jiebi/CodeConvo huggingface dataset:
Change:
| ^^^^^^^^^^^^^^^^^^^^^^^^^ = note: ...which requires evaluating trait selection obligation `impl std::clone::Clone: std::marker::Send`... note: ...which requires computing type of `cycle2::{{opaque}}#0`... <del> --> $DIR/auto-trait-leak.rs:22:16 </del> <ins> --> $DIR/auto-trait-leak.rs:20:16 </ins> | LL | fn cycle2() -> impl Clone { |                ^^^^^^^^^^ note: ...which requires borrow-checking `cycle2`... <del> --> $DIR/auto-trait-leak.rs:22:1 </del> <ins> --> $DIR/auto-trait-leak.rs:20:1 </ins> | LL | fn cycle2() -> impl Clone { | ^^^^^^^^^^^^^^^^^^^^^^^^^ note: ...which requires processing `cycle2`... <del> --> $DIR/auto-trait-leak.rs:22:1 </del> <ins> --> $DIR/auto-trait-leak.rs:20:1 </ins> | LL | fn cycle2() -> impl Clone { | ^^^^^^^^^^^^^^^^^^^^^^^^^ note: ...which requires processing MIR for `cycle2`... <del> --> $DIR/auto-trait-leak.rs:22:1 </del> <ins> --> $DIR/auto-trait-leak.rs:20:1 </ins> | LL | fn cycle2() -> impl Clone { | ^^^^^^^^^^^^^^^^^^^^^^^^^ note: ...which requires unsafety-checking `cycle2`... <del> --> $DIR/auto-trait-leak.rs:22:1 </del> <ins> --> $DIR/auto-trait-leak.rs:20:1 </ins> | LL | fn cycle2() -> impl Clone { | ^^^^^^^^^^^^^^^^^^^^^^^^^ note: ...which requires building MIR for `cycle2`... <del> --> $DIR/auto-trait-leak.rs:22:1 </del> <ins> --> $DIR/auto-trait-leak.rs:20:1 </ins> | LL | fn cycle2() -> impl Clone { | ^^^^^^^^^^^^^^^^^^^^^^^^^ note: ...which requires type-checking `cycle2`... <del> --> $DIR/auto-trait-leak.rs:22:1 </del> <ins> --> $DIR/auto-trait-leak.rs:20:1 </ins> | LL | fn cycle2() -> impl Clone { | ^^^^^^^^^^^^^^^^^^^^^^^^^

Discussion:
Does not appear on Stable or Beta in the playground. () Errors: modify labels: +C-bug, A-diagnostics, D-verbose, E-needs-bisection, T-compiler Edit: nevermind the attempt of adding “regression-from-stable-to-nightly”, I didn’t fully read the description of that label, it doesn’t apply.
Error: Label regression-from-stable-to-nightly can only be set by Rust team members Please let know if you're having trouble with this bot.
This can be reproduced outside the playground by adding to your . I suspect that this is caused by we now continue trait selection instead of bailing out when we see an error type. I think we'll want to re-add some kind of bail-out logic, but I'm not sure where the best place would be.
I can confirm regression at modify labels to -E-needs-bisection.
(This bug leaked into beta channel while waiting for PR to land, I think.)
Removing as this have been prioritized already.
This one is already on master and beta backported so closing it as fixed in both channels.
Change:
String::from("<identifier>: <type>"), Applicability::HasPlaceholders, ); <ins> } else if require_name && is_trait_item { if let PatKind::Ident(_, ident, _) = pat.node { err.span_suggestion_with_applicability( pat.span, "explicitly ignore parameter", format!("_: {}", ident), Applicability::MachineApplicable, ); } err.note("anonymous parameters are removed in the 2018 edition (see RFC 1685)"); </ins> } return Err(err);

Discussion:
This code works correctly on nightly and stable but not on 2018 edition, where it returns the error Changing it to solves it. Is this an intended change? I couldn't find anything about it in the edition guide.
Yes, this was done in
So apparently it was part of . In that case we should at least fix the error message, since it doesn't explain the source of the error at all.
Change:
borrows: flow_borrows, }; <del> if let Some(errors) = move_errors { mbcx.report_move_errors(errors); } </del> <ins> mbcx.report_move_errors(move_errors); </ins> dataflow::visit_results( &body,

Discussion:
I get an ICE when I try to build : I tried stable, beta and nightly. All ended with an ICE.
Important detail: Only happens on the branch, not
(bisecting)
It happens with master branch as well if I do before building. Without it, it fails due to nalgebra issue before it even gets to evolvim-lib.
Ah, I see
regression in nightly-2019-08-17
great :). Unsure if you're bisecting this further, anyway pinging cleanup crew in case you are not doing it further and also to see if someone is able to get an mcve. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
There don't seem to be any prebuilt artifacts for that commit range, so I've stopped there.
Assigning meanwhile we don't have an mcve as .
() Errors: modify labels to -E-needs-mcve
The reduced example regresses at nightly-2019-09-29 (..). Edit2: For me, evolvim (develop branch) regresses on that nightly, too. <br<br<details<summary<del<ttgit log</tt<iafter bisection</i</del</summary</detailsEdit3: Damn it, recompiling didn’t make realize that the code had to be recompiled and I didn’t really notice that it had just skipped compilation entirely all the time.
Even smaller: () Errors: <details</details
regression in commit (part of ) cc modify labels: -E-needs-bisection
Error: Label ICEBreaker-Cleanup-Crew can only be set by Rust team members Please let know if you're having trouble with this bot.
Error: Label ICEBreaker-Cleanup-Crew can only be set by Rust team members Please let know if you're having trouble with this bot.
Now that we have an -- thanks -- let's prioritize again
prioritize -- just testing the command
Error: This issue has already been requested for prioritization. Please let know if you're having trouble with this bot.

prioritize -- just testing the command
Looks like this compiles but it shouldn't: Dumping the MIR for this you get: Presumably, what should happen here is: The occurs here: cc
This issue is already prioritized as removing label.
I guess we need to track down where [S; 1] is emitted and make that code also look at the MIR of promoteds. We can't avoid that code from getting promoted without getting into an unfun game of whack-a-mole in the promotion code.
The error is constructed here: which is called here: and here:
hmmm... not sure what borrowck does to promoteds. I mean we basically declared all lifetimes to be static, but the same is true for the body of constants which we do run borrowck on. So... let's try to just run borrowck on promoteds and see how it goes.
alternatively we just run the logic on promoteds instead of full borrowck, as the latter may have a significant perf impact.
Change:
let tcx = self.tcx(); let trait_ref = cache_fresh_trait_pred.skip_binder().trait_ref; if self.can_use_global_caches(param_env) { <del> if let Some(trait_ref) = tcx.lift_to_global(&trait_ref) { </del> <ins> if let Err(Overflow) = candidate { // Don't cache overflow globally; we only produce this // in certain modes. } else if let Some(trait_ref) = tcx.lift_to_global(&trait_ref) { </ins> if let Some(candidate) = tcx.lift_to_global(&candidate) { debug!( "insert_candidate_cache(trait_ref={:?}, candidate={:?}) global",

Discussion:
Steps to reproduce:
I assume this is the same as
Running into this as well when running on 1.30.0-nightly ( 2018-08-05)
Hit this on the newest nightly ( 2018-08-18)
Same issue, slightly different line number Filtered log:
any idea what's going on here? let us know if you need T-compiler help :)
I didn't check yet, still on my todo list. I'll give it a look this week-end.
It would be great to have a minimized example here =)
True, I'll try to make one.
I think this is the same as as well
visited for triage. PR just needs to be landed.
Reopening; since we never backported , rustdoc ICE's on typenum again.
visiting for triage. It looks like PR is on target to be backported to stable. (In fact, the recent update of the labels to say just leads me to assume that the backport has occurred... yes, it was part of PR )
So, only two questions I have now: I openly mused to myself during this triage session that the failure to backport to beta sooner may represent a process failure of some sort. But there may be a very simple fix: Can/should we revise bors to not autoclose issues that are tagged as stable-to-beta or stable-to-stable regressions? Filed as barosl/homu On the subject of closing: Can we close this issue in light of ? Or do we need to wait until the 1.30.1 point release has officially been deployed?
Closed since 1.30.1 was released already.
Change:
error: unexpected token: `!` <del> --> $DIR/macro-expand-to-field.rs:16:10 </del> <ins> --> $DIR/macro-expand-to-field.rs:19:10 </ins> | <ins> LL | struct Struct { |        ------ while parsing this struct LL | </ins> LL |     field!(bar:u128), |          ^ unexpected token after this | = note: macros cannot expand to struct fields error: unexpected token: `!` <del> --> $DIR/macro-expand-to-field.rs:22:10 | LL |     field!(recovers:()), |          ^ unexpected token after this | = note: macros cannot expand to struct fields error: unexpected token: `!` --> $DIR/macro-expand-to-field.rs:28:12 </del> <ins> --> $DIR/macro-expand-to-field.rs:29:12 </ins> | LL |     variant!(whoops), |            ^ unexpected token after this

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-08-05 Regression in cc
This is probably because it recovers from it and gives the field no name. We should probably give it the macro's name instead I believe this is the offending line:
An alternative approach would be to directly throw an error instead of allowing the parser to continue, imo.
label -needs-triage
Change:
PatEnum(..) => match cx.tcx.def_map.borrow().find(&pat.id) { Some(&DefConst(..)) => <del> cx.tcx.sess.span_bug(pat.span, "static pattern should've  </del> <ins> cx.tcx.sess.span_bug(pat.span, "const pattern should've  </ins> been rewritten"), Some(&DefVariant(_, id, _)) => vec!(Variant(id)), _ => vec!(Single)

Discussion:
Minimal test case: If 1024 doesn’t do it for you, try bumping it upwards. ought to do it. Just don’t try numbers like a million or you’ll be waiting a while before it crashes. And if you have anything like systemd-coredump start automatically, it’ll be busy for a while as well… I guess there are a few areas where [T, ..N] is not handled well for large N. (Additional keywords: sized array.)
Running it under GDB shows that it’s flipping back and forth between two functions recursively: Whatever this recursive algorithm is needs to be made non-recursive.
There is a slight difference between this minimal test case, and the original issue . If I reduce the size of the array to 10 bytes in , compilation never completes (no error is raised). If I reduce the size of the array in this test case to 10 bytes, it compiles.
could you try to narrow down the test from , in the manner that chris-morgan has done here, but preserving the behavioral difference you are observing?
I will try my best (this lunchtime), but I only have three hours experience with Rust so far. Every few lines of code written or modified requires 15 minutes of Googling the docs. (This learning curve is still much less steep than Haskell's was.)
feel free to drop by , you’ll get any help you need there quickly.
I was mistaken. I had a subsequent, chained, command on the command line which produced no output and hung. I mistook this for the compiler hanging.
okay, great, thanks for the update! (I now feel better about asking you to do the narrowing rather than attempting to do it myself.) ;)
Change:
<ins> // run-rustfix // Parser should know when a semicolon is missing. // https://github.com/rust-lang/rust/issues/87197 fn main() { let x = 100 //~ ERROR: expected `;` println!("{}", x) //~ ERROR: expected `;` let y = 200 //~ ERROR: expected `;` println!("{}", y); } </ins>

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:
/* We have filled that place, so go further */ gap.write += 1; <ins> gap.read += 1; </ins> } <del> gap.read += 1; </del> } /* Technically we could let `gap` clean up with its Drop, but

Discussion:
is not updated (line 1636) when (line 1623) panics. This lets 's implementation to retain the already dropped element. The bug was introduced in and affects stable Rust versions = 1.52. Here is the that demonstrates the double free without using unsafe Rust code. <!-- 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. --:
label regression-from-stable-to-stable
Assigning as discussed by and removing . modify labels +P-critical -I-prioritize
Interestingly there was a test for this, but it is wrong. The vec contains the index=5, even though it is the item that panics in its drop implementation. I guess the author of this test thought that returned the new value instead of the old value?
Learning about a double-free I introduced, a year later... :eyes: And honestly, I can clearly remember that when the test was first written, it caught the bug, but I just assumed it was an off-by-one error in the testing code itself, yikes
Change:
<ins> error[E0412]: cannot find type `Foo` in this scope --> $DIR/issue-83510.rs:5:1 | LL | issue_83510::dance_like_you_want_to_ice!(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error[E0404]: expected trait, found struct `Box` --> $DIR/issue-83510.rs:5:1 | LL | issue_83510::dance_like_you_want_to_ice!(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not a trait | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error[E0405]: cannot find trait `Baz` in this scope --> $DIR/issue-83510.rs:5:1 | LL | issue_83510::dance_like_you_want_to_ice!(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope | = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error[E0658]: inherent associated types are unstable --> $DIR/issue-83510.rs:5:1 | LL | issue_83510::dance_like_you_want_to_ice!(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #8995 <https://github.com/rust-lang/rust/issues/8995> for more information = help: add `#![feature(inherent_associated_types)]` to the crate attributes to enable = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 4 previous errors Some errors have detailed explanations: E0404, E0405, E0412, E0658. For more information about an error, try `rustc --explain E0404`. </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. --With a procmacro, an ICE occurs when generating an block (whether for a trait or not) that has an associated type that looks like this: The type needs to be a valid (in scope) type that takes a generic parameter, with a trait/lifetime bound. Both the generic parameter and the trait/lifetime bound don't actually need to be in scope - just syntactically valid. I only found this after a typo ( instead of ); this code shouldn't compile without the ICE anyway - the trait/lifetime bound is on a concrete type. As a result, I cannot foresee a situation where valid code that should compile would fail to compile as a result of 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. --Occurs on latest stable, beta and nightly versions. : I have also tested this on a host running , and the ICE also occurs on that machine as well. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning and removing .
Change:
<ins> // Copyright 2017 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. #![feature(macro_vis_matcher)] macro_rules! foo { ($($p:vis)*) => {} //~ ERROR repetition matches empty token tree } foo!(a); </ins>

Discussion:
Test case: Compiling this stuck forever in the "expansion" pass. cc ( tracking issue). Since can match "nothing", the macro should error with "repetition matches empty token tree".
Change:
check_consistency(self, &[seg], ident.span, kind, initial_res, res); } Err(..) => { <del> assert!(initial_binding.is_none()); </del> let expected = kind.descr_expected(); let msg = format!("cannot find {} `{}` in this scope", expected, ident); let mut err = self.session.struct_span_err(ident.span, &msg);

Discussion:
Compiling this: Results in an ICE: Different error on nightly: Backtrace for stable:
triage: tagging as P-high for initial investigation as to severity. Doesn't seem like it warrants discussion at T-compiler meeting. Removing nomination tag.
I'll try to look at this during the weekend. This is not a regression, so the priority is probably not especially high.
Fixed in
Change:
<ins> error: expected identifier, found reserved identifier `_` --> $DIR/issue-91461.rs:2:7 | LL |     a(_:b:,) |       ^ expected identifier, found reserved identifier error: expected type, found `,` --> $DIR/issue-91461.rs:2:11 | LL |     a(_:b:,) |     -    -^ expected type |     |    | |     |    tried to parse a type due to this type ascription |     while parsing this struct | = note: `#![feature(type_ascription)]` lets you annotate an expression with a type: `<expr>: <type>` = note: see issue #23416 <https://github.com/rust-lang/rust/issues/23416> for more information error: expected type, found `,` --> $DIR/issue-91461.rs:2:11 | LL |     a(_:b:,) |          -^ expected type |          | |          tried to parse a type due to this type ascription | = note: `#![feature(type_ascription)]` lets you annotate an expression with a type: `<expr>: <type>` = note: see issue #23416 <https://github.com/rust-lang/rust/issues/23416> for more information error: aborting due to 3 previous errors </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : Affected versions: I tried nightly 2021-12-01 and stable 1.57 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
slightly simpler example not using attributes the name outside the parentheses and the name between the two colons can be arbitrary, the parentheses, underscore, and comma all appear to matter
I found a fix for this, but currently i am only emitting a suggestion for transforming the input into a struct: how do you guys think should i do a function suggestion? Should i just remove the parameter? Or should i remove the function suggestion altogether and just emit the struct suggestion? or something completely different? here is an example how the same diagnostic's output looks like for a more sane input:
I wouldn't give much thought to suggestions, as it's unlikely that a human will enter this input. So I would just remove the suggestions if they are most likely wrong. For example the struct suggestion is invalid code because structs cannot use as a field name (right?). And I'm not sure what kind of code would use two colons , it's most likely a weird typo, so a generic "unexpected token" error should be fine.
claim
Change:
Abi::C } }, <ins> // These ABI kinds are ignored on non-x86 Windows targets. // See https://docs.microsoft.com/en-us/cpp/cpp/argument-passing-and-naming-conventions // and the individual pages for __stdcall et al. Abi::Stdcall | Abi::Fastcall | Abi::Vectorcall | Abi::Thiscall => { if self.options.is_like_windows && self.arch != "x86" { Abi::C } else { abi } }, </ins> abi => abi } }

Discussion:
Compiling code like: results in: presumably because attempts to translate it into an x86-specific ABI, which the AArch64 backend rightly rejects. already ignores for non-x86 targets: I'm not completely sure what the right answer for Rust is. I think is the rough equivalent of the above clang bit and needs to take a few more cases into account for non-x86 Windows: does that sound right? If so, I'll code up a patch.
Sounds like a good place to me!
Change:
("riscv32" | "riscv64", "fast-unaligned-access") if get_version().0 <= 17 => { LLVMFeature::new("unaligned-scalar-mem") } <ins> // For LLVM 18, enable the evex512 target feature if a avx512 target feature is enabled. ("x86", s) if get_version().0 >= 18 && s.starts_with("avx512") => { LLVMFeature::with_dependency(s, TargetFeatureFoldStrength::EnableOnly("evex512")) } </ins> (_, s) => LLVMFeature::new(s), } }

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. --Compiling With nightly (2024-02-13) fails with nightly 2024-02-08 (with the stdsimd removal and stdarch addition) compiles fine Looks like the update to LLVM 18 could be the culprit <!-- 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. --: Here is the .ll file coming from the emit llvm ir (as recommended in another issue of the sort) changed extension so that github is not annoying about it (what a way to validate data blobs!) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Reduces to something like this:
Just wanted to take a moment and thank you warmly it's a pleasure to interact and work with you on those issues (even if it's only as a bug reporter ) Cheers
This fails: While this works: This also works: I think it's related to this change: It will automatically add only if generic target-cpu is used. I can't say that I understand the logic behind that change, but I guess this means we have to explicitly add in rustc when avx512 features are used.