jiebi/CodeConvo huggingface dataset:
Code change:
This code demonstrates the problem (): With stable-1.32.0 it prints . With beta-1.33.0 it wrongly prints . Beta also produces these wrong warnings: It seems that Rustc decides, that the first arm covers the whole range of a and optimizes out the other arms before they even reach MIR. The code is very similar to this . But the testcase does not test that the other arms can be reached. I was able to bisect the regression to . (This issue seems similar to , but the reduced testcase there does not use any associated consts)
Not the same as
triage: P-high, A-NLL, NLL-complete, assigning to self.
cc
I have confirmed that the bug appears to be specifically injected by commit (I've skimmed over that commit several times and still can't see the problem, but I'm going to try again now. Maybe the actual issue is that we are miscompiling downstream, but that pattern is not sufficiently exercised elsewhere in the compiler today...)
Well this is making my spidey-sense tingle: but even when that returns false, it seems like that would only imply that we fall through to presumably more general purpose code here: (still looking. Going to add a bit of instrumentation to these parts of the compiler.)
I don't mean to step on any toes, but I looked into this a little as an earlier PR of mine introduced it. I've got a fix up at but if that's not the approach we want to take then I can leave this to you.

Related discussion:
text: } } } <del> _ => PatternKind::Wild </del> <ins> ref pats => { self.tcx.sess.delay_span_bug( pat.span, &format!("found bad range pattern `{:?}` outside of error recovery", pats), ); PatternKind::Wild } </ins> } }
Code change:
This code demonstrates the problem (): With stable-1.32.0 it prints . With beta-1.33.0 it wrongly prints . Beta also produces these wrong warnings: It seems that Rustc decides, that the first arm covers the whole range of a and optimizes out the other arms before they even reach MIR. The code is very similar to this . But the testcase does not test that the other arms can be reached. I was able to bisect the regression to . (This issue seems similar to , but the reduced testcase there does not use any associated consts)
Not the same as
triage: P-high, A-NLL, NLL-complete, assigning to self.
cc
I have confirmed that the bug appears to be specifically injected by commit (I've skimmed over that commit several times and still can't see the problem, but I'm going to try again now. Maybe the actual issue is that we are miscompiling downstream, but that pattern is not sufficiently exercised elsewhere in the compiler today...)
Well this is making my spidey-sense tingle: but even when that returns false, it seems like that would only imply that we fall through to presumably more general purpose code here: (still looking. Going to add a bit of instrumentation to these parts of the compiler.)
I don't mean to step on any toes, but I looked into this a little as an earlier PR of mine introduced it. I've got a fix up at but if that's not the approach we want to take then I can leave this to you.

Related discussion:
text: <ins> // run-pass #![allow(dead_code)] trait Range { const FIRST: u8; const LAST: u8; } struct OneDigit; impl Range for OneDigit { const FIRST: u8 = 0; const LAST: u8 = 9; } struct TwoDigits; impl Range for TwoDigits { const FIRST: u8 = 10; const LAST: u8 = 99; } struct ThreeDigits; impl Range for ThreeDigits { const FIRST: u8 = 100; const LAST: u8 = 255; } fn digits(x: u8) -> u32 { match x { OneDigit::FIRST...OneDigit::LAST => 1, TwoDigits::FIRST...TwoDigits::LAST => 2, ThreeDigits::FIRST...ThreeDigits::LAST => 3, _ => unreachable!(), } } fn main() { assert_eq!(digits(100), 3); } </ins>
Code change:
std::collections::BinaryHeap is a max-heap. A very common use case for users will be to make a min-heap. The basic example should include a min-heap.
Do you think you would be able to make a PR based on e.g. ?
Added an example in

Related discussion:
text: /// // The heap should now be empty. /// assert!(heap.is_empty()) /// ``` <ins> /// /// ## Min-heap /// /// Either `std::cmp::Reverse` or a custom `Ord` implementation can be used to /// make `BinaryHeap` a min-heap. This makes `heap.pop()` return the smallest /// value instead of the greatest one. /// /// ``` /// use std::collections::BinaryHeap; /// use std::cmp::Reverse; /// /// let mut heap = BinaryHeap::new(); /// /// // Wrap values in `Reverse` /// heap.push(Reverse(1)); /// heap.push(Reverse(5)); /// heap.push(Reverse(2)); /// /// // If we pop these scores now, they should come back in the reverse order. /// assert_eq!(heap.pop(), Some(Reverse(1))); /// assert_eq!(heap.pop(), Some(Reverse(2))); /// assert_eq!(heap.pop(), Some(Reverse(5))); /// assert_eq!(heap.pop(), None); /// ``` </ins> #[stable(feature = "rust1", since = "1.0.0")] pub struct BinaryHeap<T> { data: Vec<T>,
Code change:
The following code generates some really awful LLVM IR: The same happens with . Cc who made me write these tests, and
Feels like an LLVM limitation to me. It should be replacing the with a (or a of poison when that becomes available).
For reference: LLVM is capable of optimizing a memcpy of undef alloca away, this just runs into the usual limitation that all of memcpyopt doesn't work across BBs.
This is such a long-standing issue. Seems like it might be wise to have someone working on fixing this.
Someone has already worked on this, see It's a bit hard to track, but unfortunately this got reverted again (multiple times). I suspect that this is only going to get really resolved once memcpyopt moves to memssa -- which someone has also worked on in the past (), but which never really went anywhere.
The alloca and memcpy are no longer present on nightly, as a result of .
The FIXME in the test is still there, needs a test.

Related discussion:
text: // Once we're done with llvm 14 and earlier, this test can be deleted. <del> #![crate_type="lib"] </del> <ins> #![crate_type = "lib"] </ins> use std::mem::MaybeUninit;
Code change:
The following code generates some really awful LLVM IR: The same happens with . Cc who made me write these tests, and
Feels like an LLVM limitation to me. It should be replacing the with a (or a of poison when that becomes available).
For reference: LLVM is capable of optimizing a memcpy of undef alloca away, this just runs into the usual limitation that all of memcpyopt doesn't work across BBs.
This is such a long-standing issue. Seems like it might be wise to have someone working on fixing this.
Someone has already worked on this, see It's a bit hard to track, but unfortunately this got reverted again (multiple times). I suspect that this is only going to get really resolved once memcpyopt moves to memssa -- which someone has also worked on in the past (), but which never really went anywhere.
The alloca and memcpy are no longer present on nightly, as a result of .
The FIXME in the test is still there, needs a test.

Related discussion:
text: Box::new(MaybeUninit::uninit()) } <del> // FIXME: add a test for a bigger box. Currently broken, see // https://github.com/rust-lang/rust/issues/58201. </del> <ins> // https://github.com/rust-lang/rust/issues/58201 #[no_mangle] pub fn box_uninitialized2() -> Box<MaybeUninit<[usize; 1024 * 1024]>> { // CHECK-LABEL: @box_uninitialized2 // CHECK-NOT: store // CHECK-NOT: alloca // CHECK-NOT: memcpy // CHECK-NOT: memset Box::new(MaybeUninit::uninit()) } </ins> // Hide the LLVM 15+ `allocalign` attribute in the declaration of __rust_alloc // from the CHECK-NOT above. We don't check the attributes here because we can't rely
Code change:
The following code generates some really awful LLVM IR: The same happens with . Cc who made me write these tests, and
Feels like an LLVM limitation to me. It should be replacing the with a (or a of poison when that becomes available).
For reference: LLVM is capable of optimizing a memcpy of undef alloca away, this just runs into the usual limitation that all of memcpyopt doesn't work across BBs.
This is such a long-standing issue. Seems like it might be wise to have someone working on fixing this.
Someone has already worked on this, see It's a bit hard to track, but unfortunately this got reverted again (multiple times). I suspect that this is only going to get really resolved once memcpyopt moves to memssa -- which someone has also worked on in the past (), but which never really went anywhere.
The alloca and memcpy are no longer present on nightly, as a result of .
The FIXME in the test is still there, needs a test.

Related discussion:
text: // compile-flags: -O // min-llvm-version: 15.0 <del> #![crate_type="lib"] </del> <ins> #![crate_type = "lib"] </ins> use std::mem::MaybeUninit;
Code change:
The following code generates some really awful LLVM IR: The same happens with . Cc who made me write these tests, and
Feels like an LLVM limitation to me. It should be replacing the with a (or a of poison when that becomes available).
For reference: LLVM is capable of optimizing a memcpy of undef alloca away, this just runs into the usual limitation that all of memcpyopt doesn't work across BBs.
This is such a long-standing issue. Seems like it might be wise to have someone working on fixing this.
Someone has already worked on this, see It's a bit hard to track, but unfortunately this got reverted again (multiple times). I suspect that this is only going to get really resolved once memcpyopt moves to memssa -- which someone has also worked on in the past (), but which never really went anywhere.
The alloca and memcpy are no longer present on nightly, as a result of .
The FIXME in the test is still there, needs a test.

Related discussion:
text: Box::new(MaybeUninit::uninit()) } <del> // FIXME: add a test for a bigger box. Currently broken, see // https://github.com/rust-lang/rust/issues/58201. </del> <ins> // https://github.com/rust-lang/rust/issues/58201 #[no_mangle] pub fn box_uninitialized2() -> Box<MaybeUninit<[usize; 1024 * 1024]>> { // CHECK-LABEL: @box_uninitialized2 // CHECK-NOT: store // CHECK-NOT: alloca // CHECK-NOT: memcpy // CHECK-NOT: memset Box::new(MaybeUninit::uninit()) } </ins> // Hide the `allocalign` attribute in the declaration of __rust_alloc // from the CHECK-NOT above, and also verify the attributes got set reasonably.
Code change:
Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.

Related discussion:
text: <ins> // build-fail // ignore-emscripten no asm! support // Regression test for #69092 #![feature(asm)] fn main() { unsafe { asm!(".ascii "Xen0""); } //~^ ERROR: <inline asm>:1:9: error: expected string in '.ascii' directive } </ins>
Code change:
Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.

Related discussion:
text: <ins> error: <inline asm>:1:9: error: expected string in '.ascii' directive .ascii "Xen ^ --> $DIR/issue-69092.rs:8:14 | LL |     unsafe { asm!(".ascii "Xen0""); } |              ^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>
Code change:
Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.

Related discussion:
text: <ins> // Regression test for #62504 #![feature(const_generics)] #![allow(incomplete_features)] trait HasSize { const SIZE: usize; } impl<const X: usize> HasSize for ArrayHolder<{ X }> { const SIZE: usize = X; } struct ArrayHolder<const X: usize>([u32; X]); impl<const X: usize> ArrayHolder<{ X }> { pub const fn new() -> Self { ArrayHolder([0; Self::SIZE]) //~^ ERROR: array lengths can't depend on generic parameters } } fn main() { let mut array = ArrayHolder::new(); } </ins>
Code change:
Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.

Related discussion:
text: <ins> error: array lengths can't depend on generic parameters --> $DIR/issue-62504.rs:18:25 | LL |         ArrayHolder([0; Self::SIZE]) |                         ^^^^^^^^^^ error: aborting due to previous error </ins>
Code change:
Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.

Related discussion:
text: <ins> // Regression test for #67739 #![allow(incomplete_features)] #![feature(const_generics)] use std::mem; pub trait Trait { type Associated: Sized; fn associated_size(&self) -> usize { [0u8; mem::size_of::<Self::Associated>()]; //~^ ERROR: array lengths can't depend on generic parameters 0 } } fn main() {} </ins>
Code change:
Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.

Related discussion:
text: <ins> error: array lengths can't depend on generic parameters --> $DIR/issue-67739.rs:12:15 | LL |         [0u8; mem::size_of::<Self::Associated>()]; |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>
Code change:
Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.

Related discussion:
text: <ins> // Regression test for #58490 macro_rules! a { ( @1 $i:item ) => { a! { @2 $i } }; ( @2 $i:item ) => { $i }; } mod b { a! { @1 #[macro_export] macro_rules! b { () => () } } #[macro_export] macro_rules! b { () => () } //~^ ERROR: the name `b` is defined multiple times } mod c { #[allow(unused_imports)] use crate::b; } fn main() {} </ins>
Code change:
Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.

Related discussion:
text: <ins> error[E0428]: the name `b` is defined multiple times --> $DIR/issue-58490.rs:18:5 | LL |         macro_rules! b { () => () } |         -------------- previous definition of the macro `b` here ... LL |     macro_rules! b { () => () } |     ^^^^^^^^^^^^^^ `b` redefined here | = note: `b` must be defined only once in the macro namespace of this module error: aborting due to previous error For more information about this error, try `rustc --explain E0428`. </ins>
Code change:
Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.

Related discussion:
text: <ins> // check-pass // compile-flags: --emit=mir,link // Regression test for #60390, this ICE requires `--emit=mir` flag. fn main() { enum Inner { Member(u32) }; Inner::Member(0); } </ins>
Code change:
For the following code: We get the following diagnostics: Notice that the String expression correctly suggests removing the borrow, but the expression incorrectly suggests adding , which does not fix the error.

Related discussion:
text: // Maybe remove `&`? hir::ExprKind::AddrOf(_, ref expr) => { if !cm.span_to_filename(expr.span).is_real() { <ins> if let Ok(code) = cm.span_to_snippet(sp) { if code.chars().next() == Some('&') { return Some(( sp, "consider removing the borrow", code[1..].to_string()), ); } } </ins> return None; } if let Ok(code) = cm.span_to_snippet(expr.span) {
Code change:
For the following code: We get the following diagnostics: Notice that the String expression correctly suggests removing the borrow, but the expression incorrectly suggests adding , which does not fix the error.

Related discussion:
text: LL | fn main() { |           - expected `()` because of default return type LL |     &panic!() <del> |     ^^^^^^^^^ expected (), found reference </del> <ins> |     ^^^^^^^^^ |     | |     expected (), found reference |     help: consider removing the borrow: `panic!()` </ins> | = note: expected type `()` found type `&_`
Code change:
For the following code: We get the following diagnostics: Notice that the String expression correctly suggests removing the borrow, but the expression incorrectly suggests adding , which does not fix the error.

Related discussion:
text: error[E0308]: mismatched types --> $DIR/diverging-tuple-parts-39485.rs:8:5 | <del> LL | fn g() { |        - help: try adding a return type: `-> &_` </del> LL |     &panic!() //~ ERROR mismatched types |     ^^^^^^^^^ expected (), found reference | = note: expected type `()` found type `&_` <ins> help: try adding a return type | LL | fn g() -> &_ { |        ^^^^^ help: consider removing the borrow | LL |     panic!() //~ ERROR mismatched types |     ^^^^^^^^ </ins> error[E0308]: mismatched types --> $DIR/diverging-tuple-parts-39485.rs:12:5
Code change:
For the following code: We get the following diagnostics: Notice that the String expression correctly suggests removing the borrow, but the expression incorrectly suggests adding , which does not fix the error.

Related discussion:
text: <ins> fn main() { let a: String = &String::from("a"); //~^ ERROR mismatched types let b: String = &format!("b"); //~^ ERROR mismatched types } </ins>
Code change:
For the following code: We get the following diagnostics: Notice that the String expression correctly suggests removing the borrow, but the expression incorrectly suggests adding , which does not fix the error.

Related discussion:
text: <ins> error[E0308]: mismatched types --> $DIR/format-borrow.rs:2:21 | LL |     let a: String = &String::from("a"); |                     ^^^^^^^^^^^^^^^^^^ |                     | |                     expected struct `std::string::String`, found reference |                     help: consider removing the borrow: `String::from("a")` | = note: expected type `std::string::String` found type `&std::string::String` error[E0308]: mismatched types --> $DIR/format-borrow.rs:4:21 | LL |     let b: String = &format!("b"); |                     ^^^^^^^^^^^^^ |                     | |                     expected struct `std::string::String`, found reference |                     help: consider removing the borrow: `format!("b")` | = note: expected type `std::string::String` found type `&std::string::String` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>
Code change:
ICEes when trying to compile the following code. As far as I can tell, the issue is due to the HRTB. All other issues I found mentioning where either using unstable features and/or related to which seems to be unrelated to this issue. On the playground, I am able to reproduce the ICE on stable (1.33), beta, and nightly. Locally I have the following setup: : Backtrace:
Triage: Reproduces as of 2020-03-10.
Triage: This ICE has been fixed in the latest nightly, I assume it's fixed by . Marking as .

Related discussion:
text: <ins> // Regression test for #59311. The test is taken from // rust-lang/rust/issues/71546#issuecomment-620638437 // as they seem to have the same cause. // FIXME: It's not clear that this code ought to report // an error, but the regression test is here to ensure // that it does not ICE. See discussion on #74889 for details. pub trait T { fn t<F: Fn()>(&self, _: F) {} } pub fn crash<V>(v: &V) where for<'a> &'a V: T + 'static, { v.t(|| {}); //~ ERROR: higher-ranked subtype error } fn main() {} </ins>
Code change:
ICEes when trying to compile the following code. As far as I can tell, the issue is due to the HRTB. All other issues I found mentioning where either using unstable features and/or related to which seems to be unrelated to this issue. On the playground, I am able to reproduce the ICE on stable (1.33), beta, and nightly. Locally I have the following setup: : Backtrace:
Triage: Reproduces as of 2020-03-10.
Triage: This ICE has been fixed in the latest nightly, I assume it's fixed by . Marking as .

Related discussion:
text: <ins> error: higher-ranked subtype error --> $DIR/issue-59311.rs:17:9 | LL |     v.t(|| {}); |         ^^^^^ error: aborting due to previous error </ins>
Code change:
The default edition is 2015, but the option to change this in the "extended" list, so it is only discoverable with , rather than just . Users should be encouraged to use 2018 where possible, but the omission of the edition from the default help list makes it less likely that it will be found for users not using Cargo.

Related discussion:
text: "Specify the name of the crate being built", "NAME", ), <ins> opt::opt_s( "", "edition", "Specify which edition of the compiler to use when compiling code.", EDITION_NAME_LIST, ), </ins> opt::multi_s( "", "emit",