jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: comparison operators cannot be chained --> $DIR/issue-82566-2.rs:17:23 | LL | fn foo1() -> [(); Foo1<10>::SUM] { |                       ^  ^ | help: use `::<...>` instead of `<...>` to specify type or const arguments | LL | fn foo1() -> [(); Foo1::<10>::SUM] { |                       ^^ error: expected one of `.`, `?`, `]`, or an operator, found `,` --> $DIR/issue-82566-2.rs:21:26 | LL | fn foo2() -> [(); Foo2<10, 20>::SUM] { |                          ^ expected one of `.`, `?`, `]`, or an operator | help: use `::<...>` instead of `<...>` to specify type or const arguments | LL | fn foo2() -> [(); Foo2::<10, 20>::SUM] { |                       ^^ error: expected one of `.`, `?`, `]`, or an operator, found `,` --> $DIR/issue-82566-2.rs:26:26 | LL | fn foo3() -> [(); Foo3<10, 20, 30>::SUM] { |                          ^ expected one of `.`, `?`, `]`, or an operator | help: use `::<...>` instead of `<...>` to specify type or const arguments | LL | fn foo3() -> [(); Foo3::<10, 20, 30>::SUM] { |                       ^^ error: aborting due to 3 previous errors </ins>

Discussion:
<!-- 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: The current output is: Ideally the output should mention that the user needs to use a turbofish here: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
the help message seems to only be missing if there are 2 const arguments: using type parameters or just one const param causes a useful help message
claim
It turns out 's repro is different than the original repro. My PR fixes 's examples but not the original one. I'll update it to fix the original one too.
All fixed.
Change:
fn main() { <del> assert_eq!(1, 2) assert_eq!(3, 4) //~ ERROR expected one of `.`, `;`, `?`, `}`, or an operator, found `assert_eq` </del> <ins> assert_eq!(1, 2) //~ ERROR: expected `;` assert_eq!(3, 4) //~ ERROR: expected `;` </ins> println!("hello"); }

Discussion:
: The current output is: We should detect cases where a semicolon would be appropriate (probe that the current token and maybe limited lookahead confirm that what comes next could be a valid statement on its own) and suggest a semicolon. . We might want to silence one or the other depending on whether the current token might be starting a statement or an item ( vs , etc.). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Sorry, I don't have much time these days. release-assignment
Just a guess: could this be addressed with another block, as in
I think we would need to answer this question: why is the logic here not handling the cases we want to handle?
This seems to be on track given the clue "probe that the current token and maybe limited lookahead confirm that what comes next could be a valid statement on its own"...
claim
release-assignment
That is a great question: as the code is written it looks like it should work. I don't know why it isn't triggering :( It might be that isn't being called in these case. It might be a good idea to uplift most of this method into
I'd like to give this a try. claim
Change:
<ins> #![feature(min_type_alias_impl_trait)] #![feature(impl_trait_in_bindings)] #![allow(incomplete_features)] type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; //~^ ERROR: hidden type for `impl Trait` captures lifetime that does not appear in bounds //~| ERROR: the type `&'<empty> str` does not fulfill the required lifetime //~| ERROR: cannot infer an appropriate lifetime for lifetime parameter `'a` due to conflicting requirements trait Output<'a> {} impl<'a> Output<'a> for &'a str {} fn cool_fn<'a>(arg: &'a str) -> OpaqueOutputImpl<'a> { let out: OpaqueOutputImpl<'a> = arg; arg } fn main() { let s = String::from("wassup"); cool_fn(&s); } </ins>

Discussion:
I was playing around with existential types in nightly, forgot to update some code, and hit this ICE. <!-- 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
label: +requires-nightly
I'm not sure, if it's the same cause, but this ICE seems related (found in by so I'll post it here instead of in a new issue:
The original ICE has been fixed by but hasn't, could you open a new issue if it hasn't been reported yet?
Change:
hir::TraitItemKind::Fn(ref sig, hir::TraitFn::Provided(body)) => { let mut m = (sig, &self.generics, body, None).clean(cx); if m.header.constness == hir::Constness::Const <del> && !is_min_const_fn(cx.tcx, local_did.to_def_id()) </del> <ins> && is_unstable_const_fn(cx.tcx, local_did.to_def_id()).is_some() </ins> { m.header.constness = hir::Constness::NotConst; }

Discussion:
This is a follow-up on I opened earlier, with the requested minimal reproduction in the form of a simple .
Looks like this is either or cc - do you know what those are doing/why they exist?
It's because of the feature. As long as it's not stable, they don't want the keyword to be displayed, even if the function description is describing a const fn. This is a bit strange.
Yeah, that makes no sense to me at all. I have a crate that is very much nightly-only containing a rather large number of s, and at the moment literally none of them are displayed as such in my documentation because of this, despite the fact that they've never not been and will never not be in the future. I of course cannot disable the flag either as then the crate won't compile, as much of what I'm doing does not fit into the stabilized set of functionality. At the very least, surely there must be some way to make it possible to specifically tell rustdoc to "please always document s as exactly what they are no matter what" without changing this default behaviour if that's not desired?
I think the metric should be 'does this have , not 'is this a function'.
I wonder if this isn't an artifact of the switch when adding support... But in any case, it should be a check over , you're absolutely right.
I wonder if this ever worked ... do you mind trying this with an old version of rustdoc? Preferably before was implemented: cc
I'll try that on my crate later today.
After testing both the example I gave here and my own crate with various nightlies from before was implemented, I can confirm that this problem definitely pre-dates it. There's no difference in how rustdoc behaved.
(apologies to lcnr for the ping)
If this helps at all, whichever version of rustdoc was using on August 1st did document my crate properly, it seems. Only the very latest version, uploaded on September 5th, was documented with the keyword missing. So it's a fairly recent bug, overall.
Ok, so I think I was reading the dates on the PRs a bit wrong when I tested yesterday as far as the timeframe for when was merged.

I just did a whole bunch more one-by-one testing of nightlies from August, and in fact the problem doesn't quite predate which was merged on August 7th. Specifically, the very last nightly to have a rustdoc that documents correctly is . Switching directly from that to from the next day makes the problem appear.
consider using instead which will do it automatically
Well, I already know it's a commit from between the 10th and 11th of August now, at least. Also, doesn't really seem to be designed for scenarios where identifying the problem specifically requires running on a crate and then visually inspecting the generated HTML files...
Change:
<ins> #![feature(test)] extern crate test; #[bench] fn smoke_yesiter(b: &mut test::Bencher) { let mut i = 0usize; b.iter(|| { i = i.wrapping_add(1); i }) } #[bench] fn smoke_noiter(_: &mut test::Bencher) {} </ins>

Discussion:
<!-- 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. --I tried running benchmarks with current nightly rust: Running with the previous nightly works: Also, note the difference in the line . This happens for the benchmarks in both the and crates. looks to be related ( <!-- 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<summaryBacktrace</summary<p</p</details
Ouch. I guess libtest needs better tests. I might be able to get to this in 12 hours or so, if anyone else sees this please do take care of it.
Oof, missed that started as the full list of tests+benches before getting shadowed as only the tests. Not a fan of the way TestEvent is used to manage state (haven't ever been a fan of it, TBH), but I'll have to think a bit about how to fix it without undoing the perf wins we just got here.
Confirm the bug as well: started to fail after changing the toolset to the current nighly.
Yeah, should be fixed by . Hopefully will be in the next nightly, if we're lucky.
Change:
<ins> error[E0412]: cannot find type `C` in this scope --> $DIR/issue-109831.rs:4:24 | LL | struct A; | --------- similarly named struct `A` defined here ... LL | fn f(b1: B, b2: B, a2: C) {} |                        ^ | help: a struct with a similar name exists | LL | fn f(b1: B, b2: B, a2: A) {} |                        ~ help: you might be missing a type parameter | LL | fn f<C>(b1: B, b2: B, a2: C) {} |     +++ error[E0425]: cannot find value `C` in this scope --> $DIR/issue-109831.rs:7:16 | LL | struct A; | --------- similarly named unit struct `A` defined here ... LL |     f(A, A, B, C); |                ^ help: a unit struct with a similar name exists: `A` error[E0061]: this function takes 3 arguments but 4 arguments were supplied --> $DIR/issue-109831.rs:7:5 | LL |     f(A, A, B, C); |     ^ -  -     - unexpected argument |       |  | |       |  expected `B`, found `A` |       expected `B`, found `A` | note: function defined here --> $DIR/issue-109831.rs:4:4 | LL | fn f(b1: B, b2: B, a2: C) {} |    ^ -----  -----  ----- help: remove the extra argument | LL -     f(A, A, B, C); LL +     f(/* B */, /* B */, B); | error: aborting due to 3 previous errors Some errors have detailed explanations: E0061, E0412, E0425. For more information about an error, try `rustc --explain E0061`. </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. --You need rustc built with debug assertions in order to reproduce this! <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> error: unconstrained generic constant --> $DIR/issue-84659.rs:8:15 | LL |     type Baz: Bar<{ Self::N }>; |               ^^^^^^^^^^^^^^^^ | = help: try adding a `where` bound using this expression: `where [(); { Self::N }]:` error: aborting due to previous error </ins>

Discussion:
: <details<summaryerror output</summary</details
Rust playground:
Have you been able to reproduce this ICE with the latest nightly?
Playground link is not failing, I guess it's a good sign.
No longer ICEs since

The code below will trigger an ICE on the latest nightly build This is as small as i could make it while still triggering the error <!-- 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
Also occurs on stable! Regression from 1.50 to 1.51 modify labels: -requires-nightly +regression-from-stable-to-stable
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-04-29 regressed nightly: nightly-2021-01-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed PR is , cc
See and
just because something is gated doesn't mean it can't crash on stable ;) Use the above code and try to build it on the playground or compile it with a stable compiler, it will ICE.
We briefly discussed this on . I'd revert some labels here because we think this is a nightly-only issue due to the unstable feature. The fact that it compiles and reproduces on stable is kind of misleading because it's the that allows that. Makes sense? modify labels: +requires-nightly -regression-from-stable-to-stable +P-medium
sure enough ;) but just to be clear, even without this results in an ICE on stable
Okay so this is a bit complicated. Because while this does has , is still ICEs on stable. That said, not including the feature gate doesn't ICE. Given that, I think the current labels are appropriate, except maybe . It is technically a stable to stable regression, but it requires a feature to ICE, and I'm not sure that's the spirit of what that label is intended to track.
agreed on the labels, I've got the context partially wrong here. modify labels: -requires-nightly
With this also doesn't ICE
No longer ICEs since as far as I could tell with various combinations of the new feature gates
Change:
//        the ugliness comes from inlining across crates where //        everything comes in as a fully resolved QPath (hard to //        look at). <del> match href(trait_.def_id(), cx) { Ok((ref url, _, ref path)) if !f.alternate() => { write!( f, "<a class="associatedtype" href="{url}#{shortty}.{name}"  title="type {path}::{name}">{name}</a>{args}", url = url, shortty = ItemType::AssocType, name = assoc.name, path = join_with_double_colon(path), args = assoc.args.print(cx), )?; } _ => write!(f, "{}{:#}", assoc.name, assoc.args.print(cx))?, } Ok(()) </del> <ins> if !f.alternate() && let Ok((url, _, path)) = href(trait_.def_id(), cx) { write!( f, "<a class="associatedtype" href="{url}#{shortty}.{name}"  title="type {path}::{name}">{name}</a>", shortty = ItemType::AssocType, name = assoc.name, path = join_with_double_colon(&path), ) } else { write!(f, "{}", assoc.name) }?; // Carry `f.alternate()` into this display w/o branching manually. fmt::Display::fmt(&assoc.args.print(cx), f) </ins> } } }

Discussion:
Given Rustdoc does not escape the ASCII angle brackets for the generic argument list of the generic associated type projection leading to the following butchered HTML output: I've noticed this while working on rustdoc integration for in . It's possible that the refactoring PR will fix this (need to check) or at least make it more pleasant to fix. Assigning myself for now since I'm gonna fix this otherwise. claim label T-rustdoc A-rustdoc-ui F-genericassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Copying my comment from : is requesting alternate formatting (i.e. plaintext), but in this branch of things, alternate formatting hasn't been requested by the caller. So this is likely emitting into an HTML context. If you change it to in your branch I'm guessing that will fix things.
Here's a live example: As it turns out, this bug does appear to be what's crashing rustdoc in . So I will wind up fixing it. But feel free to investigate and fix if you prefer not to wait.
This wound up being the fix:
On at least I cannot reproduce your fix that involves adding in branch (maybe that only works on your branch). In any case, the lines in are definitely the culprit. I've already fixed it that way in but I've now also opened a separate PR. Thanks for the live example!
Change:
fn visit_item(&mut self, i: &hir::Item) { debug!("visit_item: {:?}", i); <del> self.check_item_well_formed(i); </del> <ins> let def_id = self.tcx.hir.local_def_id(i.id); ty::maps::queries::check_item_well_formed::ensure(self.tcx, def_id); </ins> intravisit::walk_item(self, i); } fn visit_trait_item(&mut self, trait_item: &'v hir::TraitItem) { debug!("visit_trait_item: {:?}", trait_item); <del> let method_sig = match trait_item.node { hir::TraitItemKind::Method(ref sig, _) => Some(sig), _ => None }; self.check_associated_item(trait_item.id, trait_item.span, method_sig); </del> <ins> let def_id = self.tcx.hir.local_def_id(trait_item.id); ty::maps::queries::check_trait_item_well_formed::ensure(self.tcx, def_id); </ins> intravisit::walk_trait_item(self, trait_item) } fn visit_impl_item(&mut self, impl_item: &'v hir::ImplItem) { debug!("visit_impl_item: {:?}", impl_item); <del> let method_sig = match impl_item.node { hir::ImplItemKind::Method(ref sig, _) => Some(sig), _ => None }; self.check_associated_item(impl_item.id, impl_item.span, method_sig); </del> <ins> let def_id = self.tcx.hir.local_def_id(impl_item.id); ty::maps::queries::check_impl_item_well_formed::ensure(self.tcx, def_id); </ins> intravisit::walk_impl_item(self, impl_item) } }

Discussion:
At the moment WF checking is not done via a query. As a consequence, we cannot cache it during incremental compilation. Seems like an easy optimization. cc
I'm working on this.
Change:
const EARLY_DROP_C: i32 = (WithDtor, 0).1; //~^ ERROR destructors cannot be evaluated at compile-time <ins> const fn const_drop<T>(_: T) {} //~^ ERROR destructors cannot be evaluated at compile-time const fn const_drop2<T>(x: T) { (x, ()).1 //~^ ERROR destructors cannot be evaluated at compile-time } </ins> fn main () {}

Discussion:
These currently compile, even if they can be used from compile-time code to trigger a drop: cc
Change:
<del> Subproject commit b91ae16eb1ab03b996de5ffc44db054244c1d2f6 </del> <ins> Subproject commit 2855b2143972df7102333193aa3c83ddce227e36 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Change:
} if let Some((prefix, mpi)) = shortest_uninit_seen { <ins> // Check for a reassignment into a uninitialized field of a union (for example, // after a move out). In this case, do not report a error here. There is an // exception, if this is the first assignment into the union (that is, there is // no move out from an earlier location) then this is an attempt at initialization // of the union - we should error in that case. let tcx = this.infcx.tcx; if let ty::TyKind::Adt(def, _) = base.ty(this.mir, tcx).to_ty(tcx).sty { if def.is_union() { if this.move_data.path_map[mpi].iter().any(|moi| { this.move_data.moves[*moi].source.is_predecessor_of( context.loc, this.mir, ) }) { return; } } } </ins> this.report_use_of_moved_or_uninitialized( context, InitializationRequiringAction::PartialAssignment,

Discussion:
review comments:
triage: P-medium. (We should look into this, but even if its wrong, I'm not going to push to a backport its hypothetical bug fix.)

review comments: For the record, here's the relevant part of the test in question ():
This should be NLL-complete, not NLL-sound, right?
Yeah, it should. My bad.
triage: P-high, not not Release milestone. This issue is bad enough for fix quickly, but there's no reason to beta-backport (as I explained on the PR itself here )
Change:
<ins> // Test that a `recursion_limit` of 0 is valid #![recursion_limit = "0"] macro_rules! test { () => {}; ($tt:tt) => { test!(); }; } test!(test); //~ ERROR 10:1: 10:13: recursion limit reached while expanding `test!` fn main() {} </ins>

Discussion:
The following code since it exceeds the default recursion limit. Using as the recursion limit works as expected. This is because we don't check for integer overflow errors when parsing limits: There's a few options here. My preference would be to silently default to when overflow occurs. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi! I'd like to try and handle this. If I understand this correctly, we should check if there is an , and if that error is an overflow. If it's an overflow, we default to ? claim
correct
Change:
/// Whether a .debug_gdb_scripts section will be added to the output object file pub emit_debug_gdb_scripts: bool, <ins> /// Whether or not to unconditionally `uwtable` attributes on functions, /// typically because the platform needs to unwind for things like stack /// unwinders. pub requires_uwtable: bool, </ins> } impl Default for TargetOptions {

Discussion:
From Gecko profiler uses EHABI information to walk stack. But since rustc doesn't generate EHABI, it cannot walk stack on generated code by rust. says, "-C panic=abort" causes that EHABI isn't emitted", so we need a option not to remove it (or don't remove EHABI even if -C panic=abort).
Note the same actually applies to EH_FRAME info on x86-64, which iirc the Firefox profiler also uses on x86-64. More generally, it can be desirable to have unwind info even when panic doesn't unwind.
For C/C++ code in Firefox we use  to ensure that the compiler generates these when is on: The equivalent for x86-64 is  which is apparently on by default. It seems like having a compiler option to enable this would be good enough, since the behavior here mirrors what gcc does: only emit unwind info if needed for exceptions/unwinding.
LLVM seems to turn on EHABI as default by (EnableARMEHABI is removed by this landing, but still has it) is similar issue for Win64 ABI.
This may or may not be related to , but I can prepare a patch like for the targets here. do you know what targets are in use by Firefox and would need this treatment?