Question:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.

<ins> #![feature(const_let)] static mut STDERR_BUFFER_SPACE: u8 = 0; pub static mut STDERR_BUFFER: () = unsafe { *(&mut STDERR_BUFFER_SPACE) = 42; }; //~^ ERROR references in statics may only refer to immutable values //~| ERROR static contains unimplemented expression type fn main() {} </ins>


Question:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.

<ins> error[E0017]: references in statics may only refer to immutable values --> $DIR/static_mut_containing_mut_ref2.rs:5:46 | LL | pub static mut STDERR_BUFFER: () = unsafe { *(&mut STDERR_BUFFER_SPACE) = 42; }; |                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^ statics require immutable values error[E0019]: static contains unimplemented expression type --> $DIR/static_mut_containing_mut_ref2.rs:5:45 | LL | pub static mut STDERR_BUFFER: () = unsafe { *(&mut STDERR_BUFFER_SPACE) = 42; }; |                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors Some errors occurred: E0017, E0019. For more information about an error, try `rustc --explain E0017`. </ins>


Question:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.

<ins> #![feature(const_let)] static mut FOO: (u8, u8) = (42, 43); static mut BAR: () = unsafe { FOO.0 = 99; }; //~^ ERROR could not evaluate static initializer fn main() {} </ins>


Question:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.

<ins> error[E0080]: could not evaluate static initializer --> $DIR/static_mut_containing_mut_ref3.rs:5:31 | LL | static mut BAR: () = unsafe { FOO.0 = 99; }; |                               ^^^^^^^^^^ tried to modify a static's initial value from another static's initializer error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </ins>


Question:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.

pub static mut A: u32 = 0; pub static mut B: () = unsafe { A = 1; }; <del> //~^ ERROR cannot mutate statics in the initializer of another static </del> <ins> //~^ ERROR could not evaluate static initializer </ins> pub static mut C: u32 = unsafe { C = 1; 0 }; <del> //~^ ERROR cannot mutate statics in the initializer of another static </del> <ins> //~^ ERROR cycle detected </ins> pub static D: u32 = D;


Question:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.

<del> error: cannot mutate statics in the initializer of another static </del> <ins> error[E0080]: could not evaluate static initializer </ins> --> $DIR/write-to-static-mut-in-static.rs:14:33 | LL | pub static mut B: () = unsafe { A = 1; }; <del> |                                 ^^^^^ </del> <ins> |                                 ^^^^^ tried to modify a static's initial value from another static's initializer </ins> <del> error: cannot mutate statics in the initializer of another static </del> <ins> error[E0391]: cycle detected when const-evaluating `C` </ins> --> $DIR/write-to-static-mut-in-static.rs:17:34 | LL | pub static mut C: u32 = unsafe { C = 1; 0 }; |                                  ^^^^^ <ins> | note: ...which requires const-evaluating `C`... --> $DIR/write-to-static-mut-in-static.rs:17:1 | LL | pub static mut C: u32 = unsafe { C = 1; 0 }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = note: ...which again requires const-evaluating `C`, completing the cycle note: cycle used when const-evaluating + checking `C` --> $DIR/write-to-static-mut-in-static.rs:17:1 | LL | pub static mut C: u32 = unsafe { C = 1; 0 }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </ins> error: aborting due to 2 previous errors <ins> Some errors occurred: E0080, E0391. For more information about an error, try `rustc --explain E0080`. </ins>


Question:
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.

}, } <ins> impl<'tcx> PatternKind<'tcx> { /// If this is a `PatternKind::AscribeUserType` then return the subpattern kind, otherwise /// return this pattern kind. fn with_user_type_ascription_subpattern(self) -> Self { match self { PatternKind::AscribeUserType { subpattern: Pattern { box kind, ..  }, ..  } => kind, kind => kind, } } } </ins> #[derive(Clone, Copy, Debug, PartialEq)] pub struct PatternRange<'tcx> { pub lo: ty::Const<'tcx>,


Question:
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.

PatKind::Lit(ref value) => self.lower_lit(value), PatKind::Range(ref lo_expr, ref hi_expr, end) => { <del> match (self.lower_lit(lo_expr), self.lower_lit(hi_expr)) { (PatternKind::Constant { value: lo }, PatternKind::Constant { value: hi }) => { </del> <ins> match ( // Look for `PatternKind::Constant` patterns inside of any // `PatternKind::AscribeUserType` patterns. Type ascriptions can be safely // ignored for the purposes of lowering a range correctly - these are checked // elsewhere for well-formedness. self.lower_lit(lo_expr).with_user_type_ascription_subpattern(), self.lower_lit(hi_expr).with_user_type_ascription_subpattern(), ) { (PatternKind::Constant { value: lo }, PatternKind::Constant { value: hi }) => { </ins> use std::cmp::Ordering; let cmp = compare_const_vals( self.tcx,


Question:
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.

} } } <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> } }


Question:
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.

<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>


Question:
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

/// // 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>,


Question:
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.

// 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;


Question:
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.

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


Question:
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.

// compile-flags: -O // min-llvm-version: 15.0 <del> #![crate_type="lib"] </del> <ins> #![crate_type = "lib"] </ins> use std::mem::MaybeUninit;


Question:
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.

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.


Question:
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.

<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>


Question:
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.

<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>


Question:
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.

<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>


Question:
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.

<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>


Question:
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.

<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>


Question:
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.

<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>


Question:
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.

<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>


Question:
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.

<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>


Question:
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.

<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>


Question: 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.

// 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) {


Question: 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.

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 `&_`


Question: 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.

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


Question: 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.

<ins> fn main() { let a: String = &String::from("a"); //~^ ERROR mismatched types let b: String = &format!("b"); //~^ ERROR mismatched types } </ins>


Question: 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.

<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>


Question:
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 .

<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>


Question:
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 .

<ins> error: higher-ranked subtype error --> $DIR/issue-59311.rs:17:9 | LL |     v.t(|| {}); |         ^^^^^ error: aborting due to previous error </ins>


Question: 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.

"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",


Question: 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.

`expanded,identified` (fully parenthesized, AST nodes with IDs).", "TYPE", ), <del> opt::opt_s( "", "edition", "Specify which edition of the compiler to use when compiling code.", EDITION_NAME_LIST, ), </del> opt::multi_s( "", "remap-path-prefix",


Question:
charatreverse(s, i) returns the character at i - 1 instead of s.char_len() - 1 - i.
This is actually the "correct" behaviour (at least it is the behaviour listed in the documentation of ). Also, note that and actually deal with byte positions, not unicode char positions (this is not stated in the documentation for either of these :( ). Pull request hopefully corrects both of these issues.
Closing, has been clarified in a documentation update.

let ident = *ident; let mut path = path.clone(); for seg in &mut path.segments { <del> seg.id = self.next_node_id(); </del> <ins> // Give the cloned segment the same resolution information // as the old one (this is needed for stability checking). let new_id = self.next_node_id(); self.resolver.clone_res(seg.id, new_id); seg.id = new_id; </ins> } let span = path.span;


Question:
charatreverse(s, i) returns the character at i - 1 instead of s.char_len() - 1 - i.
This is actually the "correct" behaviour (at least it is the behaviour listed in the documentation of ). Also, note that and actually deal with byte positions, not unicode char positions (this is not stated in the documentation for either of these :( ). Pull request hopefully corrects both of these issues.
Closing, has been clarified in a documentation update.

// Give the segments new node-ids since they are being cloned. for seg in &mut prefix.segments { <del> seg.id = self.next_node_id(); </del> <ins> // Give the cloned segment the same resolution information // as the old one (this is needed for stability checking). let new_id = self.next_node_id(); self.resolver.clone_res(seg.id, new_id); seg.id = new_id; </ins> } // Each `use` import is an item and thus are owners of the


Question:
charatreverse(s, i) returns the character at i - 1 instead of s.char_len() - 1 - i.
This is actually the "correct" behaviour (at least it is the behaviour listed in the documentation of ). Also, note that and actually deal with byte positions, not unicode char positions (this is not stated in the documentation for either of these :( ). Pull request hopefully corrects both of these issues.
Closing, has been clarified in a documentation update.

fn legacy_const_generic_args(&self, expr: &Expr) -> Option<Vec<usize>>; fn get_partial_res(&self, id: NodeId) -> Option<PartialRes>; fn get_import_res(&self, id: NodeId) -> PerNS<Option<Res<NodeId>>>; <ins> // Clones the resolution (if any) on 'source' and applies it // to 'target'. Used when desugaring a `UseTreeKind::Nested` to // multiple `UseTreeKind::Simple`s fn clone_res(&mut self, source: NodeId, target: NodeId); </ins> fn get_label_res(&self, id: NodeId) -> Option<NodeId>; fn get_lifetime_res(&self, id: NodeId) -> Option<LifetimeRes>; fn take_extra_lifetime_params(&mut self, id: NodeId) -> Vec<(Ident, NodeId, LifetimeRes)>;


Question:
charatreverse(s, i) returns the character at i - 1 instead of s.char_len() - 1 - i.
This is actually the "correct" behaviour (at least it is the behaviour listed in the documentation of ). Also, note that and actually deal with byte positions, not unicode char positions (this is not stated in the documentation for either of these :( ). Pull request hopefully corrects both of these issues.
Closing, has been clarified in a documentation update.

None } <ins> fn clone_res(&mut self, source: NodeId, target: NodeId) { if let Some(res) = self.partial_res_map.get(&source) { self.partial_res_map.insert(target, *res); } } </ins> /// Obtains resolution for a `NodeId` with a single resolution. fn get_partial_res(&self, id: NodeId) -> Option<PartialRes> { self.partial_res_map.get(&id).copied()


Question:
charatreverse(s, i) returns the character at i - 1 instead of s.char_len() - 1 - i.
This is actually the "correct" behaviour (at least it is the behaviour listed in the documentation of ). Also, note that and actually deal with byte positions, not unicode char positions (this is not stated in the documentation for either of these :( ). Pull request hopefully corrects both of these issues.
Closing, has been clarified in a documentation update.

extern crate lint_output_format; //~ ERROR use of unstable library feature use lint_output_format::{foo, bar}; //~ ERROR use of unstable library feature <ins> //~| ERROR use of unstable library feature </ins> fn main() { let _x = foo();


Question:
charatreverse(s, i) returns the character at i - 1 instead of s.char_len() - 1 - i.
This is actually the "correct" behaviour (at least it is the behaviour listed in the documentation of ). Also, note that and actually deal with byte positions, not unicode char positions (this is not stated in the documentation for either of these :( ). Pull request hopefully corrects both of these issues.
Closing, has been clarified in a documentation update.

= help: add `#![feature(unstable_test_feature)]` to the crate attributes to enable error[E0658]: use of unstable library feature 'unstable_test_feature' <ins> --> $DIR/lint-output-format.rs:7:26 | LL | use lint_output_format::{foo, bar}; |                          ^^^ | = help: add `#![feature(unstable_test_feature)]` to the crate attributes to enable error[E0658]: use of unstable library feature 'unstable_test_feature' </ins> --> $DIR/lint-output-format.rs:7:31 | LL | use lint_output_format::{foo, bar};


Question:
charatreverse(s, i) returns the character at i - 1 instead of s.char_len() - 1 - i.
This is actually the "correct" behaviour (at least it is the behaviour listed in the documentation of ). Also, note that and actually deal with byte positions, not unicode char positions (this is not stated in the documentation for either of these :( ). Pull request hopefully corrects both of these issues.
Closing, has been clarified in a documentation update.

= help: add `#![feature(unstable_test_feature)]` to the crate attributes to enable error[E0658]: use of unstable library feature 'unstable_test_feature' <del> --> $DIR/lint-output-format.rs:11:14 </del> <ins> --> $DIR/lint-output-format.rs:12:14 </ins> | LL |     let _y = bar(); |              ^^^ | = help: add `#![feature(unstable_test_feature)]` to the crate attributes to enable <del> error: aborting due to 3 previous errors </del> <ins> error: aborting due to 4 previous errors </ins> For more information about this error, try `rustc --explain E0658`.


Question:
charatreverse(s, i) returns the character at i - 1 instead of s.char_len() - 1 - i.
This is actually the "correct" behaviour (at least it is the behaviour listed in the documentation of ). Also, note that and actually deal with byte positions, not unicode char positions (this is not stated in the documentation for either of these :( ). Pull request hopefully corrects both of these issues.
Closing, has been clarified in a documentation update.

impl stable_in_unstable_std::old_stable_module::OldTrait for LocalType {} } <ins> mod isolated6 { use stable_in_unstable_core::new_unstable_module::{OldTrait}; //~ ERROR use of unstable library feature 'unstable_test_feature' } mod isolated7 { use stable_in_unstable_core::new_unstable_module::*; //~ ERROR use of unstable library feature 'unstable_test_feature' } </ins>


Question:
charatreverse(s, i) returns the character at i - 1 instead of s.char_len() - 1 - i.
This is actually the "correct" behaviour (at least it is the behaviour listed in the documentation of ). Also, note that and actually deal with byte positions, not unicode char positions (this is not stated in the documentation for either of these :( ). Pull request hopefully corrects both of these issues.
Closing, has been clarified in a documentation update.

= note: see issue #1 <https://github.com/rust-lang/rust/issues/1> for more information = help: add `#![feature(unstable_test_feature)]` to the crate attributes to enable <del> error: aborting due to 4 previous errors </del> <ins> error[E0658]: use of unstable library feature 'unstable_test_feature' --> $DIR/stable-in-unstable.rs:49:56 | LL |     use stable_in_unstable_core::new_unstable_module::{OldTrait}; |                                                        ^^^^^^^^ | = note: see issue #1 <https://github.com/rust-lang/rust/issues/1> for more information = help: add `#![feature(unstable_test_feature)]` to the crate attributes to enable error[E0658]: use of unstable library feature 'unstable_test_feature' --> $DIR/stable-in-unstable.rs:53:9 | LL |     use stable_in_unstable_core::new_unstable_module::*; |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #1 <https://github.com/rust-lang/rust/issues/1> for more information = help: add `#![feature(unstable_test_feature)]` to the crate attributes to enable error: aborting due to 6 previous errors </ins> For more information about this error, try `rustc --explain E0658`.


Question: First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?

/// Returns the creation time listed in this metadata. /// <del> /// The returned value corresponds to the `birthtime` field of `stat` on /// Unix platforms and the `ftCreationTime` field on Windows platforms. </del> <ins> /// The returned value corresponds to the `btime` field of `statx` on /// Linux kernel starting from to 4.11, the `birthtime` field of `stat` on other /// Unix platforms, and the `ftCreationTime` field on Windows platforms. </ins> /// /// # Errors /// /// This field may not be available on all platforms, and will return an <del> /// `Err` on platforms where it is not available. </del> <ins> /// `Err` on platforms or filesystems where it is not available. </ins> /// /// # Examples ///


Question: First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?

///     if let Ok(time) = metadata.created() { ///         println!("{:?}", time); ///     } else { <del> ///         println!("Not supported on this platform"); </del> <ins> ///         println!("Not supported on this platform or filesystem"); </ins> ///     } ///     Ok(()) /// }


Question: First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?

check!(a.created()); check!(b.created()); } <ins> if cfg!(target_os = "linux") { // Not always available match (a.created(), b.created()) { (Ok(t1), Ok(t2)) => assert!(t1 <= t2), (Err(e1), Err(e2)) if e1.kind() == ErrorKind::Other && e2.kind() == ErrorKind::Other => {} (a, b) => panic!( "creation time must be always supported or not supported: {:?} {:?}", a, b, ), } } </ins> } }


Question: First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?

pub struct File(FileDesc); <del> #[derive(Clone)] pub struct FileAttr { stat: stat64, </del> <ins> // FIXME: This should be available on Linux with all `target_arch` and `target_env`. // https://github.com/rust-lang/libc/issues/1545 macro_rules! cfg_has_statx { ({ $($then_tt:tt)* } else { $($else_tt:tt)* }) => { cfg_if::cfg_if! { if #[cfg(all(target_os = "linux", target_env = "gnu", any( target_arch = "x86", target_arch = "arm", // target_arch = "mips", target_arch = "powerpc", target_arch = "x86_64", // target_arch = "aarch64", target_arch = "powerpc64", // target_arch = "mips64", // target_arch = "s390x", target_arch = "sparc64", )))] { $($then_tt)* } else { $($else_tt)* } } }; ($($block_inner:tt)*) => { #[cfg(all(target_os = "linux", target_env = "gnu", any( target_arch = "x86", target_arch = "arm", // target_arch = "mips", target_arch = "powerpc", target_arch = "x86_64", // target_arch = "aarch64", target_arch = "powerpc64", // target_arch = "mips64", // target_arch = "s390x", target_arch = "sparc64", )))] { $($block_inner)* } }; </ins> } <ins> cfg_has_statx! {{ #[derive(Clone)] pub struct FileAttr { stat: stat64, statx_extra_fields: Option<StatxExtraFields>, } #[derive(Clone)] struct StatxExtraFields { // This is needed to check if btime is supported by the filesystem. stx_mask: u32, stx_btime: libc::statx_timestamp, } // We prefer `statx` on Linux if available, which contains file creation time. // Default `stat64` contains no creation time. unsafe fn try_statx( fd: c_int, path: *const libc::c_char, flags: i32, mask: u32, ) -> Option<io::Result<FileAttr>> { use crate::sync::atomic::{AtomicBool, Ordering}; // Linux kernel prior to 4.11 or glibc prior to glibc 2.28 don't support `statx` // We store the availability in a global to avoid unnecessary syscalls static HAS_STATX: AtomicBool = AtomicBool::new(true); syscall! { fn statx( fd: c_int, pathname: *const libc::c_char, flags: c_int, mask: libc::c_uint, statxbuf: *mut libc::statx ) -> c_int } if !HAS_STATX.load(Ordering::Relaxed) { return None; } let mut buf: libc::statx = mem::zeroed(); let ret = cvt(statx(fd, path, flags, mask, &mut buf)); match ret { Err(err) => match err.raw_os_error() { Some(libc::ENOSYS) => { HAS_STATX.store(false, Ordering::Relaxed); return None; } _ => return Some(Err(err)), } Ok(_) => { // We cannot fill `stat64` exhaustively because of private padding fields. let mut stat: stat64 = mem::zeroed(); // `c_ulong` on gnu-mips, `dev_t` otherwise stat.st_dev = libc::makedev(buf.stx_dev_major, buf.stx_dev_minor) as _; stat.st_ino = buf.stx_ino as libc::ino64_t; stat.st_nlink = buf.stx_nlink as libc::nlink_t; stat.st_mode = buf.stx_mode as libc::mode_t; stat.st_uid = buf.stx_uid as libc::uid_t; stat.st_gid = buf.stx_gid as libc::gid_t; stat.st_rdev = libc::makedev(buf.stx_rdev_major, buf.stx_rdev_minor) as _; stat.st_size = buf.stx_size as off64_t; stat.st_blksize = buf.stx_blksize as libc::blksize_t; stat.st_blocks = buf.stx_blocks as libc::blkcnt64_t; stat.st_atime = buf.stx_atime.tv_sec as libc::time_t; // `i64` on gnu-x86_64-x32, `c_ulong` otherwise. stat.st_atime_nsec = buf.stx_atime.tv_nsec as _; stat.st_mtime = buf.stx_mtime.tv_sec as libc::time_t; stat.st_mtime_nsec = buf.stx_mtime.tv_nsec as _; stat.st_ctime = buf.stx_ctime.tv_sec as libc::time_t; stat.st_ctime_nsec = buf.stx_ctime.tv_nsec as _; let extra = StatxExtraFields { stx_mask: buf.stx_mask, stx_btime: buf.stx_btime, }; Some(Ok(FileAttr { stat, statx_extra_fields: Some(extra) })) } } } } else { #[derive(Clone)] pub struct FileAttr { stat: stat64, } }} </ins> // all DirEntry's will have a reference to this struct struct InnerReadDir { dirp: Dir,


Question: First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?

#[derive(Debug)] pub struct DirBuilder { mode: mode_t } <ins> cfg_has_statx! {{ impl FileAttr { fn from_stat64(stat: stat64) -> Self { Self { stat, statx_extra_fields: None } } } } else { impl FileAttr { fn from_stat64(stat: stat64) -> Self { Self { stat } } } }} </ins> impl FileAttr { pub fn size(&self) -> u64 { self.stat.st_size as u64 } pub fn perm(&self) -> FilePermissions {


Question: First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?

target_os = "macos", target_os = "ios")))] pub fn created(&self) -> io::Result<SystemTime> { <ins> cfg_has_statx! { if let Some(ext) = &self.statx_extra_fields { return if (ext.stx_mask & libc::STATX_BTIME) != 0 { Ok(SystemTime::from(libc::timespec { tv_sec: ext.stx_btime.tv_sec as libc::time_t, tv_nsec: ext.stx_btime.tv_nsec as _, })) } else { Err(io::Error::new( io::ErrorKind::Other, "creation time is not available for the filesystem", )) }; } } </ins> Err(io::Error::new(io::ErrorKind::Other, "creation time is not available on this platform  currently"))


Question: First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?

#[cfg(any(target_os = "linux", target_os = "emscripten", target_os = "android"))] pub fn metadata(&self) -> io::Result<FileAttr> { <del> let fd = cvt(unsafe {dirfd(self.dir.inner.dirp.0)})?; </del> <ins> let fd = cvt(unsafe { dirfd(self.dir.inner.dirp.0) })?; let name = self.entry.d_name.as_ptr(); cfg_has_statx! { if let Some(ret) = unsafe { try_statx( fd, name, libc::AT_SYMLINK_NOFOLLOW | libc::AT_STATX_SYNC_AS_STAT, libc::STATX_ALL, ) } { return ret; } } </ins> let mut stat: stat64 = unsafe { mem::zeroed() }; cvt(unsafe { <del> fstatat64(fd, self.entry.d_name.as_ptr(), &mut stat, libc::AT_SYMLINK_NOFOLLOW) </del> <ins> fstatat64(fd, name, &mut stat, libc::AT_SYMLINK_NOFOLLOW) </ins> })?; <del> Ok(FileAttr { stat }) </del> <ins> Ok(FileAttr::from_stat64(stat)) </ins> } #[cfg(not(any(target_os = "linux", target_os = "emscripten", target_os = "android")))]


Question: First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?

} pub fn file_attr(&self) -> io::Result<FileAttr> { <ins> let fd = self.0.raw(); cfg_has_statx! { if let Some(ret) = unsafe { try_statx( fd, b"0" as *const _ as *const libc::c_char, libc::AT_EMPTY_PATH | libc::AT_STATX_SYNC_AS_STAT, libc::STATX_ALL, ) } { return ret; } } </ins> let mut stat: stat64 = unsafe { mem::zeroed() }; cvt(unsafe { <del> fstat64(self.0.raw(), &mut stat) </del> <ins> fstat64(fd, &mut stat) </ins> })?; <del> Ok(FileAttr { stat }) </del> <ins> Ok(FileAttr::from_stat64(stat)) </ins> } pub fn fsync(&self) -> io::Result<()> {


Question: First of all, it now returns an Err with "not available on this platform currently". But I found that there is a system call  available in Linux kernel 4.11, which can get the birth time. As the , the function uses on Unix platforms. But the just never contains . Shouldn't it try when available?

pub fn stat(p: &Path) -> io::Result<FileAttr> { let p = cstr(p)?; <ins> cfg_has_statx! { if let Some(ret) = unsafe { try_statx( libc::AT_FDCWD, p.as_ptr(), libc::AT_STATX_SYNC_AS_STAT, libc::STATX_ALL, ) } { return ret; } } </ins> let mut stat: stat64 = unsafe { mem::zeroed() }; cvt(unsafe { stat64(p.as_ptr(), &mut stat) })?; <del> Ok(FileAttr { stat }) </del> <ins> Ok(FileAttr::from_stat64(stat)) </ins> } pub fn lstat(p: &Path) -> io::Result<FileAttr> { let p = cstr(p)?; <ins> cfg_has_statx! { if let Some(ret) = unsafe { try_statx( libc::AT_FDCWD, p.as_ptr(), libc::AT_SYMLINK_NOFOLLOW | libc::AT_STATX_SYNC_AS_STAT, libc::STATX_ALL, ) } { return ret; } } </ins> let mut stat: stat64 = unsafe { mem::zeroed() }; cvt(unsafe { lstat64(p.as_ptr(), &mut stat) })?; <del> Ok(FileAttr { stat }) </del> <ins> Ok(FileAttr::from_stat64(stat)) </ins> } pub fn canonicalize(p: &Path) -> io::Result<PathBuf> {


Question: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls 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 prioritization.

<del> Subproject commit cafbe7f2d9bdf9e94946e3f6f62b781b05b7d556 </del> <ins> Subproject commit d420589e1a8208c85368d07c1644c6725367650b </ins>


Question:
While I was trying to make a general impl, I came across this ICE. Note that inlining makes this ICE go away.
thanks for putting the stack-trace, I forgot about that This also works
Small repro: I'll try to have a PR up for this next week.
Another repro from

borrow_region: RegionVid, outlived_region: RegionVid, ) -> (ConstraintCategory, bool, Span, Option<RegionName>) { <del> let (category, from_closure, span) = self.best_blame_constraint(mir, borrow_region, |r| r == outlived_region); </del> <ins> let (category, from_closure, span) = self.best_blame_constraint( mir, borrow_region, |r| self.provides_universal_region(r, borrow_region, outlived_region) ); </ins> let outlived_fr_name = self.give_region_a_name(infcx, mir, upvars, mir_def_id, outlived_region, &mut 1); (category, from_closure, span, outlived_fr_name)


Question:
While I was trying to make a general impl, I came across this ICE. Note that inlining makes this ICE go away.
thanks for putting the stack-trace, I forgot about that This also works
Small repro: I'll try to have a PR up for this next week.
Another repro from

<ins> // Test that we handle the case when a local variable is borrowed for `'static` // due to an outlives constraint involving a region in an incompatible universe pub trait Outlives<'this> {} impl<'this, T> Outlives<'this> for T where T: 'this {} trait Reference { type AssociatedType; } impl<'a, T: 'a> Reference for &'a T { type AssociatedType = &'a (); } fn assert_static_via_hrtb<G>(_: G) where for<'a> G: Outlives<'a> {} fn assert_static_via_hrtb_with_assoc_type<T>(_: &'_ T) where for<'a> &'a T: Reference<AssociatedType = &'a ()>, {} fn main() { let local = 0; assert_static_via_hrtb(&local); //~ ERROR `local` does not live long enough assert_static_via_hrtb_with_assoc_type(&&local); //~ ERROR `local` does not live long enough } </ins>


Question:
While I was trying to make a general impl, I came across this ICE. Note that inlining makes this ICE go away.
thanks for putting the stack-trace, I forgot about that This also works
Small repro: I'll try to have a PR up for this next week.
Another repro from

<ins> error[E0597]: `local` does not live long enough --> $DIR/local-outlives-static-via-hrtb.rs:24:28 | LL |     assert_static_via_hrtb(&local); |     -----------------------^^^^^^- |     |                      | |     |                      borrowed value does not live long enough |     argument requires that `local` is borrowed for `'static` LL |     assert_static_via_hrtb_with_assoc_type(&&local); LL | } | - `local` dropped here while still borrowed error[E0597]: `local` does not live long enough --> $DIR/local-outlives-static-via-hrtb.rs:25:45 | LL |     assert_static_via_hrtb_with_assoc_type(&&local); |     ----------------------------------------^^^^^^- |     |                                       | |     |                                       borrowed value does not live long enough |     argument requires that `local` is borrowed for `'static` LL | } | - `local` dropped here while still borrowed error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0597`. </ins>


Question:
Run tests for and you'll get the following diagnostic: But to be as helpful as possible the diagnostic should, if possible, point to the start of the invalid code block.
This error was removed in because I didn't think it could actually be produced. Looks like it was possible to trigger by writing an empty doc test. The error message is misleading, though. It's a valid code block, just empty. On master, this code produces a passing doc test now. IMO, that is the correct behavior. There should probably be a test for it.
I agree completely. Would this mean re-introducing this message but improving the message (replacing invalid with empty or something similar)? I believe that is the best course of action as warning on an empty code block is completely valid and desired IMO.
The original code only caught this incidentally. I think this check would make more sense as a rustdoc lint instead of a hard warning. Could be to or a new pass entirely.
could you edit this issue to reflect the current status? It should be something like "Empty doc tests should be linted".
I'd like to take this issue - should have a PR this week for review.

dox[code_block.code].to_owned(), ); <del> let has_errors = { let mut has_errors = false; </del> <ins> let validation_status = { let mut has_syntax_errors = false; let mut only_whitespace = true; // even if there is a syntax error, we need to run the lexer over the whole file </ins> let mut lexer = Lexer::new(&sess, source_file, None); loop  { match lexer.next_token().kind { token::Eof => break, <del> token::Unknown(..) => has_errors = true, _ => (), </del> <ins> token::Whitespace => (), token::Unknown(..) => has_syntax_errors = true, _ => only_whitespace = false, </ins> } } <del> has_errors </del> <ins> if has_syntax_errors { Some(CodeBlockInvalid::SyntaxError) } else if only_whitespace { Some(CodeBlockInvalid::Empty) } else { None } </ins> }; <del> if has_errors { </del> <ins> if let Some(code_block_invalid) = validation_status { </ins> let mut diag = if let Some(sp) = super::source_span_for_markdown_range(self.cx, &dox, &code_block.range, &item.attrs) { <del> let mut diag = self .cx .sess() .struct_span_warn(sp, "could not parse code block as Rust code"); </del> <ins> let warning_message = match code_block_invalid { CodeBlockInvalid::SyntaxError => "could not parse code block as Rust code", CodeBlockInvalid::Empty => "Rust code block is empty", }; let mut diag = self.cx.sess().struct_span_warn(sp, warning_message); </ins> if code_block.syntax.is_none() && code_block.is_fenced { let sp = sp.from_inner(InnerSpan::new(0, 3));


Question:
Run tests for and you'll get the following diagnostic: But to be as helpful as possible the diagnostic should, if possible, point to the start of the invalid code block.
This error was removed in because I didn't think it could actually be produced. Looks like it was possible to trigger by writing an empty doc test. The error message is misleading, though. It's a valid code block, just empty. On master, this code produces a passing doc test now. IMO, that is the correct behavior. There should probably be a test for it.
I agree completely. Would this mean re-introducing this message but improving the message (replacing invalid with empty or something similar)? I believe that is the best course of action as warning on an empty code block is completely valid and desired IMO.
The original code only caught this incidentally. I think this check would make more sense as a rustdoc lint instead of a hard warning. Could be to or a new pass entirely.
could you edit this issue to reflect the current status? It should be something like "Empty doc tests should be linted".
I'd like to take this issue - should have a PR this week for review.

self.fold_item_recur(item) } } <ins> enum CodeBlockInvalid { SyntaxError, Empty, } </ins>


Question:
Run tests for and you'll get the following diagnostic: But to be as helpful as possible the diagnostic should, if possible, point to the start of the invalid code block.
This error was removed in because I didn't think it could actually be produced. Looks like it was possible to trigger by writing an empty doc test. The error message is misleading, though. It's a valid code block, just empty. On master, this code produces a passing doc test now. IMO, that is the correct behavior. There should probably be a test for it.
I agree completely. Would this mean re-introducing this message but improving the message (replacing invalid with empty or something similar)? I believe that is the best course of action as warning on an empty code block is completely valid and desired IMO.
The original code only caught this incidentally. I think this check would make more sense as a rustdoc lint instead of a hard warning. Could be to or a new pass entirely.
could you edit this issue to reflect the current status? It should be something like "Empty doc tests should be linted".
I'd like to take this issue - should have a PR this week for review.

/// _ #[doc = "```"] pub fn crazy_attrs() {} <ins> /// ```rust /// ``` pub fn empty_rust() {} /// ``` /// /// /// ``` pub fn empty_rust_with_whitespace() {} </ins>


Question:
Run tests for and you'll get the following diagnostic: But to be as helpful as possible the diagnostic should, if possible, point to the start of the invalid code block.
This error was removed in because I didn't think it could actually be produced. Looks like it was possible to trigger by writing an empty doc test. The error message is misleading, though. It's a valid code block, just empty. On master, this code produces a passing doc test now. IMO, that is the correct behavior. There should probably be a test for it.
I agree completely. Would this mean re-introducing this message but improving the message (replacing invalid with empty or something similar)? I believe that is the best course of action as warning on an empty code block is completely valid and desired IMO.
The original code only caught this incidentally. I think this check would make more sense as a rustdoc lint instead of a hard warning. Could be to or a new pass entirely.
could you edit this issue to reflect the current status? It should be something like "Empty doc tests should be linted".
I'd like to take this issue - should have a PR this week for review.

| = help: mark blocks that do not contain Rust code as text: ```text <ins> warning: Rust code block is empty --> $DIR/invalid-syntax.rs:68:5 | LL |   /// ```rust |  _____^ LL | | /// ``` | |_______^ warning: Rust code block is empty --> $DIR/invalid-syntax.rs:72:5 | LL |   /// ``` |  _____^ LL | | /// LL | | /// LL | | /// ``` | |_______^ help: mark blocks that do not contain Rust code as text | LL | /// ```text |     ^^^^^^^ </ins> error: unknown start of token:  --> <rustdoc-highlighting>:1:1 |


Question:
How to reproduce Actual Result Actual Result with full backtrace rustc --version --verbose Expected result Additional details Please note that the issue will go away once you succeed in building the project (probably thanks due to some compiler caching, sorry, not sure here). A is enough to get the error back :) Thank you.
triage: P-medium due to niche nature of bug. Leaving nominated to try to increase its visibility in short term in case T-compiler members want to attack it.
I'm not asking you to re-prio. I'd just like to say I don't think the issue is so niche, as seems to exhibit the very same behaviour, and I can easily see myself trying: Thank you and again for looking at the ticket :+1:
briefly at T-compiler meeting. un-nominating.
I inadvertently ran into this bug today when trying to do with my project with closed to see how my project would behave. I wasted quite a bit of time trying to find the ICE by reducing my program then I found this issue.
I am unable to reproduce this anymore and WSL:
The problem is still present for me on macOS even on nightly:
I wonder if this is related to ? By the way, for that reason, don't run Rust things with .

#[cfg(not(test))] pub fn init() { <ins> // The standard streams might be closed on application startup. To prevent // std::io::{stdin, stdout,stderr} objects from using other unrelated file // resources opened later, we reopen standards streams when they are closed. unsafe { sanitize_standard_fds(); } </ins> // By default, some platforms will send a *signal* when an EPIPE error // would otherwise be delivered. This runtime doesn't install a SIGPIPE // handler, causing it to kill the program, which isn't exactly what we


Question:
How to reproduce Actual Result Actual Result with full backtrace rustc --version --verbose Expected result Additional details Please note that the issue will go away once you succeed in building the project (probably thanks due to some compiler caching, sorry, not sure here). A is enough to get the error back :) Thank you.
triage: P-medium due to niche nature of bug. Leaving nominated to try to increase its visibility in short term in case T-compiler members want to attack it.
I'm not asking you to re-prio. I'd just like to say I don't think the issue is so niche, as seems to exhibit the very same behaviour, and I can easily see myself trying: Thank you and again for looking at the ticket :+1:
briefly at T-compiler meeting. un-nominating.
I inadvertently ran into this bug today when trying to do with my project with closed to see how my project would behave. I wasted quite a bit of time trying to find the ICE by reducing my program then I found this issue.
I am unable to reproduce this anymore and WSL:
The problem is still present for me on macOS even on nightly:
I wonder if this is related to ? By the way, for that reason, don't run Rust things with .

reset_sigpipe(); } <ins> // In the case when all file descriptors are open, the poll has been // observed to perform better than fcntl (on GNU/Linux). #[cfg(not(any( miri, target_os = "emscripten", target_os = "fuchsia", // The poll on Darwin doesn't set POLLNVAL for closed fds. target_os = "macos", target_os = "ios", target_os = "redox", )))] unsafe fn sanitize_standard_fds() { use crate::sys::os::errno; let pfds: &mut [_] = &mut [ libc::pollfd { fd: 0, events: 0, revents: 0 }, libc::pollfd { fd: 1, events: 0, revents: 0 }, libc::pollfd { fd: 2, events: 0, revents: 0 }, ]; while libc::poll(pfds.as_mut_ptr(), 3, 0) == -1 { if errno() == libc::EINTR { continue; } libc::abort(); } for pfd in pfds { if pfd.revents & libc::POLLNVAL == 0 { continue; } if libc::open("/dev/null0".as_ptr().cast(), libc::O_RDWR, 0) == -1 { // If the stream is closed but we failed to reopen it, abort the // process. Otherwise we wouldn't preserve the safety of // operations on the corresponding Rust object Stdin, Stdout, or // Stderr. libc::abort(); } } } #[cfg(any(target_os = "macos", target_os = "ios", target_os = "redox"))] unsafe fn sanitize_standard_fds() { use crate::sys::os::errno; for fd in 0..3 { if libc::fcntl(fd, libc::F_GETFD) == -1 && errno() == libc::EBADF { if libc::open("/dev/null0".as_ptr().cast(), libc::O_RDWR, 0) == -1 { libc::abort(); } } } } #[cfg(any( // The standard fds are always available in Miri. miri, target_os = "emscripten", target_os = "fuchsia"))] unsafe fn sanitize_standard_fds() {} </ins> #[cfg(not(any(target_os = "emscripten", target_os = "fuchsia")))] unsafe fn reset_sigpipe() { assert!(signal(libc::SIGPIPE, libc::SIG_IGN) != libc::SIG_ERR);


Question:
How to reproduce Actual Result Actual Result with full backtrace rustc --version --verbose Expected result Additional details Please note that the issue will go away once you succeed in building the project (probably thanks due to some compiler caching, sorry, not sure here). A is enough to get the error back :) Thank you.
triage: P-medium due to niche nature of bug. Leaving nominated to try to increase its visibility in short term in case T-compiler members want to attack it.
I'm not asking you to re-prio. I'd just like to say I don't think the issue is so niche, as seems to exhibit the very same behaviour, and I can easily see myself trying: Thank you and again for looking at the ticket :+1:
briefly at T-compiler meeting. un-nominating.
I inadvertently ran into this bug today when trying to do with my project with closed to see how my project would behave. I wasted quite a bit of time trying to find the ICE by reducing my program then I found this issue.
I am unable to reproduce this anymore and WSL:
The problem is still present for me on macOS even on nightly:
I wonder if this is related to ? By the way, for that reason, don't run Rust things with .

return r } <ins> #[cfg(unix)] fn assert_fd_is_valid(fd: libc::c_int) { if unsafe { libc::fcntl(fd, libc::F_GETFD) == -1 } { panic!("file descriptor {} is not valid: {}", fd, io::Error::last_os_error()); } } #[cfg(windows)] fn assert_fd_is_valid(_fd: libc::c_int) {} </ins> #[cfg(windows)] unsafe fn without_stdio<R, F: FnOnce() -> R>(f: F) -> R { type DWORD = u32;


Question:
How to reproduce Actual Result Actual Result with full backtrace rustc --version --verbose Expected result Additional details Please note that the issue will go away once you succeed in building the project (probably thanks due to some compiler caching, sorry, not sure here). A is enough to get the error back :) Thank you.
triage: P-medium due to niche nature of bug. Leaving nominated to try to increase its visibility in short term in case T-compiler members want to attack it.
I'm not asking you to re-prio. I'd just like to say I don't think the issue is so niche, as seems to exhibit the very same behaviour, and I can easily see myself trying: Thank you and again for looking at the ticket :+1:
briefly at T-compiler meeting. un-nominating.
I inadvertently ran into this bug today when trying to do with my project with closed to see how my project would behave. I wasted quite a bit of time trying to find the ICE by reducing my program then I found this issue.
I am unable to reproduce this anymore and WSL:
The problem is still present for me on macOS even on nightly:
I wonder if this is related to ? By the way, for that reason, don't run Rust things with .

fn main() { if env::args().len() > 1 { <ins> // Writing to stdout & stderr should not panic. </ins> println!("test"); assert!(io::stdout().write(b"testn").is_ok()); assert!(io::stderr().write(b"testn").is_ok()); <ins> // Stdin should be at EOF. </ins> assert_eq!(io::stdin().read(&mut [0; 10]).unwrap(), 0); <ins> // Standard file descriptors should be valid on UNIX: assert_fd_is_valid(0); assert_fd_is_valid(1); assert_fd_is_valid(2); </ins> return }


Question:
How to reproduce Actual Result Actual Result with full backtrace rustc --version --verbose Expected result Additional details Please note that the issue will go away once you succeed in building the project (probably thanks due to some compiler caching, sorry, not sure here). A is enough to get the error back :) Thank you.
triage: P-medium due to niche nature of bug. Leaving nominated to try to increase its visibility in short term in case T-compiler members want to attack it.
I'm not asking you to re-prio. I'd just like to say I don't think the issue is so niche, as seems to exhibit the very same behaviour, and I can easily see myself trying: Thank you and again for looking at the ticket :+1:
briefly at T-compiler meeting. un-nominating.
I inadvertently ran into this bug today when trying to do with my project with closed to see how my project would behave. I wasted quite a bit of time trying to find the ICE by reducing my program then I found this issue.
I am unable to reproduce this anymore and WSL:
The problem is still present for me on macOS even on nightly:
I wonder if this is related to ? By the way, for that reason, don't run Rust things with .

.stdout(Stdio::null()) .stderr(Stdio::null()) .status().unwrap(); <del> assert!(status.success(), "{:?} isn't a success", status); </del> <ins> assert!(status.success(), "{} isn't a success", status); </ins> // Finally, close everything then spawn a child to make sure everything is // *still* ok. let status = unsafe { without_stdio(|| Command::new(&me).arg("next").status()) }.unwrap(); <del> assert!(status.success(), "{:?} isn't a success", status); </del> <ins> assert!(status.success(), "{} isn't a success", status); </ins> }


Question:
only checks that the link section contains no pointers, but there may be arbitrary bytes in the data, even undefined bytes (e.g. due to padding). cc is that ok? llvm may insert whereever there are undefined bytes. Or should we lint/error on such statics? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
that should be ok yeah, I think that's what happens on all other platforms and it's up to the consumer to ensure that all bytes they read have defined values if they want.
Ok, I guess we should probably just document that in the code segment that I linked above.
claim

return } <del> // For the wasm32 target statics with #[link_section] are placed into custom </del> <ins> // For the wasm32 target statics with `#[link_section]` are placed into custom </ins> // sections of the final output file, but this isn't link custom sections of // other executable formats. Namely we can only embed a list of bytes, // nothing with pointers to anything else or relocations. If any relocation // show up, reject them here. <ins> // `#[link_section]` may contain arbitrary, or even undefined bytes, but it is // the consumer's responsibility to ensure all bytes that have been read // have defined values. </ins> let instance = ty::Instance::mono(tcx, id); let cid = GlobalId { instance,


Question:
The following code (which is awesome!), but the warning is not as clear as it could be: This results in: it should probably say "futures do nothing unless you await them" or something. Most people won't know what 'polled' is all about, I think.
The current note originates from: To change it, simply edit that.
What about ?
In any case, . Just a typo :wink: I would actually expect something in the line of: Btw, I'd love to work on this issue and provide a PR. I'm really looking forward to help Rust just as much as it has helped me thus far!
We may want to work in the fact that you can use somehow. Other than that, sounds pretty good.
what trait does provide ? :astonished:
is equivalent to and is likely to replace it eventually. See I think for now might be good enough and we could tweak later.
That makes sense to me! Am I ok to work on this?

/// When using a future, you generally won't call `poll` directly, but instead /// `await!` the value. #[doc(spotlight)] <del> #[must_use = "futures do nothing unless polled"] </del> <ins> #[must_use = "futures do nothing unless you `.await` or poll them"] </ins> #[stable(feature = "futures_api", since = "1.36.0")] pub trait Future { /// The type of value produced on completion.


Question:
Hello, I was working on my toy project here: The project was compiling and running fine at this commit: However, I decided I wanted to move functionality out of and into , so I moved all of it except the declarations, and then tried to compile. This led to the compiler panic. The repro commit for this: I am using CLion, and the command I run is simply . I am pretty new to Rust so it might just be me doing something really wrong, but it'd be great if someone could look into this and advise. Thank you! With : With : EDIT: Updated with last working commit. EDIT2: Posted crash message with --verbose flag and clarified IDE. EDIT3: Added MSVC toolchain error.
I have a PR that will fix the underlying problem, but we need to come up with a reproduction case to avoid regressions in the future.
Removing nomination since a fix is already approved
Thank you so much for the super-fast response! However, I am not at all familiar with rust's compiler code, so if you could tell which part of the code the compiler trips upon, I can try isolating that part of the code to make a smaller reproducible example.
Reduced it down to two files: (replace obvisouly ^^) can be any primtive type as , , , . Haven't managed to get it down to one file sadly :/
is there a problem of adding the test in two files (with )? if not, I could try to work on this as a first issue.
No, that's totally fine. Go for it!

<ins> // compile-flags: --edition=2018 pub use u32; </ins>


Question:
Hello, I was working on my toy project here: The project was compiling and running fine at this commit: However, I decided I wanted to move functionality out of and into , so I moved all of it except the declarations, and then tried to compile. This led to the compiler panic. The repro commit for this: I am using CLion, and the command I run is simply . I am pretty new to Rust so it might just be me doing something really wrong, but it'd be great if someone could look into this and advise. Thank you! With : With : EDIT: Updated with last working commit. EDIT2: Posted crash message with --verbose flag and clarified IDE. EDIT3: Added MSVC toolchain error.
I have a PR that will fix the underlying problem, but we need to come up with a reproduction case to avoid regressions in the future.
Removing nomination since a fix is already approved
Thank you so much for the super-fast response! However, I am not at all familiar with rust's compiler code, so if you could tell which part of the code the compiler trips upon, I can try isolating that part of the code to make a smaller reproducible example.
Reduced it down to two files: (replace obvisouly ^^) can be any primtive type as , , , . Haven't managed to get it down to one file sadly :/
is there a problem of adding the test in two files (with )? if not, I could try to work on this as a first issue.
No, that's totally fine. Go for it!

<ins> // Regression test for #60976: ICE (with <=1.36.0) when another file had `use <primitive_type>;`. // check-pass // aux-build:extern-use-primitive-type-lib.rs extern crate extern_use_primitive_type_lib; fn main() {} </ins>


Question:
gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:

use rustc::hir::def::{Res, DefKind}; use rustc::hir::def_id::DefId; use rustc::lint; <del> use rustc::ty; </del> <ins> use rustc::ty::{self, Ty}; </ins> use rustc::ty::adjustment; use rustc_data_structures::fx::FxHashMap; use lint::{LateContext, EarlyContext, LintContext, LintArray};


Question:
gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:

return; } <del> let t = cx.tables.expr_ty(&expr); let type_permits_lack_of_use = if t.is_unit() || cx.tcx.is_ty_uninhabited_from( cx.tcx.hir().get_module_parent_by_hir_id(expr.hir_id), t) { true } else { match t.sty { ty::Adt(def, _) => check_must_use(cx, def.did, s.span, "", ""), ty::Opaque(def, _) => { let mut must_use = false; for (predicate, _) in &cx.tcx.predicates_of(def).predicates { if let ty::Predicate::Trait(ref poly_trait_predicate) = predicate { let trait_ref = poly_trait_predicate.skip_binder().trait_ref; if check_must_use(cx, trait_ref.def_id, s.span, "implementer of ", "") { must_use = true; break; } } } must_use } ty::Dynamic(binder, _) => { let mut must_use = false; for predicate in binder.skip_binder().iter() { if let ty::ExistentialPredicate::Trait(ref trait_ref) = predicate { if check_must_use(cx, trait_ref.def_id, s.span, "", " trait object") { must_use = true; break; } } } must_use } _ => false, } }; </del> <ins> let ty = cx.tables.expr_ty(&expr); let type_permits_lack_of_use = check_must_use_ty(cx, ty, &expr, s.span, ""); </ins> let mut fn_warned = false; let mut op_warned = false;


Question:
gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:

_ => None }; if let Some(def_id) = maybe_def_id { <del> fn_warned = check_must_use(cx, def_id, s.span, "return value of ", ""); </del> <ins> fn_warned = check_must_use_def(cx, def_id, s.span, "return value of ", ""); </ins> } else if type_permits_lack_of_use { // We don't warn about unused unit or uninhabited types. // (See https://github.com/rust-lang/rust/issues/43806 for details.)


Question:
gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:

cx.span_lint(UNUSED_RESULTS, s.span, "unused result"); } <del> fn check_must_use( </del> <ins> // Returns whether an error has been emitted (and thus another does not need to be later). fn check_must_use_ty<'tcx>( cx: &LateContext<'_, 'tcx>, ty: Ty<'tcx>, expr: &hir::Expr, span: Span, descr_post_path: &str, ) -> bool { if ty.is_unit() || cx.tcx.is_ty_uninhabited_from( cx.tcx.hir().get_module_parent_by_hir_id(expr.hir_id), ty) { return true; } match ty.sty { ty::Adt(def, _) => check_must_use_def(cx, def.did, span, "", descr_post_path), ty::Opaque(def, _) => { let mut has_emitted = false; for (predicate, _) in &cx.tcx.predicates_of(def).predicates { if let ty::Predicate::Trait(ref poly_trait_predicate) = predicate { let trait_ref = poly_trait_predicate.skip_binder().trait_ref; let def_id = trait_ref.def_id; if check_must_use_def(cx, def_id, span, "implementer of ", "") { has_emitted = true; break; } } } has_emitted } ty::Dynamic(binder, _) => { let mut has_emitted = false; for predicate in binder.skip_binder().iter() { if let ty::ExistentialPredicate::Trait(ref trait_ref) = predicate { let def_id = trait_ref.def_id; if check_must_use_def(cx, def_id, span, "", " trait object") { has_emitted = true; break; } } } has_emitted } ty::Tuple(ref tys) => { let mut has_emitted = false; let spans = if let hir::ExprKind::Tup(comps) = &expr.node { debug_assert_eq!(comps.len(), tys.len()); comps.iter().map(|e| e.span).collect() } else { vec![] }; for (i, ty) in tys.iter().map(|k| k.expect_ty()).enumerate() { let descr_post_path = &format!(" in tuple element {}", i); let span = *spans.get(i).unwrap_or(&span); if check_must_use_ty(cx, ty, expr, span, descr_post_path) { has_emitted = true; } } has_emitted } _ => false, } } // Returns whether an error has been emitted (and thus another does not need to be later). fn check_must_use_def( </ins> cx: &LateContext<'_, '_>, def_id: DefId, <del> sp: Span, </del> <ins> span: Span, </ins> descr_pre_path: &str, descr_post_path: &str, ) -> bool {


Question:
gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:

if attr.check_name(sym::must_use) { let msg = format!("unused {}`{}`{} that must be used", descr_pre_path, cx.tcx.def_path_str(def_id), descr_post_path); <del> let mut err = cx.struct_span_lint(UNUSED_MUST_USE, sp, &msg); </del> <ins> let mut err = cx.struct_span_lint(UNUSED_MUST_USE, span, &msg); </ins> // check for #[must_use = "..."] if let Some(note) = attr.value_str() { err.note(&note.as_str());


Question:
gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:

<ins> #![deny(unused_must_use)] fn foo() -> (Result<(), ()>, ()) { (Ok::<(), ()>(()), ()) } fn main() { (Ok::<(), ()>(()),); //~ ERROR unused `std::result::Result` (Ok::<(), ()>(()), 0, Ok::<(), ()>(()), 5); //~^ ERROR unused `std::result::Result` //~^^ ERROR unused `std::result::Result` foo(); //~ ERROR unused `std::result::Result` ((Err::<(), ()>(()), ()), ()); //~ ERROR unused `std::result::Result` } </ins>


Question:
gives a warning, but does not.
suggested that we test this out with crater to see if this would generate much substantial noise and how common it would be.
I'd expect it'd be a pretty substantial source of warnings, but that's exactly why I think we should introduce it. People compiling with are asking for these sorts of bugs to be caught, and we should serve them appropriately ;) In any case, running crater would require having an implementation to do a crater run on, so let's do it!
Let's do it. (I'd personally even like an attribute to allow people to opt-in to this for , for example, when T is itself . That way if I make a , I'll get a warning on that I normally wouldn't want but plausibly do now that I'm getting s in the s.)
I've opened a pull request to try this out:
We discussed this on the language team meeting; folks felt generally positive, but we'd like to do a crater run to see what the impact would be like and if there would be many false positives.
I tried this using but it does not seemed to complain when the part of is not used, is the the correct behavior? I hit this when doing where I didn't use part of the tuple which cause it to not work, which I did not know is required to be used.
putting it into a binding, even an unused one, is considered a use, like how doesn't lint. With just calling it lints:

<ins> error: unused `std::result::Result` in tuple element 0 that must be used --> $DIR/must_use-tuple.rs:8:6 | LL |     (Ok::<(), ()>(()),); |      ^^^^^^^^^^^^^^^^ | note: lint level defined here --> $DIR/must_use-tuple.rs:1:9 | LL | #![deny(unused_must_use)] |         ^^^^^^^^^^^^^^^ = note: this `Result` may be an `Err` variant, which should be handled error: unused `std::result::Result` in tuple element 0 that must be used --> $DIR/must_use-tuple.rs:10:6 | LL |     (Ok::<(), ()>(()), 0, Ok::<(), ()>(()), 5); |      ^^^^^^^^^^^^^^^^ | = note: this `Result` may be an `Err` variant, which should be handled error: unused `std::result::Result` in tuple element 2 that must be used --> $DIR/must_use-tuple.rs:10:27 | LL |     (Ok::<(), ()>(()), 0, Ok::<(), ()>(()), 5); |                           ^^^^^^^^^^^^^^^^ | = note: this `Result` may be an `Err` variant, which should be handled error: unused `std::result::Result` in tuple element 0 that must be used --> $DIR/must_use-tuple.rs:14:5 | LL |     foo(); |     ^^^^^^ | = note: this `Result` may be an `Err` variant, which should be handled error: unused `std::result::Result` in tuple element 0 that must be used --> $DIR/must_use-tuple.rs:16:6 | LL |     ((Err::<(), ()>(()), ()), ()); |      ^^^^^^^^^^^^^^^^^^^^^^^ | = note: this `Result` may be an `Err` variant, which should be handled error: aborting due to 5 previous errors </ins>


Question:
A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .

self.tcx().mk_const( ty::Const { val: ConstValue::Infer(InferConst::Canonical(self.binder_index, var.into())), <del> ty: const_var.ty, </del> <ins> ty: self.fold_ty(const_var.ty), </ins> } ) }


Question:
A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .

<ins> // revisions:rpass1 #![feature(const_generics)] struct Struct<T>(T); impl<T, const N: usize> Struct<[T; N]> { fn f() {} fn g() { Self::f(); } } fn main() { Struct::<[u32; 3]>::g(); } </ins>


Question:
A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .

<ins> // revisions:rpass1 #![feature(const_generics)] struct FakeArray<T, const N: usize>(T); impl<T, const N: usize> FakeArray<T, { N }> { fn len(&self) -> usize { N } } fn main() { let fa = FakeArray::<u32, { 32 }>(1); assert_eq!(fa.len(), 32); } </ins>


Question:
A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .

<ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct S<T, const N: usize>([T; N]); fn f<T, const N: usize>(x: T) -> S<T, {N}> { panic!() } fn main() { f(0u8); //[cfail1]~^ ERROR type annotations needed } </ins>