jiebi/CodeConvo huggingface dataset:
Code change:
<!-- 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
I used this to make some warnings/errors go away: Regressed in cc modify labels: regression-from-stable-to-nightly

Related discussion:
text: <ins> error[E0038]: the trait `T` cannot be made into an object --> $DIR/issue-87495.rs:4:25 | LL |     const CONST: (bool, dyn T); |                         ^^^^^ `T` cannot be made into an object | = help: consider moving `CONST` to another trait note: for a trait to be "object safe" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety> --> $DIR/issue-87495.rs:4:11 | LL | trait T { |       - this trait cannot be made into an object... LL |     const CONST: (bool, dyn T); |           ^^^^^ ...because it contains this associated `const` error: aborting due to previous error For more information about this error, try `rustc --explain E0038`. </ins>
Code change:
<!-- 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. --When trying to compile this incorrect code using cargo, nightly rustc panics. When compiling using rustc directly without further arguments (or using the same command cargo calls with removed), it outputs an error message instead. I also noticed that changing to will also result in an error message instead of a panic. <!-- 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
I seem to have run into the same issue with this code: <details<summaryBacktrace</summary</details
I believe these ICEs trigger because of / are made visible by cc
I'm not able to repro this with rustc 1.56.0-nightly ( 2021-08-02): Could you verify that you see it with a recent nightly? There have been significant changes in this area recently. Edit: ah! with enabled I see it:
I am able to reproduce my issue and the other one on by simply running :

Related discussion:
text: if let ObligationCauseCode::WellFormed(Some(wf_loc)) = root_obligation.cause.code.peel_derives() { <del> if let Some(cause) = self.tcx.diagnostic_hir_wf_check((obligation.predicate, wf_loc.clone())) { </del> <ins> if let Some(cause) = self.tcx.diagnostic_hir_wf_check(( tcx.erase_regions(obligation.predicate), wf_loc.clone(), )) { </ins> obligation.cause = cause; span = obligation.cause.span; }
Code change:
<!-- 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. --When trying to compile this incorrect code using cargo, nightly rustc panics. When compiling using rustc directly without further arguments (or using the same command cargo calls with removed), it outputs an error message instead. I also noticed that changing to will also result in an error message instead of a panic. <!-- 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
I seem to have run into the same issue with this code: <details<summaryBacktrace</summary</details
I believe these ICEs trigger because of / are made visible by cc
I'm not able to repro this with rustc 1.56.0-nightly ( 2021-08-02): Could you verify that you see it with a recent nightly? There have been significant changes in this area recently. Edit: ah! with enabled I see it:
I am able to reproduce my issue and the other one on by simply running :

Related discussion:
text: <ins> // Regression test for #87549. // compile-flags: -C incremental=tmp/wf/hir-wf-check-erase-regions pub struct Table<T, const N: usize>([Option<T>; N]); impl<'a, T, const N: usize> IntoIterator for &'a Table<T, N> { type IntoIter = std::iter::Flatten<std::slice::Iter<'a, T>>; //~ ERROR `&T` is not an iterator type Item = &'a T; fn into_iter(self) -> Self::IntoIter { //~ ERROR `&T` is not an iterator unimplemented!() } } fn main() {} </ins>
Code change:
<!-- 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. --When trying to compile this incorrect code using cargo, nightly rustc panics. When compiling using rustc directly without further arguments (or using the same command cargo calls with removed), it outputs an error message instead. I also noticed that changing to will also result in an error message instead of a panic. <!-- 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
I seem to have run into the same issue with this code: <details<summaryBacktrace</summary</details
I believe these ICEs trigger because of / are made visible by cc
I'm not able to repro this with rustc 1.56.0-nightly ( 2021-08-02): Could you verify that you see it with a recent nightly? There have been significant changes in this area recently. Edit: ah! with enabled I see it:
I am able to reproduce my issue and the other one on by simply running :

Related discussion:
text: <ins> error[E0277]: `&T` is not an iterator --> $DIR/hir-wf-check-erase-regions.rs:7:5 | LL |     type IntoIter = std::iter::Flatten<std::slice::Iter<'a, T>>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `&T` is not an iterator | ::: $SRC_DIR/core/src/iter/adapters/flatten.rs:LL:COL | LL | pub struct Flatten<I: Iterator<Item: IntoIterator>> { |                                      ------------ required by this bound in `Flatten` | = help: the trait `Iterator` is not implemented for `&T` = note: required because of the requirements on the impl of `IntoIterator` for `&T` error[E0277]: `&T` is not an iterator --> $DIR/hir-wf-check-erase-regions.rs:10:27 | LL |     fn into_iter(self) -> Self::IntoIter { |                           ^^^^^^^^^^^^^^ `&T` is not an iterator | ::: $SRC_DIR/core/src/iter/adapters/flatten.rs:LL:COL | LL | pub struct Flatten<I: Iterator<Item: IntoIterator>> { |                                      ------------ required by this bound in `Flatten` | = help: the trait `Iterator` is not implemented for `&T` = note: required because of the requirements on the impl of `IntoIterator` for `&T` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>
Code change:
The following ICE was found migrating 0.26.0 and  0.4.38. cc which was an error on the same line, though I think the cause is slightly different. Note that I think this is also triggering an incorrect lint for the parameter (the actual code uses the parameter). <!-- 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</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: if def.variants.len() > 1 { needs_to_be_read = true; } <ins> } else { // If it is not ty::Adt, then it should be read needs_to_be_read = true; </ins> } } PatKind::Lit(_) | PatKind::Range(..) => {
Code change:
The following ICE was found migrating 0.26.0 and  0.4.38. cc which was an error on the same line, though I think the cause is slightly different. Note that I think this is also triggering an incorrect lint for the parameter (the actual code uses the parameter). <!-- 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</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: <ins> // run-pass // edition:2021 const LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED: i32 = 0x01; const LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT: i32 = 0x02; pub fn hotplug_callback(event: i32) { let _ = || { match event { LIBUSB_HOTPLUG_EVENT_DEVICE_ARRIVED => (), LIBUSB_HOTPLUG_EVENT_DEVICE_LEFT => (), _ => (), }; }; } fn main() { hotplug_callback(1); } </ins>
Code change:
The following ICE was found migrating 0.26.0 and  0.4.38. cc which was an error on the same line, though I think the cause is slightly different. Note that I think this is also triggering an incorrect lint for the parameter (the actual code uses the parameter). <!-- 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</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Related discussion:
text: <ins> // run-pass // edition:2021 const PATTERN_REF: &str = "Hello World"; const NUMBER: i32 = 30; const NUMBER_POINTER: *const i32 = &NUMBER; pub fn edge_case_ref(event: &str) { let _ = || { match event { PATTERN_REF => (), _ => (), }; }; } pub fn edge_case_str(event: String) { let _ = || { match event.as_str() { "hello" => (), _ => (), }; }; } pub fn edge_case_raw_ptr(event: *const i32) { let _ = || { match event { NUMBER_POINTER => (), _ => (), }; }; } pub fn edge_case_char(event: char) { let _ = || { match event { 'a' => (), _ => (), }; }; } fn main() {} </ins>
Code change:
The following is minimized from , which is regressed as of nightly-2021-08-15.
Relevant commit range is Of the 9 landed PRs, the ones that look potentially relevant to codegen are and .
I tried all the merge commits in order of merge: : pass : pass : pass : pass : pass : pass : pass : pass : regressed so that narrows this down to (
This passes under Miri, so I suspect that we've exposed an LLVM bug.
Not sure it's an LLVM bug because it seems the IR is broken even before any LLVM passes. I tried: Before: After: Diff: The looks like legitimately broken input IR. Notice the extractvalue insts relocated from the front of bb4 to the end of bb0 (invalidly after the terminator). What in LLVM is actually running during a -Cno-prepopulate-passes build?
I think we should do a quick revert and then figure this out without any pressure
the mir changes are that seems totally reasonable, so we need to check what codegen_llvm makes of it
I wonder why the goto collapse only happens if the zst assignment is eliminated. it seems like we need to preserve bb4 in mir or inject it in codegen_llvm, but first we should find out why the goto collapse is happening at all
There are no control-flow simplification passes after removal of dead local variables, which is why it didn't happen so far. Still, it seems a bit surprising it wasn't reported earlier: Adding a new cleanup pass before codegen would be one way to address this.
I swear half of my PRs break the compiler I'm excited for what bugs arise when we start using undef for uninitialized consts... Revert PR:
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
The issue was not fixed, it is an LLVM crash on stable as shows
Relabeling regression because worked in 1.51.0. It bisects to nightly-2021-03-02 ().
is the only codegen change in that nightly.
Reopening to track the stable-to-stable regression.
Backport was merged.

Related discussion:
text: impl AddCallGuards { pub fn add_call_guards(&self, body: &mut Body<'_>) { <del> let pred_count: IndexVec<_, _> = body.predecessors().iter().map(|ps| ps.len()).collect(); </del> <ins> let mut pred_count: IndexVec<_, _> = body.predecessors().iter().map(|ps| ps.len()).collect(); pred_count[START_BLOCK] += 1; </ins> // We need a place to store the new blocks generated let mut new_blocks = Vec::new();
Code change:
The following is minimized from , which is regressed as of nightly-2021-08-15.
Relevant commit range is Of the 9 landed PRs, the ones that look potentially relevant to codegen are and .
I tried all the merge commits in order of merge: : pass : pass : pass : pass : pass : pass : pass : pass : regressed so that narrows this down to (
This passes under Miri, so I suspect that we've exposed an LLVM bug.
Not sure it's an LLVM bug because it seems the IR is broken even before any LLVM passes. I tried: Before: After: Diff: The looks like legitimately broken input IR. Notice the extractvalue insts relocated from the front of bb4 to the end of bb0 (invalidly after the terminator). What in LLVM is actually running during a -Cno-prepopulate-passes build?
I think we should do a quick revert and then figure this out without any pressure
the mir changes are that seems totally reasonable, so we need to check what codegen_llvm makes of it
I wonder why the goto collapse only happens if the zst assignment is eliminated. it seems like we need to preserve bb4 in mir or inject it in codegen_llvm, but first we should find out why the goto collapse is happening at all
There are no control-flow simplification passes after removal of dead local variables, which is why it didn't happen so far. Still, it seems a bit surprising it wasn't reported earlier: Adding a new cleanup pass before codegen would be one way to address this.
I swear half of my PRs break the compiler I'm excited for what bugs arise when we start using undef for uninitialized consts... Revert PR:
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
The issue was not fixed, it is an LLVM crash on stable as shows
Relabeling regression because worked in 1.51.0. It bisects to nightly-2021-03-02 ().
is the only codegen change in that nightly.
Reopening to track the stable-to-stable regression.
Backport was merged.

Related discussion:
text: // CHECK-LABEL: @main fn main() { take_until(|| true); <ins> f(None); </ins> } <ins> fn f(_a: Option<String>) -> Option<u32> { loop { g(); () } } fn g() -> Option<u32> { None } </ins>
Code change:
fixed but this issue still fails: Found trying to migrate . Let me know if you need any more information. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign
The culprit is
Let me know how I can provide assistance on this one
label +A-closures +A-edition-2021 +T-compiler +I-ICE
claim
This seems like a similar problem as . We end up at a point where we to determine type of a variable and end up returning early without possibly capturing.
release-assignment
claim
Reopening -- I was able to trigger this on rustc_errors: Going to try to minify...
Triggers with the following (rustc --edition=2021), both on beta and nightly. I think this requires if let guards, though.
We ICE after attempting to resolve the for here: I believe we recently the option to have in pattern matching arms, but we never consumed the expression when "visiting" the arm leading us to not "read" and hence not being able to resolve it. cc:

Related discussion:
text: if let Some(hir::Guard::If(ref e)) = arm.guard { self.consume_expr(e) <ins> } else if let Some(hir::Guard::IfLet(_, ref e)) = arm.guard { self.consume_expr(e) </ins> } self.consume_expr(&arm.body);
Code change:
fixed but this issue still fails: Found trying to migrate . Let me know if you need any more information. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign
The culprit is
Let me know how I can provide assistance on this one
label +A-closures +A-edition-2021 +T-compiler +I-ICE
claim
This seems like a similar problem as . We end up at a point where we to determine type of a variable and end up returning early without possibly capturing.
release-assignment
claim
Reopening -- I was able to trigger this on rustc_errors: Going to try to minify...
Triggers with the following (rustc --edition=2021), both on beta and nightly. I think this requires if let guards, though.
We ICE after attempting to resolve the for here: I believe we recently the option to have in pattern matching arms, but we never consumed the expression when "visiting" the arm leading us to not "read" and hence not being able to resolve it. cc:

Related discussion:
text: <ins> // edition:2021 // run-pass #![feature(if_let_guard)] #[allow(unused_must_use)] #[allow(dead_code)] fn print_error_count(registry: &Registry) { |x: &Registry| { match &x { Registry if let _ = registry.try_find_description() => { } //~^ WARNING: irrefutable `if let` guard pattern _ => {} } }; } struct Registry; impl Registry { pub fn try_find_description(&self) { unimplemented!() } } fn main() {} </ins>
Code change:
fixed but this issue still fails: Found trying to migrate . Let me know if you need any more information. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
assign
The culprit is
Let me know how I can provide assistance on this one
label +A-closures +A-edition-2021 +T-compiler +I-ICE
claim
This seems like a similar problem as . We end up at a point where we to determine type of a variable and end up returning early without possibly capturing.
release-assignment
claim
Reopening -- I was able to trigger this on rustc_errors: Going to try to minify...
Triggers with the following (rustc --edition=2021), both on beta and nightly. I think this requires if let guards, though.
We ICE after attempting to resolve the for here: I believe we recently the option to have in pattern matching arms, but we never consumed the expression when "visiting" the arm leading us to not "read" and hence not being able to resolve it. cc:

Related discussion:
text: <ins> warning: irrefutable `if let` guard pattern --> $DIR/issue-88118-2.rs:10:29 | LL |             Registry if let _ = registry.try_find_description() => { } |                             ^ | = note: `#[warn(irrefutable_let_patterns)]` on by default = note: this pattern will always match, so the guard is useless = help: consider removing the guard and adding a `let` inside the match arm warning: 1 warning emitted </ins>
Code change:
Obviously a corner case. This would never actually be used for anything, this is just testing the bounds of what the compiler is capable of. Running this Ruby method with numarguments or greater generates a Rust file which can be used to reproduce the output. (via ) : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +regression-from-stable-to-beta
Nothing that Ruby code can achieve that Rust macros couldn't do as well: ()
Haha, just tried out a different direction of “many arguments”. Apparently this results in a segfault, AFAICT It’s explicitly a stack overflow on stable (and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety). <hrEdit: Opened this as a separate issue
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

Related discussion:
text: } fn check_fn_decl(&self, fn_decl: &FnDecl, self_semantic: SelfSemantic) { <ins> self.check_decl_num_args(fn_decl); </ins> self.check_decl_cvaradic_pos(fn_decl); self.check_decl_attrs(fn_decl); self.check_decl_self_param(fn_decl, self_semantic); } <ins> /// Emits fatal error if function declaration has more than `u16::MAX` arguments /// Error is fatal to prevent errors during typechecking fn check_decl_num_args(&self, fn_decl: &FnDecl) { let max_num_args: usize = u16::MAX.into(); if fn_decl.inputs.len() > max_num_args { let Param { span, .. } = fn_decl.inputs[0]; self.err_handler().span_fatal( span, &format!("function can not have more than {} arguments", max_num_args), ); } } </ins> fn check_decl_cvaradic_pos(&self, fn_decl: &FnDecl) { match &*fn_decl.inputs { [Param { ty, span, .. }] => {
Code change:
Obviously a corner case. This would never actually be used for anything, this is just testing the bounds of what the compiler is capable of. Running this Ruby method with numarguments or greater generates a Rust file which can be used to reproduce the output. (via ) : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +regression-from-stable-to-beta
Nothing that Ruby code can achieve that Rust macros couldn't do as well: ()
Haha, just tried out a different direction of “many arguments”. Apparently this results in a segfault, AFAICT It’s explicitly a stack overflow on stable (and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety). <hrEdit: Opened this as a separate issue
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

Related discussion:
text: <ins> macro_rules! many_args { ([$($t:tt)*]#$($h:tt)*) => { many_args!{[$($t)*$($t)*]$($h)*} }; ([$($t:tt)*]) => { fn _f($($t: ()),*) {} //~ ERROR function can not have more than 65535 arguments } } many_args!{[_]########## ######} fn main() {} </ins>
Code change:
Obviously a corner case. This would never actually be used for anything, this is just testing the bounds of what the compiler is capable of. Running this Ruby method with numarguments or greater generates a Rust file which can be used to reproduce the output. (via ) : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +regression-from-stable-to-beta
Nothing that Ruby code can achieve that Rust macros couldn't do as well: ()
Haha, just tried out a different direction of “many arguments”. Apparently this results in a segfault, AFAICT It’s explicitly a stack overflow on stable (and AFAIK segfaults can happen on stack overflow in sound rust code, so maybe it isn’t some memory unsafety). <hrEdit: Opened this as a separate issue
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low

Related discussion:
text: <ins> error: function can not have more than 65535 arguments --> $DIR/issue-88577-check-fn-with-more-than-65535-arguments.rs:6:24 | LL |           fn _f($($t: ()),*) {} |  ________________________^ LL | |     } LL | | } LL | | LL | | many_args!{[_]########## ######} | |____________^ error: aborting due to previous error </ins>