jiebi/CodeConvo huggingface dataset:
Change:
/// modified in a way that it remains valid UTF-8. /// /// [`u8`]: primitive.u8.html <del> #[unstable(feature = "str_as_mut_ptr", issue = "58215")] </del> <ins> #[stable(feature = "str_as_mut_ptr", since = "1.36.0")] </ins> #[inline] pub fn as_mut_ptr(&mut self) -> *mut u8 { self as *mut str as *mut u8

Discussion:
This is a tracking issue for : Implemented in
Given that the implementation is trivial I don’t think letting it "bake" in Nightly is any use. And since already has this method and already has the version of this, I don’t expect this to be controversial at all. Still, let’s go through the usual dance: fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
Change:
} } fn visit_impl_item(&mut self, it: &'tcx ImplItem) { <ins> debug!("find_existential_constraints: visiting {:?}", it); </ins> let def_id = self.tcx.hir().local_def_id(it.hir_id); // The existential type itself or its children are not within its reveal scope. if def_id != self.def_id {

Discussion:
Mentioning the existential types tracking issue Mentioning and
O_o I don't think I considered closures at all. Should closures be defining uses? Or just uses (and thus only be able to return that type by calling a function that defines the existential)?
As a motivating use case, existential types defined by a closure are required if we want to extend to support referring to local variables.
Yeah, any in-scope use (including in a binding) can be a defining use.
A binding like this? It looks like this is not currently picked up. It is why I had to write rather than simply in my previous comment.
Yeah, the RFC specifies that that should work.
I chose a simpler logic: any in scope use must be a defining use.
We've moved from segmentation faults to an ICE:
Change:
where `n` is the floating-point number represented by `[num]`. "] fn from_str(num: str) -> option<float> { <ins> if num == "inf" { ret some(infinity); } else if num == "-inf" { ret some(neg_infinity); } else if num == "NaN" { ret some(NaN); } </ins> let mut pos = 0u;               //Current byte position in the string. //Used to walk the string in O(n). let len = str::len(num);        //Length of the string, in bytes.

Discussion:
Should float::fromstr do the following conversions? "NaN" -float::NaN "inf" -float::infinity "-inf" -float::neginfinity That'd match what float::to_str does (if my pull request is merged.) If this sounds good I'll chuck a patch in.
It will be very good when this will be fixed. There are some additional points to be considered: If I remember correctly, the floating point standard allows for both short ("inf") and long ("infinity") syntax. Are you aware of the other float formatting related issues? I think there used to be a floating point literal parsing problem in rustc for very large literals (not fitting into 32 bits) that is related (can't find the issue right now). Besides adding support for NaN and inf in fromstr/tostr, I personally think rust should define a literal syntax for these, i.e. the compiler should support them directly.
If this is standard behavior for converting from strings than I say go for it.
More things to check proper handling of +0.0 vs -0.0 vs 0.0 hexadecimal notation for the mantissa for the lossless exchange of values
The last one is discusses in . The real kicker would be if all this were supposed by the parser as literal syntax.
Fixed by
Change:
// If there is a single unbound associated type and a single excess generic param // suggest replacing the generic param with the associated type bound if provided_args_matches_unbound_traits && !unbound_types.is_empty() { <del> let unused_generics = &self.gen_args.args[self.num_expected_type_or_const_args()..]; let suggestions = iter::zip(unused_generics, &unbound_types) .map(|(potential, name)| (potential.span().shrink_to_lo(), format!("{name} = "))) .collect::<Vec<_>>(); if !suggestions.is_empty() { err.multipart_suggestion_verbose( format!( "replace the generic bound{s} with the associated type{s}", s = pluralize!(unbound_types.len()) ), suggestions, Applicability::MaybeIncorrect, ); </del> <ins> // Don't suggest if we're in a trait impl as // that would result in invalid syntax (fixes #116464) if !self.is_in_trait_impl() { let unused_generics = &self.gen_args.args[self.num_expected_type_or_const_args()..]; let suggestions = iter::zip(unused_generics, &unbound_types) .map(|(potential, name)| { (potential.span().shrink_to_lo(), format!("{name} = ")) }) .collect::<Vec<_>>(); if !suggestions.is_empty() { err.multipart_suggestion_verbose( format!( "replace the generic bound{s} with the associated type{s}", s = pluralize!(unbound_types.len()) ), suggestions, Applicability::MaybeIncorrect, ); } </ins> } } else if remove_entire_generics { let span = self

Discussion:
The suggestion is not valid syntax. Applying the original suggestion like so: to this error instead: Note also that a more naive suggestion to keep the parameter like so: fail because it's unconstrained: needs to be a concrete type or an associated type of an input type parameter. The diagnostic is identical in beta and nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
/// // `next_if_eq` saves the value of the next item if it was not equal to `expected`. /// assert_eq!(iter.next(), Some(1)); /// ``` <del> #[unstable(feature = "peekable_next_if", issue = "72480")] </del> <ins> #[stable(feature = "peekable_next_if", since = "1.51.0")] </ins> pub fn next_if_eq<T>(&mut self, expected: &T) -> Option<I::Item> where T: ?Sized,

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for the feature (). The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implement the RFC [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- Should be named or ? Should be named or ?
modify labels: T-libs
I don't think the methods should be renamed to something else, becuase also has a method, and should use the same name but with the component. Also, if these questions are resolved and there are no other blockers, I would like to go ahead and stabilize this feature.
Change:
<ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #[derive(Debug)] enum Foo { Bar(u32, u32), Baz(&'static u32, &'static u32) } static NUM: u32 = 100; fn main () { let mut b = Foo::Baz(&NUM, &NUM); b = Foo::Bar(f(&b), g(&b)); } static FNUM: u32 = 1; fn f (b: &Foo) -> u32 { FNUM } static GNUM: u32 = 2; fn g (b: &Foo) -> u32 { GNUM } </ins>

Discussion:
Assigning to a mutable vector causes it to be modified in-place even if the right side of the assignment references it. On IRC, pointed me to , which might be related.
Nominating. This may not be a 1.0 backcompat-lang issue though as it seems fairly rare.
Same thing with structs:
OK, same thing happens with enums, which is a bit more serious since it now affects memory safety.
I believe this problem is in trans -- it is supposed to used a temporary buffer for these sorts of cases, but obviously that check is not working correctly.
Team believes this to be a miscompilation issue (and not, as we feared at first, a failure of the borrow-checker to reject an incorrect program). That is, these programs should be compilable; the problem is that the generated code is wrong. P-high, not 1.0.
All of the code examples from this ticket seem to work now: So I think this just needs regression tests.
Change:
}); } <ins> fn visit_fn(&mut self, fn_kind: FnKind<'a>, span: Span, _: NodeId) { if let FnKind::Fn(_, _, sig, _, body) = fn_kind { if let Async::Yes { closure_id, return_impl_trait_id, .. } = sig.header.asyncness { self.create_def(return_impl_trait_id, DefPathData::ImplTrait, span); // For async functions, we need to create their inner defs inside of a // closure to match their desugared representation. Besides that, // we must mirror everything that `visit::walk_fn` below does. self.visit_fn_header(&sig.header); visit::walk_fn_decl(self, &sig.decl); if let Some(body) = body { let closure_def = self.create_def(closure_id, DefPathData::ClosureExpr, span); self.with_parent(closure_def, |this| this.visit_block(body)); } return; } } visit::walk_fn(self, fn_kind, span); } </ins> fn visit_use_tree(&mut self, use_tree: &'a UseTree, id: NodeId, _nested: bool) { self.create_def(id, DefPathData::Misc, use_tree.span); visit::walk_use_tree(self, use_tree, id);

Discussion:
I was migrating my library (Mammut) to use reqwest and be async, and the compiler ICEd. I don't know how to reduce it further than this. I tried this code: I expected to see this happen: A successful build or another compile error Instead, this happened: I also tried this on the latest nightly and it emits the same error. : Backtrace:
Reproduced with lastest nighlty: ICE from macro resolving I believe. cc
cc
triage: P-high, removing nomination tag. (instead, going to proritize going through the P-high issues that have accumulated over last two weeks.)
Visiting from triage.. the next step is to reduce the reproducer.
Reduced ():
Further reduced:
Fixed in
Change:
"log", "memchr", "opener", <del> "pulldown-cmark 0.8.0", </del> <ins> "pulldown-cmark", </ins> "regex", "serde", "serde_derive",

Discussion:
Nested markdown lists as below are not rendered as nested lists, but as single-level lists. Works as expected: stable (, ) beta (, ) Produces unintended output: nightly (, ) Initially reported at foo bar baz With (with stable toolchain): ! foo + bar + baz With with nightly toolchain: !
I need to confirm if it comes from rustdoc or pulldown-cmark. I'll try to fix it in the next days.
This is a regression in pulldown-cmark, I have opened
This also affects
Thanks !
A patch release of pulldown-cmark is about to be released. Could someone open a PR to update to it?
Ok, release is out.
Just opened for it.
Marking as P-high: regression that breaks relatively simple Markdown syntax
Change:
pub fn noop_visit_vis<T: MutVisitor>(visibility: &mut Visibility, vis: &mut T) { match &mut visibility.kind { VisibilityKind::Public | VisibilityKind::Inherited => {} <del> VisibilityKind::Restricted { path, id } => { </del> <ins> VisibilityKind::Restricted { path, id, shorthand: _ } => { </ins> vis.visit_path(path); vis.visit_id(id); }

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: it to print . Instead, this happened: it prints . <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.62.1 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-beta -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Similar effect can already be observed on stable too prints already. But it is indeed a (small?) behavior change in this beta for the case.
I would expect to see this issue in 2020, but not now when we are collecting tokens in (almost) all cases instead of converting them from AST. Apparently for visibilities they are collected incorrectly for some reason. cc (in case you have time for this)
bisection points to searched nightlies: from nightly-2022-01-01 to nightly-2022-08-03 regressed nightly: nightly-2022-05-24 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsThe commit is a rollup so I think_ it's in cc ?
Without even looking at the rest of the rollup, it's definitely my PR. Short of storing whether was used, I'm not sure what could be done.
This will slip into 1.63.

I'll work on this this evening to get it resolved quickly, even if it is too late to patch the beta. I don't think it'll be too difficult.
PR is up: . This also fixes to be , which is certainly better than the status quo of .
Change:
z-index: 1; } } <ins> .hidden-by-impl-hider, .hidden-by-usual-hider { /* important because of conflicting rule for small screens */ display: none !important; } </ins>

Discussion:
When pressing the hotkey on type's documentation such as on the , the methods of the are still shown. This is however mostly useless information that gets in the way of scrolling to see what traits a type implements. It would be more ergonomic if would hide every method of every trait but still show all associated items (types and consts) for each (since they carry useful information). In addition, a / link should be on all the s (including non-trait impls) either besides or to the left of the (as done with s this expands and collapses the impls but keeps associated items shown.
I can rewrite this as an RFC if required, but I was unsure about the protocol wrt. rustdoc.
Similar request:
Closing as resolved.

For example, looking at the docs for , some important trait implementations are hard to find in between all the implementations for each size of fixed-size arrays: Hopefully these impls will eventually become generic, but in the meantime we should consider some way of hiding or collapsing them in the docs.
cc
Dupe of
Change:
// searching forwards for boundaries we've got somewhere to search. let snippet = if let Some(ref src) = local_begin.sf.src { let len = src.len(); <del> (&src[start_index..len]) </del> <ins> &src[start_index..len] </ins> } else if let Some(src) = src.get_source() { let len = src.len(); <del> (&src[start_index..len]) </del> <ins> &src[start_index..len] </ins> } else { return 1; };

Discussion:
I'd be interested in handling this. Looking at , it looks fairly straightforward -- however it does look like there could be some ambiguity with return values in blocks (e.g. ) Would we want to disambiguate lints, or would it be fine to use the same lint diagnostic for both cases?
what sort of ambiguity do you mean? I'd expect a single lint on in your example (note that we about unused ).
To use your original example, Both and are , since they represent the implicit return at the end of a block. I was wondering if we'd care about the case, and if we did, if it made sense to treat it the same as . If you naively add a match arm to the visitor, you get the same diagnostic for both.
Yes, both and should be linted here.
Change:
Let's see an example coming from the [standard library] by taking a look at the [`std::env::args()`][env::args] function: <del> ``````text </del> <ins> ``````markdown </ins> Returns the arguments which this program was started with (normally passed via the command line).

Discussion:
Split off from . modify labels: T-rustdoc C-enhancement <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Uh, it looks like rustbot is editing my message and adding weird comments:
Cc
It looks like smart punctuation doesn't work in headers: ! wasn't able to reproduce this in pulldown itself; I'm guessing rustdoc is doing something special with headers. Cc
Triagebot does that as a way of easily storing data per-issue (we could do it in the database now, we didn't have one back then). But it's expected and shouldn't really be a problem.
Is this a good thing? Wouldn't keeping things as it is is better?
I think if you want to argue against doing this, giving reasons would be helpful. I personally think given that we already use emoji and otherwise non-ASCII characters readily, it should be reasonable for us to generate smart quotes as well.
I do think emoji and other non-ASCII characters if specified would be good except for smart quote. It's like saying to use greek question mark which is the same as semi-colon when a semi-colon was seen in documentation to make it look a bit cooler. One thing is copying, when others are copying the text, it will copy the utf-8 version of smart quotes which when displayed in terminals which in turn will make it look ugly and hard for text processing. Auto changing text to emoji I am okay with that. But not automatically changing single quotes, double quotes and semi-colons. Personally I don't see much benefit to that, usually if users want it they would specifically type it out but otherwise it would be similar. In my humble opinion, looks wise the smart quotes are more ugly, but easier to distinguish opening and closing quotes, but still when copied and pasted it may not look so good.
Change:
= help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct = note: this struct has unspecified layout note: the type is defined here <del> --> $DIR/lint-ctypes-94223.rs:27:1 </del> <ins> --> $DIR/lint-ctypes-94223.rs:34:1 </ins> | LL | pub struct FfiUnsafe; | ^^^^^^^^^^^^^^^^^^^^ error: `extern` fn uses type `FfiUnsafe`, which is not FFI-safe <del> --> $DIR/lint-ctypes-94223.rs:41:22 </del> <ins> --> $DIR/lint-ctypes-94223.rs:48:22 </ins> | LL | pub const BAD_CONST: extern "C" fn(FfiUnsafe) = f; |                      ^^^^^^^^^^^^^^^^^^^^^^^^ not FFI-safe

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- at <details<summary<strongBacktrace</strong</summary<p</p</detailssearched nightlies: from nightly-2023-01-01 to nightly-2023-08-14 regressed nightly: nightly-2023-07-04 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
As referenced in the other issue this now also happens on stable since = 1.70. The culprint seems to be this type alias: Removing the reference in the Option works around this panic.
Here's a minimal example that reproduces the issue: Interestingly, this only happens while the function is extern "C".
WG-prioritization assigning priority (). cc: for the bisection pointing to label -I-prioritize +P-high
claim
The panic originates in the on this line: It happens because returns which it does because normalization of fails. The reason the normalization fails is because trait resolution fails for the projection due to not being sufficiently bound. If, for example, I change in 's example above to by adding a bound, the panic goes away as trait resolution succeeds now. Since the normalization failure can be legitimate as in this case, I feel this unwrap: should be removed to fix the issue. However, I'm not sure what the enclosing method should do upon receiving a from . I'd presume it should return . Please review and let me know if this analysis makes sense. cc:
Closely related PR: . It fixes an ICE due to similar causes but on a different line. In fact the very next line.
Yeah, I think making not and just bubble up the is the right behavior here.
Change:
<ins> error[E0422]: cannot find struct, variant or union type `Drain` in this scope --> $DIR/issue-52202-use-suggestions.rs:21:14 | LL |     let _d = Drain {}; |              ^^^^^ not found in this scope help: possible candidates are found in other modules, you can import them into scope | LL | use crate::plumbing::Drain; | LL | use std::collections::binary_heap::Drain; | LL | use std::collections::hash_map::Drain; | LL | use std::collections::hash_set::Drain; | and 3 other candidates error: aborting due to previous error For more information about this error, try `rustc --explain E0422`. </ins>

Discussion:
Consider the following program. When compiled with with the 6 July nightly, we get this error message: But if we take the suggestion literally (and continue using the 2018 edition), is : A pull request is forthcoming.
Change:
<ins> #![feature(const_trait_impl, effects)] const fn test() -> impl ~const Fn() { //~ ERROR ~const can only be applied to `#[const_trait]` traits const move || { //~ ERROR const closures are experimental let sl: &[u8] = b"foo"; match sl { [first, remainder @ ..] => { assert_eq!(first, &b'f'); } [] => panic!(), } } } fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2023-02-05 Regression in cc
Fixed on the latest nightly, marking as E-needs-test labels: +E-needs-test
I don't think this is actually fixed, just that the ICE cannot be triggered currently, but might resurface when the effects feature is fully implemented.