jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // run-rustfix pub enum Range { //~^ ERROR `enum` and `struct` are mutually exclusive Valid { begin: u32, len: u32, }, Out, } fn main() { } </ins>

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should look like: Highlight to the user that the keywords and are mutually exclusive. Replace with . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
if !fail { return None; } <del> bug!("unexpected const parent in type_of_def_id(): {:?}", x); </del> <ins> tcx.sess.delay_span_bug( DUMMY_SP, &format!( "unexpected const parent in type_of_def_id(): {:?}", x ), ); tcx.types.err </ins> } } }

Related discussion:
text: Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:
Code change:
last_import_segment: false, unusable_binding: None, <ins> pat_span_map: Default::default(), </ins> partial_res_map: Default::default(), import_res_map: Default::default(), label_res_map: Default::default(),

Related discussion:
text: The following code... the following error and warning: The warning says that is not used but it clearly is, just not properly. This error is normally easier to spot when using the proper casing for constants, but that might not always be the case. Perhaps in this instance, we should look for other items with the exact same name and point out that the user is trying to use a constant as a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Every single one of these errors should point at similarly named things of the wrong namespace.
Do you know where in the code this is coming from?
running the following will tell you where the error is being emitted: From there the place you might want to start looking at is , which is a bit hard to follow at the moment (I'm doing a slight clean up of that method at the moment), but should be reasonably straight forward to add another check for this case to that pile :)
claim
Can I take this issue?
Yes feel free to take it, I removed my assignment.
I’m going to be tied up until May, feel free to take this issue:pray:
Hey I'm looking to get to know the Rust codebase better and contribute to the project - would love to take a crack at this issue!
claim
Code change:
<ins> // Regression test for ICE #129503 // Tests that we come up with decent error spans // when the template fed to `asm!()` is itself a // macro call like `concat!()` and should not ICE use std::arch::asm; fn main() { // Should not ICE asm!(concat!(r#"lJ𐏿Æ�.𐏿�"#, "r} {}")); //~^ ERROR invalid asm template string: unmatched `}` found // Macro call template: should point to // everything within `asm!()` as error span asm!(concat!("abc", "r} {}")); //~^ ERROR invalid asm template string: unmatched `}` found // Literal template: should point precisely to // just the `}` as error span asm!("abc", "r} {}"); //~^ ERROR invalid asm template string: unmatched `}` found } </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [resolverforlowering_raw] getting the resolver for lowering --
cc
(without looking at the code, is it ?) EDIT: ah no this might be the other class of macro-related unicode troubles, seems similar to
Code change:
[95818]: https://github.com/rust-lang/rust/pull/95818/ [95897]: https://github.com/rust-lang/rust/pull/95897/ [95953]: https://github.com/rust-lang/rust/pull/95953/ <ins> [96051]: https://github.com/rust-lang/rust/pull/96051/ </ins> [96296]: https://github.com/rust-lang/rust/pull/96296/ [96455]: https://github.com/rust-lang/rust/pull/96455/ [96737]: https://github.com/rust-lang/rust/pull/96737/

Related discussion:
text: <!-- 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. --- ~Related release note: ~Related PR: ~ ~Though the PR describes the change is related to improve its truncation better, the changed behavior is rounding up which was down before.~ EDIT: The upper changes and issue . It is not related to this issue. I want to check if this is expected change or regression. I tried this code: I expected to see this happen: explanation Until 1.62.1, Instead, this happened: explanation In 1.63.0, <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Until 1.62.1 <!-- Provide the version you are using that has the regression. --:
-- that PR you linked landed in 1.60, not 1.63?
Oh, I am sorry. I probably didn't check how much I scrolled down from release note. Then which change would be related?
Code change:
config.download_beta_toolchain(); config.out.join(config.build.triple).join("stage0/bin/rustc") }); config.initial_cargo = build .cargo .map(|cargo| {

Related discussion:
text: I'm trying to build Rust on a Tier 3 platform (; actually it's that's listed in Tier 3, but I don't think that affects the problem). Since there are no snapshots for this platform, I installed rustc from the distro's package manager (apk) and created a file to force using the pre-installed rustc rather than downloading snapshots: And the output of : I ran ; when it got as far as building the core library, I got a series of errors that were very hard to make sense of until I realized that it's because core library code depends on unstable features and I was using a stable rustc to compile it: There were many more errors, but I think they all relate to unstable features. It took me ages to figure out that (for example) the first error is due to the feature being disabled in stable. I understand that the stable compiler won't allow using unstable features even with , but is it possible for the parser to recognize this code even so and reject it with something like "feature is not enabled" instead of the much more generic "expected identifier" error?
Huh, usually Rust gets around this by setting , and usually when we bootstrap it's with a beta compiler, which does need that set by , and that would allow all the features. I wonder if wasn't set?
It's set, but the command that's actually failing (it took some effort to figure out which executable was actually failing) is: And what's installed for me in is a stable compiler. I realized after the fact that I can't use it to bootstrap, but with a different error message I might have noticed that sooner.
Forwards compatibility in diagnostics seems extremely hard. I think a much simpler and more helpful fix is to check the output of in bootstrap and give a hard error if it's not either the current version or N-1.
Note that the problem here is that you were trying to use 1.68 to build 1.70; it's unrelated to stable vs beta, the problem is that it was two versions behind instead of only one.
Mentoring instructions: in , if is set, run that process with . Compare that output to the contents of using the crate; if the minor versions aren't either the same or 1 apart, give a hard error. Note that this should also disallow e.g.
Code change:
config.download_beta_toolchain(); config.out.join(config.build.triple).join("stage0/bin/rustc") }); config.initial_cargo = build .cargo .map(|cargo| {

Related discussion:
text: building 1.68 with 1.69; we use deny-warnings in most cases and have no guarantees that unstable features will be the same between releases. Only building 1.68 with 1.67 or 1.68 should be allowed.
btw I've noticed you running into a few different bootstrap bugs the past few days — reading through https://rustc-dev- may or may not make it easier to diagnose these issues without having to spend ages interpreting the diagnostics. I'm also happy to chat about "how should this work" sorts of things .
Yes, I've read that. Thanks!
The error message could be improved though. Maybe one could make the to put into libcore/bootstrap's
I don't think rust-version is a good way to solve this, no - that won't give a warning or error if you use a future version to compile an older version. Also it won't be able to catch local-rebuild issues where the nightly version of the bootstrap compiler is too old. See my suggestion in
Hmm, I'm afraid I might have said something unclear. I'm not asking for forward compatibility in diagnostics. The feature was in version 1.68.0, according to , and I was using rustc version 1.68.2. So it should "know" about that feature, but my understanding is that when I was invoking rustc it was with flags that prevent unstable features from being used.
hmm, in that case something strange is going on because playground gives a much more reasonable error than the one you saw:
what commit of rustc were you trying to build when you got this error? I'm going to see if I can replicate it locally.
I was trying to build .
Ah ok, it was related to the context of the closure: If you look at the same gist with beta, the error message is much better: So I think this particular diagnostic issue has already been fixed. I still want to keep this issue open to track checking the version of the bootstrap compiler, though.
Code change:
#[rustc_doc_primitive = "f32"] #[doc(alias = "single")] <del> /// A 32-bit floating point type (specifically, the "binary32" type defined in IEEE 754-2008). </del> <ins> /// A 32-bit floating-point type (specifically, the "binary32" type defined in IEEE 754-2008). </ins> /// /// This type can represent a wide range of decimal numbers, like `3.5`, `27`, /// `-113.75`, `0.0078125`, `34359738368`, `0`, `-1`. So unlike integer types <del> /// (such as `i32`), floating point types can represent non-integer numbers, </del> <ins> /// (such as `i32`), floating-point types can represent non-integer numbers, </ins> /// too. /// /// However, being able to represent this wide range of numbers comes at the

Related discussion:
text: Pointed out by in the float docs are using the term "arithmetic" operations in a few places, but that term is never defined. Furthermore, the new NaN docs probably should use that term as well when discussing which operations the NaN rules apply to (instead of "non-bitwise floating point operations" which they use currently). By "arithmetic operations", the docs likely mean all operations except for unary , , , , , and .
Code change:
if i != 0 || j != lines.len() { Some((i, j)) } else { None } } <del> fn get_horizontal_trim(lines: &[&str], kind: CommentKind) -> Option<usize> { </del> <ins> fn get_horizontal_trim<'a>(lines: &'a [&str], kind: CommentKind) -> Option<String> { </ins> let mut i = usize::MAX; let mut first = true;

Related discussion:
text: Hi, I've just published a new version of my crate and the generated documentation is including a lot of bullet points that have never been included before. When I generate the docs locally on the 1.8.1 source code using the latest stable version of rust I see the same formatting for the 1.8.0 that generated, so I think this is a bug that's slipped into the nightly version of Stable local docs: ! ! My guess is that it's because I'm using block comments, the unwanted bullet points seem to match up with empty lines in the documentation comment which consist of just a . Thanks
Seems potentially related to , but the latest builds were from a nightly that should have that fixed in; cc you probably have some idea on where the issue is.
This is highly surprising indeed. Can you run with the last nightly locally and tell us if it reproduces the bug please? If so, I'll try to check what's wrong in rustdoc.
I have ran cargo doc on the latest nightly locally (nightly-x86_64-unknown-linux-gnu rustc 1.60.0-nightly ( 2022-01-20)) and it has reproduced the bug - I see the same generated docs as from the build.
It'll be fixed by
Thanks, is there any way I can get to rebuild the docs for the affected versions or will I have to submit a new version of my library to get a fixed build?
Sure. But that for that, please open an issue on repository directly.
Code change:
return ret; } <ins> fn verify_rustc_version(&self, name: &str, span: Span, metadata: &MetadataBlob) { let crate_rustc_version = decoder::crate_rustc_version(metadata.as_slice()); if crate_rustc_version != Some(rustc_version()) { span_err!(self.sess, span, E0514, "the crate `{}` has been compiled with {}, which is  incompatible with this version of rustc", name, crate_rustc_version .as_ref().map(|s|&**s) .unwrap_or("an old version of rustc") ); self.sess.abort_if_errors(); } } </ins> fn register_crate(&mut self, root: &Option<CratePaths>, ident: &str,

Related discussion:
text: When trying to update uutils/coreutils to HEAD, I got this ICE: Version: code:
apparently, this happens as a side effect of the build process. i had built with stable, then tried to build with nightly, giving incorrect metadata
Code change:
<ins> error[E0404]: expected trait, found type alias `Strings` --> $DIR/suggest-trait-alias-instead-of-type.rs:10:18 | LL | struct Struct<S: Strings>(S); |                  ^^^^^^^ type aliases cannot be used as traits | help: you might have meant to use `#![feature(trait_alias)]` instead of a `type` alias | LL | trait Strings = Iterator<Item=String>; | error: aborting due to previous error For more information about this error, try `rustc --explain E0404`. </ins>

Related discussion:
text: I managed to reproduce the problem with this snippet: The compiler yells E0404 at me, but fair enough I always ask it to a bit more about it :) However this time, it only says this: This is confusing because the snippet above doesn't involve the keyword so I didn't understand initially what I was doing wrong, then I read the error message again: I first tried this, and it worked, but having to repeat the whole syntax everywhere wasn't too compelling, hence the alias: The compiler error message makes it very clear that I can't alias a trait, but the E0404 explanation doesn't mention it at all. I hope the description could also include this use case as I've seen sometimes EXXXX explanations go over several facets of the same problem. That won't help me, but maybe others that may trip on the same problem. I would have submitted a pull request for the docs myself, but I have no idea why you can't use type aliases for traits so I can't it ;) I'm using stable Rust 1.19.0 (on Fedora).
One more thing, even though the compiler lets me create an alias for a trait, I don't know when I can use such an alias. Maybe this should be explained too.
Current output (in nightly):
Current output: No structured suggestion for the nightly feature (should be and the feature flag).
Code change:
extra_args.push("--disable-minification"); } <del> doc_std(builder, self.format, stage, target, &out, &extra_args, &self.crates); </del> <ins> doc_std(builder, self.format, stage, target, &out, &extra_args, &crates); </ins> // Don't open if the format is json if let DocumentationFormat::Json = self.format {

Related discussion:
text: I have pinned down the regression to a specific commit, thanks to recommending me . searched nightlies: from nightly-2024-07-28 to nightly-2024-07-30 regressed nightly: nightly-2024-07-30 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.9</summaryHost triple: aarch64-apple-darwin Reproduce with: : </details
Based on the commits in that rollup, I feel like might be the culprit, but it isn't obvious to me why that might be the case (cc
Thanks for the ping, will fix this.
Code change:
<ins> trait T { type A: S<C<i32 = u32> = ()>; //~^ ERROR associated type bindings are not allowed here } trait Q {} trait S { type C: Q; } fn main() {} </ins>

Related discussion:
text: I expect the following code to be rejected by the compiler but it is actually accepted and compiles successfully: The associated constant does not have any generic parameters / associated items (constants cannot have those anyways in the current version of Rust) and thus the argument list should be flagged as erroneous. Interestingly, if you remove the , the compiler correctly identifies this as an error: . I think is to be interpreted as a nested equality constraint (and not as a “defaulted” parameter, i.e. a parameter with a default value). : label T-compiler requires-nightly (it now does) Hence, I am just going to mention its tracking issue: . CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Doesn't need assoc const equality: Let me take a quick stab at this. claim
On a related note, a slightly modified version of the code above leads to an ICE (I was about to create a separate issue for this, should I still do that?): <details<summarystderr (diagnostics & backtrace)</summary</detailsThis only leads to an ICE on the current nightly (2022-09-27) (e.g. on the playground) but not on older ones like (2022-09-21).
If you want to bisect it feel free, but I think fixing the original issue in this report will also fix this one.
Yeah, I think so, too. I guess I won't bisect this.
This regressed in the last day
Oh wait, I caused it: searched nightlies: from nightly-2022-08-01 to nightly-2022-09-26 regressed nightly: nightly-2022-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Code change:
// present. However, we first need to strip the empty lines so they don't get in the middle // when we try to compute the "horizontal trim". let lines = if kind == CommentKind::Block { <del> let mut i = 0; </del> <ins> // Whatever happens, we skip the first line. let mut i = if lines[0].trim_start().starts_with('*') { 0 } else { 1 }; </ins> let mut j = lines.len(); while i < j && lines[i].trim().is_empty() {

Related discussion:
text: Hi, I've just published a new version of my crate and the generated documentation is including a lot of bullet points that have never been included before. When I generate the docs locally on the 1.8.1 source code using the latest stable version of rust I see the same formatting for the 1.8.0 that generated, so I think this is a bug that's slipped into the nightly version of Stable local docs: ! ! My guess is that it's because I'm using block comments, the unwanted bullet points seem to match up with empty lines in the documentation comment which consist of just a . Thanks
Seems potentially related to , but the latest builds were from a nightly that should have that fixed in; cc you probably have some idea on where the issue is.
This is highly surprising indeed. Can you run with the last nightly locally and tell us if it reproduces the bug please? If so, I'll try to check what's wrong in rustdoc.
I have ran cargo doc on the latest nightly locally (nightly-x86_64-unknown-linux-gnu rustc 1.60.0-nightly ( 2022-01-20)) and it has reproduced the bug - I see the same generated docs as from the build.
It'll be fixed by
Thanks, is there any way I can get to rebuild the docs for the affected versions or will I have to submit a new version of my library to get a fixed build?
Sure. But that for that, please open an issue on repository directly.
Code change:
/// [`NotConnected`]: ../../std/io/enum.ErrorKind.html#variant.NotConnected /// /// ```no_run <del> /// #![feature(udp_peer_addr)] </del> /// use std::net::UdpSocket; /// /// let socket = UdpSocket::bind("127.0.0.1:34254").expect("couldn't bind to address"); /// assert_eq!(socket.peer_addr().unwrap_err().kind(), ///            ::std::io::ErrorKind::NotConnected); /// ``` <del> #[unstable(feature = "udp_peer_addr", issue = "59127")] </del> <ins> #[stable(feature = "udp_peer_addr", since = "1.40.0")] </ins> pub fn peer_addr(&self) -> io::Result<SocketAddr> { self.0.peer_addr() }

Related discussion:
text: Tracking issue for making on stable: ,
FYI, in Rust issue tracker, "tracking issue" is a jargon for stabilizing features already in nightly. As I understand, is not yet in nightly?
A tracking issue has to be opened before a feature can land in nightly, because the attribute needs an issue number to refer to. has also been approved already, so it'll land in one of the next nightlies.
How about moving this to stable?
What's left to do to stabilize this feature? Any ETA?
Can this be stablised for 1.37?
Another reminder -- can we kick off FCP for stabilization?
any updates?
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] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Code change:
// This is something like impl Trait1 for Trait2. Illegal // if Trait1 is a supertrait of Trait2 or Trait2 is not object safe. <del> if let Some(principal_def_id) = data.principal_def_id() { if !tcx.is_object_safe(principal_def_id) { </del> <ins> let component_def_ids = data.iter().flat_map(|predicate| { match predicate.skip_binder() { ty::ExistentialPredicate::Trait(tr) => Some(tr.def_id), ty::ExistentialPredicate::AutoTrait(def_id) => Some(*def_id), // An associated type projection necessarily comes with // an additional `Trait` requirement. ty::ExistentialPredicate::Projection(..) => None, } }); for component_def_id in component_def_ids { if !tcx.is_object_safe(component_def_id) { </ins> // This is an error, but it will be reported by wfcheck.  Ignore it here. // This is tested by `coherence-impl-trait-for-trait-object-safe.rs`. } else { let mut supertrait_def_ids = <del> traits::supertrait_def_ids(tcx, principal_def_id); </del> <ins> traits::supertrait_def_ids(tcx, component_def_id); </ins> if supertrait_def_ids.any(|d| d == trait_def_id) { let sp = tcx.sess.source_map().def_span(tcx.span_of_impl(impl_def_id).unwrap()); struct_span_err!(tcx.sess,

Related discussion:
text: Code gives the same error as , giving (dyn Xyz + Abc + 'static)XyzCode passes coherence, but wfcheck fails because of the confusion: