Question:
While logged in as on Linux:: the Rust repo The suggestion to run isn't helpful if you don't already have a Rust toolchain installed. That leaves: "Alternatively, use the pre-vendored dist component." It's completely unclear to me what this means or how to do it. Perhaps providing a link to documentation would be useful. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh this is very funny, is what rustup calls it, which is of course completely unhelpful in this scenario where you don't have rustup and are building from source. Mentoring instructions: should link to
Hmm, I guess for this particular scenario you might be building from a commit other than latest master as well. We do technically package it for individual commits: but AFAIK that isn't documented anywhere. Maybe we should add it to forge?
claim
hello, i'm taking the liberty of claiming this pull request, but I'd like some information. Should I propose a solution (like the curl command with the right url?) or just propose the documentation page?
claim
claim

eprint('ERROR: vendoring required, but vendor directory does not exist.') eprint('       Run `cargo vendor {}` to initialize the ' 'vendor directory.'.format(sync_dirs)) <del> eprint('Alternatively, use the pre-vendored `rustc-src` dist component.') </del> <ins> eprint('       Alternatively, use the pre-vendored `rustc-src` dist component.') eprint('       To get a stable/beta/nightly version, download it from: ') eprint('       ' 'https://forge.rust-lang.org/infra/other-installation-methods.html#source-code') eprint('       To get a specific commit version, download it using the below URL,') eprint('       replacing <commit> with a specific commit checksum: ') eprint('       ' 'https://ci-artifacts.rust-lang.org/rustc-builds/<commit>/rustc-nightly-src.tar.xz') eprint('       Once you have the source downloaded, place the vendor directory') eprint('       from the archive in the root of the rust project.') </ins> raise Exception("{} not found".format(vendor_dir)) if not os.path.exists(cargo_dir):


Question:
I tried this code: I expected to see this happen: rustc prints the target spec successfully, because it knows it exists: Instead, this happened: rustc fails to load the LLVM specification: Note that this is different from the error we emit for an unrecognized target: Also, this only happens for local builds, because we don't use the LLVM in the component in rustup, only when building rustc from source. ... wtf ??? HEAD is branched from
cc do you know what could be going wrong here?
Thank you for bringing this to my attention. It is possible that the locally builds has enabled , and that prebuilt LLVM does not support LoongArch architecture. It would be great if you could provide specific steps to reproduce. Thank you.
Yes, that's exactly what's happened, I have download-ci-llvm enabled and the prebuilt LLVM differs. Here's steps to reproduce:
The RustDev component builds LLVM here: but I'm not sure how that differs from the component?
I think the difference is that the of ci-llvm does not contain LoongArch, but locally it does. Is it time to update ci-llvm?
Maybe need to bump download-ci-llvm-stamp to pick up the LoongArch enablement?
Thank you for catching that. I was mistaken to think that the cached prebuilt ci-llvm would automatically update over time.
no worries :) it updates every six weeks when we make a new release, or if the submodule is updated, but it's cached until then so it's not constantly re-uploaded on every change to bootstrap.
Is there any way CI could help prevent such problems? Like, complain if gets changed but the stamp file does not, or something like that?
we can use heuristics, but they're only heuristics and I wouldn't want to fail CI on them. That said, having rustbot leave a comment if you touch rustc_llvm or seems reasonable, so the PR author can make a judgement call but also doesn't forget about the stamp.

Change this file to make users of the `download-ci-llvm` configuration download a new version of LLVM from CI, even if the LLVM submodule hasn’t changed. <del> Last change is for: https://github.com/rust-lang/rust/pull/109373 </del> <ins> Last change is for: https://github.com/rust-lang/rust/pull/96971 </ins>


Question:
I tried this code: I expected to see this happen: No panic during runtime Instead, this happened: Panicked during runtime <details<summaryFormat: was already formatted once</summary</details<!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.70 (beta) and Rust 1.69 (stable) <!-- Provide the version you are using that has the regression. --: None I also reported this here , but I think this one is on . assigning you, because I suspect this has something to do with recent changes.
I'll look into this tomorrow. Can you check if it also happens with -Zflatten-format-args=no?
This is unrelated to and was caused by a recent change to the panic runtime. I've posted a fix at

<ins> // run-fail // check-run-results // exec-env:RUST_BACKTRACE=0 // Test that we format the panic message only once. // Regression test for https://github.com/rust-lang/rust/issues/110717 use std::fmt; struct PrintOnFmt; impl fmt::Display for PrintOnFmt { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { eprintln!("fmt"); f.write_str("PrintOnFmt") } } fn main() { panic!("{}", PrintOnFmt) } </ins>


Question:
I tried this code: I expected to see this happen: No panic during runtime Instead, this happened: Panicked during runtime <details<summaryFormat: was already formatted once</summary</details<!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.70 (beta) and Rust 1.69 (stable) <!-- Provide the version you are using that has the regression. --: None I also reported this here , but I think this one is on . assigning you, because I suspect this has something to do with recent changes.
I'll look into this tomorrow. Can you check if it also happens with -Zflatten-format-args=no?
This is unrelated to and was caused by a recent change to the panic runtime. I've posted a fix at

<ins> fmt thread 'main' panicked at 'PrintOnFmt', $DIR/fmt-only-once.rs:20:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace </ins>


Question:
Happened during probably since cc
You'll need to delete the directory. There was probably a file left behind, and git won't delete the directory automatically.
Hm, there is no such directory ?! :sweatsmile: There is a though
My fault. I forgot to update Will send a PR.
What is most concerning to me is that this actually did not fail the entire , so this would/did not even break CI..? is there something we can do about that?
Run in CI probably? I supposed to run it locally before submitting a PR. However, that was an unlucky day. Something on nightly cannot build, so I blindly pushed .
Oh, sorry, I misunderstood what was going on. There have been some issues with those directories being moved around, but this was different. The issue here is that the credential helpers are being included on an "as available" basis. Because they are nightly and experimental, they were intentionally marked as being optional so that if they failed it wouldn't cause problems here on rust-lang/rust. Eventually, if it gets stabilized, this will need to change to make them required tools.

if self.target.contains("windows") { build_cred( "cargo-credential-wincred", <del> "src/tools/cargo/crates/credential/cargo-credential-wincred", </del> <ins> "src/tools/cargo/credential/cargo-credential-wincred", </ins> ); } if self.target.contains("apple-darwin") { build_cred( "cargo-credential-macos-keychain", <del> "src/tools/cargo/crates/credential/cargo-credential-macos-keychain", </del> <ins> "src/tools/cargo/credential/cargo-credential-macos-keychain", </ins> ); } build_cred( "cargo-credential-1password", <del> "src/tools/cargo/crates/credential/cargo-credential-1password", </del> <ins> "src/tools/cargo/credential/cargo-credential-1password", </ins> ); cargo_bin_path }


Question:
There should be a test for ensuring that it does not have the same bug as and , that inside of the const refers to instead of inferring a lifetime. The following code is what passes and should be as a test: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
are you still working on this? If not, I would be happy to claim :slightlysmilingface:
there is no activity from them for almost a month, so you are free to claim it now
claim

<ins> // check-pass #![feature(inline_const)] fn main() { let _my_usize = const { let a = 10_usize; let b: &'_ usize = &a; *b }; } </ins>


Question:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with

} } <del> impl Visitor<'_> for CanConstProp { </del> <ins> impl<'tcx> Visitor<'tcx> for CanConstProp { fn visit_place(&mut self, place: &Place<'tcx>, mut context: PlaceContext, loc: Location) { use rustc_middle::mir::visit::PlaceContext::*; // Dereferencing just read the addess of `place.local`. if place.projection.first() == Some(&PlaceElem::Deref) { context = NonMutatingUse(NonMutatingUseContext::Copy); } self.visit_local(place.local, context, loc); self.visit_projection(place.as_ref(), context, loc); } </ins> fn visit_local(&mut self, local: Local, context: PlaceContext, _: Location) { use rustc_middle::mir::visit::PlaceContext::*; match context { <del> // Projections are fine, because `&mut foo.x` will be caught by // `MutatingUseContext::Borrow` elsewhere. MutatingUse(MutatingUseContext::Projection) </del> // These are just stores, where the storing is not propagatable, but there may be later // mutations of the same local via `Store` | MutatingUse(MutatingUseContext::Call)


Question:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with

NonMutatingUse(NonMutatingUseContext::Copy) | NonMutatingUse(NonMutatingUseContext::Move) | NonMutatingUse(NonMutatingUseContext::Inspect) <del> | NonMutatingUse(NonMutatingUseContext::Projection) </del> | NonMutatingUse(NonMutatingUseContext::PlaceMention) | NonUse(_) => {}


Question:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with

trace!("local {:?} can't be propagated because it's used: {:?}", local, context); self.can_const_prop[local] = ConstPropMode::NoPropagation; } <ins> MutatingUse(MutatingUseContext::Projection) | NonMutatingUse(NonMutatingUseContext::Projection) => bug!("visit_place should not pass {context:?} for {local:?}"), </ins> } } }


Question:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with

<ins> - // MIR for `fn0` before ConstProp + // MIR for `fn0` after ConstProp fn fn0() -> bool { let mut _0: bool;                    // return place in scope 0 at $DIR/address_of_pair.rs:+0:17: +0:21 let mut _1: !;                       // in scope 0 at $DIR/address_of_pair.rs:+0:22: +9:2 let mut _2: (i32, bool);             // in scope 0 at $DIR/address_of_pair.rs:+1:9: +1:17 let _4: ();                          // in scope 0 at $DIR/address_of_pair.rs:+4:5: +6:6 let mut _6: bool;                    // in scope 0 at $DIR/address_of_pair.rs:+7:16: +7:22 scope 1 { debug pair => _2;                // in scope 1 at $DIR/address_of_pair.rs:+1:9: +1:17 let _3: *mut bool;               // in scope 1 at $DIR/address_of_pair.rs:+2:9: +2:12 scope 2 { debug ptr => _3;             // in scope 2 at $DIR/address_of_pair.rs:+2:9: +2:12 let _5: bool;                // in scope 2 at $DIR/address_of_pair.rs:+7:9: +7:12 scope 3 { } scope 4 { debug ret => _5;         // in scope 4 at $DIR/address_of_pair.rs:+7:9: +7:12 } } } bb0: { StorageLive(_2);                 // scope 0 at $DIR/address_of_pair.rs:+1:9: +1:17 _2 = (const 1_i32, const false); // scope 0 at $DIR/address_of_pair.rs:+1:20: +1:30 StorageLive(_3);                 // scope 1 at $DIR/address_of_pair.rs:+2:9: +2:12 _3 = &raw mut (_2.1: bool);      // scope 1 at $SRC_DIR/core/src/ptr/mod.rs:LL:COL _2 = (const 1_i32, const false); // scope 2 at $DIR/address_of_pair.rs:+3:5: +3:22 StorageLive(_4);                 // scope 2 at $DIR/address_of_pair.rs:+4:5: +6:6 (*_3) = const true;              // scope 3 at $DIR/address_of_pair.rs:+5:9: +5:20 _4 = const ();                   // scope 3 at $DIR/address_of_pair.rs:+4:5: +6:6 StorageDead(_4);                 // scope 2 at $DIR/address_of_pair.rs:+6:5: +6:6 StorageLive(_5);                 // scope 2 at $DIR/address_of_pair.rs:+7:9: +7:12 StorageLive(_6);                 // scope 2 at $DIR/address_of_pair.rs:+7:16: +7:22 _6 = (_2.1: bool);               // scope 2 at $DIR/address_of_pair.rs:+7:16: +7:22 _5 = Not(move _6);               // scope 2 at $DIR/address_of_pair.rs:+7:15: +7:22 StorageDead(_6);                 // scope 2 at $DIR/address_of_pair.rs:+7:21: +7:22 _0 = _5;                         // scope 4 at $DIR/address_of_pair.rs:+8:12: +8:15 StorageDead(_5);                 // scope 2 at $DIR/address_of_pair.rs:+9:1: +9:2 StorageDead(_3);                 // scope 1 at $DIR/address_of_pair.rs:+9:1: +9:2 StorageDead(_2);                 // scope 0 at $DIR/address_of_pair.rs:+9:1: +9:2 return;                          // scope 0 at $DIR/address_of_pair.rs:+9:2: +9:2 } } </ins>


Question:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with

<ins> // unit-test: ConstProp // EMIT_MIR address_of_pair.fn0.ConstProp.diff pub fn fn0() -> bool { let mut pair = (1, false); let ptr = core::ptr::addr_of_mut!(pair.1); pair = (1, false); unsafe { *ptr = true; } let ret = !pair.1; return ret; } pub fn main() { println!("{}", fn0()); } </ins>


Question:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with

bb0: { StorageLive(_1);                 // scope 0 at $DIR/const_prop_miscompile.rs:+1:9: +1:14 <del> -         _1 = (const 1_i32,);             // scope 0 at $DIR/const_prop_miscompile.rs:+1:17: +1:21 +         _1 = const (1_i32,);             // scope 0 at $DIR/const_prop_miscompile.rs:+1:17: +1:21 </del> <ins> _1 = (const 1_i32,);             // scope 0 at $DIR/const_prop_miscompile.rs:+1:17: +1:21 </ins> StorageLive(_2);                 // scope 1 at $DIR/const_prop_miscompile.rs:+2:5: +4:6 StorageLive(_3);                 // scope 2 at $DIR/const_prop_miscompile.rs:+3:10: +3:22 _3 = &raw mut (_1.0: i32);       // scope 2 at $DIR/const_prop_miscompile.rs:+3:10: +3:22


Question:
This code has UB under Stacked Borrows in Miri, but is fine with , and it should print However, under and above, it prints : cc
Here's a pure-surface Rust reproduction
any guess which MIR opt might be the culprit here?
Even more minimized reproducer: My first guess would be that some MIR analysis assumes that means that no pointer to can exist any more -- with Stacked Borrows that was true, but not with Tree Borrows. I usually push back against making Stacked Borrows assumptions in optimizations but looks like something slipped through? Cc
Even stranger, with Rust 1.69 we get . This goes back all the way to ; before that, we didn't have . Only beta and nightly without optimizations seem to do this correctly.
Does this look like the bad optimization?
yes, very much so. Specifically the is wrong, the rest then follows from that. Did ConstProp never learn that locals that have their address taken cannot be propagated?
I'm about to be busy for a few hours, so if someone else wants to bisect what changed with they should do that. I'll check back later.
I've been suspecting such a bug without managing to reproduce it for a few months. The bug is in the visitor, which mistreats place context. I can make a targeted fix in the hour.
I'm curious, how did you come up with this example?
I'm making a fuzzer targeting custom MIR :D It's still quite incomplete and currently hosted on an ETH Zürich private GitLab instance I guess I should make a public mirror on GitHub soon...
That is awesome! This is exactly the kind of stuff I was hoping to find with one.
Ah so should we report these? I think I read somewhere that custom mir is likely to get wrong and would always cause crashes then or something which is why I have ignored all of the / ICEs that I came across.
This isn't an ICE, this is a change in behavior due to enabling an optimization.
ah right sorry, I was confused with

bb0: { StorageLive(_1);                 // scope 0 at $DIR/const_prop_miscompile.rs:+1:9: +1:14 <del> -         _1 = (const 1_i32,);             // scope 0 at $DIR/const_prop_miscompile.rs:+1:17: +1:21 +         _1 = const (1_i32,);             // scope 0 at $DIR/const_prop_miscompile.rs:+1:17: +1:21 </del> <ins> _1 = (const 1_i32,);             // scope 0 at $DIR/const_prop_miscompile.rs:+1:17: +1:21 </ins> StorageLive(_2);                 // scope 1 at $DIR/const_prop_miscompile.rs:+2:6: +2:14 _2 = &mut (_1.0: i32);           // scope 1 at $DIR/const_prop_miscompile.rs:+2:6: +2:14 (*_2) = const 5_i32;             // scope 1 at $DIR/const_prop_miscompile.rs:+2:5: +2:18


Question:
I decided to try address sanitizer on WSL Ubuntu today, but ran into 2 errors. These errors are only present when using the sanitizer, so my crate compiles normally. To give context there are 2 crates: and . On there is a procedural macro called , which is named the same as my crate which I am re-exporting it to. I don't really know if this a bug or a problem on my end, but I thought I'd mention it just in case. : I included the full error output in a file below
If you use sanitizers you need to pass the flag, but I guess you missed it. See also :
Oh I did miss it and that fixed it. The documentation made it sound optional though, so I didn't realize that was the issue. Thanks for the quick reply!
Re-opening because the error is very confusing. See also
On the error is: which isn't great, but at least suggests some issue related to asan. On the error is: Which is very confusing. was merged between those two versions and changes in which cases E0519 is emitted. ping who wrote that PR.

assert_eq!(self.metas.len(), self.stable_crate_ids.len()); let num = CrateNum::new(self.stable_crate_ids.len()); if let Some(&existing) = self.stable_crate_ids.get(&root.stable_crate_id()) { <del> let crate_name0 = root.name(); if let Some(crate_name1) = self.metas[existing].as_ref().map(|data| data.name()) { </del> <ins> // Check for (potential) conflicts with the local crate if existing == LOCAL_CRATE { Err(CrateError::SymbolConflictsCurrent(root.name())) } else if let Some(crate_name1) = self.metas[existing].as_ref().map(|data| data.name()) { let crate_name0 = root.name(); </ins> Err(CrateError::StableCrateIdCollision(crate_name0, crate_name1)) } else { <del> Err(CrateError::SymbolConflictsCurrent(crate_name0)) </del> <ins> Err(CrateError::NotFound(root.name())) </ins> } } else { self.metas.push(None);


Question:
I decided to try address sanitizer on WSL Ubuntu today, but ran into 2 errors. These errors are only present when using the sanitizer, so my crate compiles normally. To give context there are 2 crates: and . On there is a procedural macro called , which is named the same as my crate which I am re-exporting it to. I don't really know if this a bug or a problem on my end, but I thought I'd mention it just in case. : I included the full error output in a file below
If you use sanitizers you need to pass the flag, but I guess you missed it. See also :
Oh I did miss it and that fixed it. The documentation made it sound optional though, so I didn't realize that was the issue. Thanks for the quick reply!
Re-opening because the error is very confusing. See also
On the error is: which isn't great, but at least suggests some issue related to asan. On the error is: Which is very confusing. was merged between those two versions and changes in which cases E0519 is emitted. ping who wrote that PR.

DlSym(String), LocatorCombined(Box<CombinedLocatorError>), NonDylibPlugin(Symbol), <ins> NotFound(Symbol), </ins> } enum MetadataError<'a> {


Question:
I decided to try address sanitizer on WSL Ubuntu today, but ran into 2 errors. These errors are only present when using the sanitizer, so my crate compiles normally. To give context there are 2 crates: and . On there is a procedural macro called , which is named the same as my crate which I am re-exporting it to. I don't really know if this a bug or a problem on my end, but I thought I'd mention it just in case. : I included the full error output in a file below
If you use sanitizers you need to pass the flag, but I guess you missed it. See also :
Oh I did miss it and that fixed it. The documentation made it sound optional though, so I didn't realize that was the issue. Thanks for the quick reply!
Re-opening because the error is very confusing. See also
On the error is: which isn't great, but at least suggests some issue related to asan. On the error is: Which is very confusing. was merged between those two versions and changes in which cases E0519 is emitted. ping who wrote that PR.

CrateError::NonDylibPlugin(crate_name) => { sess.emit_err(errors::NoDylibPlugin { span, crate_name }); } <ins> CrateError::NotFound(crate_name) => { sess.emit_err(errors::CannotFindCrate { span, crate_name, add_info: String::new(), missing_core, current_crate: sess.opts.crate_name.clone().unwrap_or("<unknown>".to_string()), is_nightly_build: sess.is_nightly_build(), profiler_runtime: Symbol::intern(&sess.opts.unstable_opts.profiler_runtime), locator_triple: sess.opts.target_triple.clone(), }); } </ins> } } }


Question:
I decided to try address sanitizer on WSL Ubuntu today, but ran into 2 errors. These errors are only present when using the sanitizer, so my crate compiles normally. To give context there are 2 crates: and . On there is a procedural macro called , which is named the same as my crate which I am re-exporting it to. I don't really know if this a bug or a problem on my end, but I thought I'd mention it just in case. : I included the full error output in a file below
If you use sanitizers you need to pass the flag, but I guess you missed it. See also :
Oh I did miss it and that fixed it. The documentation made it sound optional though, so I didn't realize that was the issue. Thanks for the quick reply!
Re-opening because the error is very confusing. See also
On the error is: which isn't great, but at least suggests some issue related to asan. On the error is: Which is very confusing. was merged between those two versions and changes in which cases E0519 is emitted. ping who wrote that PR.

--crate-type=rlib  --edition=2018  c.rs 2>&1 | tee $(TMPDIR)/output.txt || exit 0 <del> $(CGREP) E0519 < $(TMPDIR)/output.txt </del> <ins> $(CGREP) E0463 < $(TMPDIR)/output.txt </ins> $(CGREP) -v "internal compiler error" < $(TMPDIR)/output.txt


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic

} if tcx.sess.opts.unstable_opts.drop_tracking_mir && let DefKind::Generator = tcx.def_kind(closure_def_id) <ins> && let Some(generator_layout) = tcx.mir_generator_witnesses(closure_def_id) </ins> { <del> let generator_layout = tcx.mir_generator_witnesses(closure_def_id); </del> for interior_ty in &generator_layout.field_tys { label_match(interior_ty.ty, interior_ty.source_info.span); }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic

if encode_opt { record!(self.tables.optimized_mir[def_id.to_def_id()] <- tcx.optimized_mir(def_id)); <del> if tcx.sess.opts.unstable_opts.drop_tracking_mir && let DefKind::Generator = self.tcx.def_kind(def_id) { record!(self.tables.mir_generator_witnesses[def_id.to_def_id()] <- tcx.mir_generator_witnesses(def_id)); </del> <ins> if tcx.sess.opts.unstable_opts.drop_tracking_mir && let DefKind::Generator = self.tcx.def_kind(def_id) && let Some(witnesses) = tcx.mir_generator_witnesses(def_id) { record!(self.tables.mir_generator_witnesses[def_id.to_def_id()] <- witnesses); </ins> } } if encode_const {


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic

} } <del> query mir_generator_witnesses(key: DefId) -> &'tcx mir::GeneratorLayout<'tcx> { </del> <ins> query mir_generator_witnesses(key: DefId) -> &'tcx Option<mir::GeneratorLayout<'tcx>> { </ins> arena_cache desc { |tcx| "generator witness types for `{}`", tcx.def_path_str(key) } cache_on_disk_if { key.is_local() }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic

self, def_id: DefId, ) -> impl Iterator<Item = ty::EarlyBinder<Ty<'tcx>>> { <del> let generator_layout = &self.mir_generator_witnesses(def_id); </del> <ins> let generator_layout = self.mir_generator_witnesses(def_id); </ins> generator_layout <del> .field_tys .iter() </del> <ins> .as_ref() .map_or_else(|| [].iter(), |l| l.field_tys.iter()) </ins> .filter(|decl| !decl.ignore_for_traits) .map(|decl| ty::EarlyBinder(decl.ty)) }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic

pub(crate) fn mir_generator_witnesses<'tcx>( tcx: TyCtxt<'tcx>, def_id: LocalDefId, <del> ) -> GeneratorLayout<'tcx> { </del> <ins> ) -> Option<GeneratorLayout<'tcx>> { </ins> assert!(tcx.sess.opts.unstable_opts.drop_tracking_mir); let (body, _) = tcx.mir_promoted(def_id);


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic

// Get the interior types and substs which typeck computed let movable = match *gen_ty.kind() { ty::Generator(_, _, movability) => movability == hir::Movability::Movable, <ins> ty::Error(_) => return None, </ins> _ => span_bug!(body.span, "unexpected generator type {}", gen_ty), };


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic

check_suspend_tys(tcx, &generator_layout, &body); <del> generator_layout </del> <ins> Some(generator_layout) </ins> } impl<'tcx> MirPass<'tcx> for StateTransform {


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic

&& generator_did.is_local() // Try to avoid cycles. && !generator_within_in_progress_typeck <ins> && let Some(generator_info) = self.tcx.mir_generator_witnesses(generator_did) </ins> { <del> let generator_info = &self.tcx.mir_generator_witnesses(generator_did); </del> debug!(?generator_info); 'find_source: for (variant, source_info) in generator_info.variant_fields.iter().zip(&generator_info.variant_source_info) {


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic

<ins> // compile-flags: -Zdrop-tracking-mir --edition=2021 #![feature(generators)] pub async fn async_bad_body() { match true {} //~ ERROR non-exhaustive patterns: type `bool` is non-empty } pub fn generator_bad_body() { || { // 'non-exhaustive pattern' only seems to be reported once, so this annotation doesn't work // keep the function around so we can make sure it doesn't ICE match true {}; // ERROR non-exhaustive patterns: type `bool` is non-empty yield (); }; } fn main() {} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic

<ins> error[E0004]: non-exhaustive patterns: type `bool` is non-empty --> $DIR/drop-tracking-error-body.rs:6:11 | LL |     match true {} |           ^^^^ | = note: the matched value is of type `bool` help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern as shown | LL ~     match true { LL +         _ => todo!(), LL ~     } | error: aborting due to previous error For more information about this error, try `rustc --explain E0004`. </ins>


Question:
Apologies for the not-very-readable reproduction. It was generated by a fuzzer and this is the best I can minimise it to. The program has no UB under , and Miri prints 22, this is also the result with Very strangely, if you drop to 0 or 1, the result becomes 11 which is wrong. Reproducible on both Apple Silicon macOS and x8664 Linux cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Executing the program trough reveals that under Stacked Borrows there is UB:
It does, and since the UB involves and which carry the wrong and right results (11 and 22), the miscompilation is likely due to an assumption that was valid under SB but not under TB. Though this bug probably isn't in mir-opt as a low gives the wrong result. It could be in IR gen or LLVM itself
(defensively labeled this as unsound because that seems more likely than not)
is relevant:
Here's the diff that ConstProp produces. Does this look relevant? Relevant stuff is buried down in the pile of scopes ugh. The relevant diff smells like
This is the relevant diff, but ConstProp is correct here: ( in the original source) is not aliased by anything, 6 can be propagated. Indeed the result with ConstProp is right and without_ is wrong, it actually mitigated a bug further down the pipeline
Slightly edited to make the executed control flow simpler: no loop is taken more than once except for , which executes one line and then returns on the second iteration. <details<summarySee</summary</details
I put this together to look through what LLVM is doing with and without ConstProp enabled:
Regression in nightly-2022-08-13 which was when we did the llvm 15 upgrade
WG-prioritization assigning priority (). Provisionally assigning a P-high priority, will be discussed in the next compiler meeting. label -I-prioritize +P-high +I-compiler-nominated
Note that the compiler is not intended to exploit SB yet so this is still a bug (either in rustc, or in TB failing to represent some UB that we really need).
Since this only happens on low optimization levels, and based on the regression range, looks like an LLVM issue masked by rustc ConstProp? Cc
This version has no UB under Stacked Borrows but still triggers the misoptimisation
I've started to minimize it further: more updates will come later repo:
I don't have a compiled LLVM lying around, could you run your reduction with an LLVM built with ASan? My fuzzer was also running into this segfault , and on this repro when I tried , I would get segfaults if I put the index too low (i.e. disabling too many optimisations!). I have a suspicion that they are related
I don't have an LLVM built with ASan around either right now, but I do have alive2 yelling at me when I feed in a reduced version of this test case. I'll create an issue soon I guess. But I can look into ASan as well.
I checked with ASan and it all looked fine. As backlinked already, I also created an LLVM issue: llvm/llvm-project
The bug has been fixed in assign

[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/16.0-2023-04-05 </del> <ins> branch = rustc/16.0-2023-06-05 </ins> [submodule "src/doc/embedded-book"] path = src/doc/embedded-book url = https://github.com/rust-embedded/book.git


Question:
Apologies for the not-very-readable reproduction. It was generated by a fuzzer and this is the best I can minimise it to. The program has no UB under , and Miri prints 22, this is also the result with Very strangely, if you drop to 0 or 1, the result becomes 11 which is wrong. Reproducible on both Apple Silicon macOS and x8664 Linux cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Executing the program trough reveals that under Stacked Borrows there is UB:
It does, and since the UB involves and which carry the wrong and right results (11 and 22), the miscompilation is likely due to an assumption that was valid under SB but not under TB. Though this bug probably isn't in mir-opt as a low gives the wrong result. It could be in IR gen or LLVM itself
(defensively labeled this as unsound because that seems more likely than not)
is relevant:
Here's the diff that ConstProp produces. Does this look relevant? Relevant stuff is buried down in the pile of scopes ugh. The relevant diff smells like
This is the relevant diff, but ConstProp is correct here: ( in the original source) is not aliased by anything, 6 can be propagated. Indeed the result with ConstProp is right and without_ is wrong, it actually mitigated a bug further down the pipeline
Slightly edited to make the executed control flow simpler: no loop is taken more than once except for , which executes one line and then returns on the second iteration. <details<summarySee</summary</details
I put this together to look through what LLVM is doing with and without ConstProp enabled:
Regression in nightly-2022-08-13 which was when we did the llvm 15 upgrade
WG-prioritization assigning priority (). Provisionally assigning a P-high priority, will be discussed in the next compiler meeting. label -I-prioritize +P-high +I-compiler-nominated
Note that the compiler is not intended to exploit SB yet so this is still a bug (either in rustc, or in TB failing to represent some UB that we really need).
Since this only happens on low optimization levels, and based on the regression range, looks like an LLVM issue masked by rustc ConstProp? Cc
This version has no UB under Stacked Borrows but still triggers the misoptimisation
I've started to minimize it further: more updates will come later repo:
I don't have a compiled LLVM lying around, could you run your reduction with an LLVM built with ASan? My fuzzer was also running into this segfault , and on this repro when I tried , I would get segfaults if I put the index too low (i.e. disabling too many optimisations!). I have a suspicion that they are related
I don't have an LLVM built with ASan around either right now, but I do have alive2 yelling at me when I feed in a reduced version of this test case. I'll create an issue soon I guess. But I can look into ASan as well.
I checked with ASan and it all looked fine. As backlinked already, I also created an LLVM issue: llvm/llvm-project
The bug has been fixed in assign

<del> Subproject commit 533d3f338b804d54e5d0ac4fba6276af23002d9c </del> <ins> Subproject commit 22897bce7bfedc9cd3953a33419b346936263500 </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

let scope = Scope::TraitRefBoundary { s: self.scope }; self.with(scope, |this| { walk_list!(this, visit_generic_param, generics.params); <del> for param in generics.params { match param.kind { GenericParamKind::Lifetime { .. } => {} GenericParamKind::Type { default, .. } => { if let Some(ty) = default { this.visit_ty(ty); } } GenericParamKind::Const { ty, default } => { this.visit_ty(ty); if let Some(default) = default { this.visit_body(this.tcx.hir().body(default.body)); } } } } </del> walk_list!(this, visit_where_predicate, generics.predicates); }) }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

// like implicit `?Sized` or const-param-has-ty predicates. } } <ins> match p.kind { GenericParamKind::Lifetime { .. } => {} GenericParamKind::Type { default, .. } => { if let Some(ty) = default { self.visit_ty(ty); } } GenericParamKind::Const { ty, default } => { self.visit_ty(ty); if let Some(default) = default { self.visit_body(self.tcx.hir().body(default.body)); } } } </ins> } }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> #![feature(non_lifetime_binders)] //~^ WARNING the feature `non_lifetime_binders` is incomplete and may not be safe to use and/or cause compiler crashes pub fn bar() where for<const N: usize = { (||1usize)() }> V: IntoIterator //~^ ERROR cannot find type `V` in this scope [E0412] { } fn main() { bar(); } </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> error[E0412]: cannot find type `V` in this scope --> $DIR/issue-112547.rs:8:4 | LL | }> V: IntoIterator |    ^ not found in this scope | help: you might be missing a type parameter | LL | pub fn bar<V>() |           +++ warning: the feature `non_lifetime_binders` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/issue-112547.rs:1:12 | LL | #![feature(non_lifetime_binders)] |            ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #108185 <https://github.com/rust-lang/rust/issues/108185> for more information = note: `#[warn(incomplete_features)]` on by default error: aborting due to previous error; 1 warning emitted For more information about this error, try `rustc --explain E0412`. </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2023-02-05 Regression in cc
Fixed on the latest nightly, marking as E-needs-test labels: +E-needs-test
I don't think this is actually fixed, just that the ICE cannot be triggered currently, but might resurface when the effects feature is fully implemented.

<ins> #![feature(const_trait_impl, effects)] const fn test() -> impl ~const Fn() { //~ ERROR ~const can only be applied to `#[const_trait]` traits const move || { //~ ERROR const closures are experimental let sl: &[u8] = b"foo"; match sl { [first, remainder @ ..] => { assert_eq!(first, &b'f'); } [] => panic!(), } } } fn main() {} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2023-02-05 Regression in cc
Fixed on the latest nightly, marking as E-needs-test labels: +E-needs-test
I don't think this is actually fixed, just that the ICE cannot be triggered currently, but might resurface when the effects feature is fully implemented.

<ins> error[E0658]: const closures are experimental --> $DIR/ice-112822-expected-type-for-param.rs:4:5 | LL |     const move || { |     ^^^^^ | = note: see issue #106003 <https://github.com/rust-lang/rust/issues/106003> for more information = help: add `#![feature(const_closures)]` to the crate attributes to enable error: ~const can only be applied to `#[const_trait]` traits --> $DIR/ice-112822-expected-type-for-param.rs:3:32 | LL | const fn test() -> impl ~const Fn() { |                                ^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0658`. </ins>


Question:
is left set to a dangling pointer if unwinds. This is unsound because a later call to will use that dangling pointer. There is a similar issue with and unwinding. since you're on the Stable MIR cc list: cc
if you can add it as a dependency, using would probably be better than rolling your own version.
Yea, that makes sense. I think we should look into using it for the module, too, which is how we get a within the compiler itself

"rustc_hir", "rustc_middle", "rustc_span", <ins> "scoped-tls", </ins> "tracing", ]


Question:
is left set to a dangling pointer if unwinds. This is unsound because a later call to will use that dangling pointer. There is a similar issue with and unwinding. since you're on the Stable MIR cc list: cc
if you can add it as a dependency, using would probably be better than rolling your own version.
Yea, that makes sense. I think we should look into using it for the module, too, which is how we get a within the compiler itself

rustc_middle = { path = "../rustc_middle", optional = true } rustc_span = { path = "../rustc_span", optional = true } tracing = "0.1" <ins> scoped-tls = "1.0" </ins> [features] default = [


Question:
is left set to a dangling pointer if unwinds. This is unsound because a later call to will use that dangling pointer. There is a similar issue with and unwinding. since you're on the Stable MIR cc list: cc
if you can add it as a dependency, using would probably be better than rolling your own version.
Yea, that makes sense. I think we should look into using it for the module, too, which is how we get a within the compiler itself

// Make this module private for now since external users should not call these directly. mod rustc_smir; <ins> #[macro_use] extern crate scoped_tls; </ins>


Question:
is left set to a dangling pointer if unwinds. This is unsound because a later call to will use that dangling pointer. There is a similar issue with and unwinding. since you're on the Stable MIR cc list: cc
if you can add it as a dependency, using would probably be better than rolling your own version.
Yea, that makes sense. I think we should look into using it for the module, too, which is how we get a within the compiler itself

fn rustc_tables(&mut self, f: &mut dyn FnMut(&mut Tables<'_>)); } <del> thread_local! { /// A thread local variable that stores a pointer to the tables mapping between TyCtxt /// datastructures and stable MIR datastructures. static TLV: Cell<*mut ()> = const { Cell::new(std::ptr::null_mut()) }; } </del> <ins> // A thread local variable that stores a pointer to the tables mapping between TyCtxt // datastructures and stable MIR datastructures scoped_thread_local! (static TLV: Cell<*mut ()>); </ins> pub fn run(mut context: impl Context, f: impl FnOnce()) { <del> assert!(TLV.get().is_null()); </del> <ins> assert!(!TLV.is_set()); </ins> fn g<'a>(mut context: &mut (dyn Context + 'a), f: impl FnOnce()) { <del> TLV.set(&mut context as *mut &mut _ as _); f(); TLV.replace(std::ptr::null_mut()); </del> <ins> let ptr: *mut () = &mut context as *mut &mut _ as _; TLV.set(&Cell::new(ptr), || { f(); }); </ins> } g(&mut context, f); }


Question:
is left set to a dangling pointer if unwinds. This is unsound because a later call to will use that dangling pointer. There is a similar issue with and unwinding. since you're on the Stable MIR cc list: cc
if you can add it as a dependency, using would probably be better than rolling your own version.
Yea, that makes sense. I think we should look into using it for the module, too, which is how we get a within the compiler itself

/// Loads the current context and calls a function with it. /// Do not nest these, as that will ICE. pub(crate) fn with<R>(f: impl FnOnce(&mut dyn Context) -> R) -> R { <del> let ptr = TLV.replace(std::ptr::null_mut()) as *mut &mut dyn Context; assert!(!ptr.is_null()); let ret = f(unsafe { *ptr }); TLV.set(ptr as _); ret </del> <ins> assert!(TLV.is_set()); TLV.with(|tlv| { let ptr = tlv.get(); assert!(!ptr.is_null()); f(unsafe { *(ptr as *mut &mut dyn Context) }) }) </ins> }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
This also ICEs on stable with the same error, so I don't think this is related to any of my recent changes at a glance. Having a look at it though
Regression in nightly-2021-09-01 commit[0] 2021-08-30: Auto merge of - sexxi-goose:issue-, r=nikomatsakis commit[1] 2021-08-30: Auto merge of - lcnr:cec-rename, r=oli-obk commit[2] 2021-08-31: Auto merge of - HTG-YT:edition2021-compopt-stabilization, r=m-ou-se commit[3] 2021-08-31: Auto merge of - Aaron1011:guess-foreign-head-span, r=estebank commit[4] 2021-08-31: Auto merge of - sexxi-goose:issue-, r=nikomatsakis commit[5] 2021-08-31: Auto merge of - RalfJung:miri, r=RalfJung commit[6] 2021-08-31: Auto merge of - m-ou-se:rollup-az6xtc5, r=m-ou-se commit[7] 2021-08-31: Auto merge of - m-ou-se:rollup-jeusxbo, r=m-ou-se commit[8] 2021-08-31: Auto merge of - Mark-Simulacrum:fix-rlibs, r=ehuss
I suspect that might be a false positive bisect?
ah meh, probably, if the feature gate was renamed or something, the code with the "new" feature gate might no longer trigger the ice once needed the old feature gate -_-
Bisected to nightly-2022-11-27, probably caused by . <details<summary<codecargo-bisect-rustc</codeoutput </summary</details

use rustc_hir::{HirId, Pat, PatKind}; use rustc_infer::infer; use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind}; <ins> use rustc_middle::mir::interpret::ErrorHandled; </ins> use rustc_middle::ty::{self, Adt, BindingMode, Ty, TypeVisitableExt}; use rustc_session::lint::builtin::NON_EXHAUSTIVE_OMITTED_PATTERNS; use rustc_span::edit_distance::find_best_match_for_name;


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
This also ICEs on stable with the same error, so I don't think this is related to any of my recent changes at a glance. Having a look at it though
Regression in nightly-2021-09-01 commit[0] 2021-08-30: Auto merge of - sexxi-goose:issue-, r=nikomatsakis commit[1] 2021-08-30: Auto merge of - lcnr:cec-rename, r=oli-obk commit[2] 2021-08-31: Auto merge of - HTG-YT:edition2021-compopt-stabilization, r=m-ou-se commit[3] 2021-08-31: Auto merge of - Aaron1011:guess-foreign-head-span, r=estebank commit[4] 2021-08-31: Auto merge of - sexxi-goose:issue-, r=nikomatsakis commit[5] 2021-08-31: Auto merge of - RalfJung:miri, r=RalfJung commit[6] 2021-08-31: Auto merge of - m-ou-se:rollup-az6xtc5, r=m-ou-se commit[7] 2021-08-31: Auto merge of - m-ou-se:rollup-jeusxbo, r=m-ou-se commit[8] 2021-08-31: Auto merge of - Mark-Simulacrum:fix-rlibs, r=ehuss
I suspect that might be a false positive bisect?
ah meh, probably, if the feature gate was renamed or something, the code with the "new" feature gate might no longer trigger the ice once needed the old feature gate -_-
Bisected to nightly-2022-11-27, probably caused by . <details<summary<codecargo-bisect-rustc</codeoutput </summary</details

len: ty::Const<'tcx>, min_len: u64, ) -> (Option<Ty<'tcx>>, Ty<'tcx>) { <del> let guar = if let Some(len) = len.try_eval_target_usize(self.tcx, self.param_env) { </del> <ins> let len = match len.eval(self.tcx, self.param_env, None) { Ok(val) => val .try_to_scalar() .and_then(|scalar| scalar.try_to_int().ok()) .and_then(|int| int.try_to_target_usize(self.tcx).ok()), Err(ErrorHandled::Reported(..)) => { let guar = self.error_scrutinee_unfixed_length(span); return (Some(Ty::new_error(self.tcx, guar)), arr_ty); } Err(ErrorHandled::TooGeneric(..)) => None, }; let guar = if let Some(len) = len { </ins> // Now we know the length... if slice.is_none() { // ...and since there is no variable-length pattern,


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
This also ICEs on stable with the same error, so I don't think this is related to any of my recent changes at a glance. Having a look at it though
Regression in nightly-2021-09-01 commit[0] 2021-08-30: Auto merge of - sexxi-goose:issue-, r=nikomatsakis commit[1] 2021-08-30: Auto merge of - lcnr:cec-rename, r=oli-obk commit[2] 2021-08-31: Auto merge of - HTG-YT:edition2021-compopt-stabilization, r=m-ou-se commit[3] 2021-08-31: Auto merge of - Aaron1011:guess-foreign-head-span, r=estebank commit[4] 2021-08-31: Auto merge of - sexxi-goose:issue-, r=nikomatsakis commit[5] 2021-08-31: Auto merge of - RalfJung:miri, r=RalfJung commit[6] 2021-08-31: Auto merge of - m-ou-se:rollup-az6xtc5, r=m-ou-se commit[7] 2021-08-31: Auto merge of - m-ou-se:rollup-jeusxbo, r=m-ou-se commit[8] 2021-08-31: Auto merge of - Mark-Simulacrum:fix-rlibs, r=ehuss
I suspect that might be a false positive bisect?
ah meh, probably, if the feature gate was renamed or something, the code with the "new" feature gate might no longer trigger the ice once needed the old feature gate -_-
Bisected to nightly-2022-11-27, probably caused by . <details<summary<codecargo-bisect-rustc</codeoutput </summary</details

<ins> #![allow(incomplete_features)] #![feature(generic_const_exprs)] fn something(path: [usize; N]) -> impl Clone { //~^ ERROR cannot find value `N` in this scope match path { [] => 0, //~ ERROR cannot pattern-match on an array without a fixed length _ => 1, }; } fn main() {} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
This also ICEs on stable with the same error, so I don't think this is related to any of my recent changes at a glance. Having a look at it though
Regression in nightly-2021-09-01 commit[0] 2021-08-30: Auto merge of - sexxi-goose:issue-, r=nikomatsakis commit[1] 2021-08-30: Auto merge of - lcnr:cec-rename, r=oli-obk commit[2] 2021-08-31: Auto merge of - HTG-YT:edition2021-compopt-stabilization, r=m-ou-se commit[3] 2021-08-31: Auto merge of - Aaron1011:guess-foreign-head-span, r=estebank commit[4] 2021-08-31: Auto merge of - sexxi-goose:issue-, r=nikomatsakis commit[5] 2021-08-31: Auto merge of - RalfJung:miri, r=RalfJung commit[6] 2021-08-31: Auto merge of - m-ou-se:rollup-az6xtc5, r=m-ou-se commit[7] 2021-08-31: Auto merge of - m-ou-se:rollup-jeusxbo, r=m-ou-se commit[8] 2021-08-31: Auto merge of - Mark-Simulacrum:fix-rlibs, r=ehuss
I suspect that might be a false positive bisect?
ah meh, probably, if the feature gate was renamed or something, the code with the "new" feature gate might no longer trigger the ice once needed the old feature gate -_-
Bisected to nightly-2022-11-27, probably caused by . <details<summary<codecargo-bisect-rustc</codeoutput </summary</details

<ins> error[E0425]: cannot find value `N` in this scope --> $DIR/issue-116186.rs:4:28 | LL | fn something(path: [usize; N]) -> impl Clone { |                            ^ not found in this scope | help: you might be missing a const parameter | LL | fn something<const N: /* Type */>(path: [usize; N]) -> impl Clone { |             +++++++++++++++++++++ error[E0730]: cannot pattern-match on an array without a fixed length --> $DIR/issue-116186.rs:7:9 | LL |         [] => 0, |         ^^ error: aborting due to 2 previous errors Some errors have detailed explanations: E0425, E0730. For more information about an error, try `rustc --explain E0425`. </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can be reduced to
Also causes the out of bounds panic (), but not the earlier type mismatch ICE
Triage: Fixed on the latest nightly, marked as E-needs-test labels: +E-needs-test

<ins> // test for #113326 #![feature(type_alias_impl_trait)] pub type Diff = impl Fn(usize) -> usize; pub fn lift() -> Diff { |_: usize |loop {} } pub fn add( n: Diff, m: Diff, ) -> Diff { move |x: usize| m(n(x)) //~ ERROR: concrete type differs } fn main() {} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can be reduced to
Also causes the out of bounds panic (), but not the earlier type mismatch ICE
Triage: Fixed on the latest nightly, marked as E-needs-test labels: +E-needs-test

<ins> error: concrete type differs from previous defining opaque type use --> $DIR/recursive-fn-tait.rs:14:5 | LL |     move |x: usize| m(n(x)) |     ^^^^^^^^^^^^^^^^^^^^^^^ expected `{closure@$DIR/recursive-fn-tait.rs:7:5: 7:16}`, got `{closure@$DIR/recursive-fn-tait.rs:14:5: 14:20}` | note: previous use here --> $DIR/recursive-fn-tait.rs:7:5 | LL |     |_: usize |loop {} |     ^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>


Question:
I tried this code: and I expected to see this happen: All tests passing. No doc tests running when using Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The tests pass for me and they're passing in CI. So I suspect there is something about your system that differs from mine and CI. Can you post the contents of your ?
Also, could you share how these tests are failing? Failing tests usually explain why their stderr differs from expected, or otherwise explain why the test happened to fail.
Hi there, I just did a fresh clone and got the same failures (target x86_64-unknown-linux-gnu). The file has not been changed. The test pass when I used my Mac device. The test each have "The actual stderr differed from the expected stderr." The actual stderr seems to have extra lines " full type name has been written to.." which are not in the expected stderr. Could that be the cause of the failure? If so, what can a fix look like? Full output on terminal:
is your copy of rust cloned into some really deep directory path? like... ? the problem is that your tests are failing because your build is producing type names that hit the length limit and are spilled to disk, and that file limit is dependent (unfortunately) on the path that the rust clone is located at...
we should probably fix this so that UI tests don't spill any long type names to disk by default. We could do this by adding a compiler flag that disables this behavior, and enable that flag by default in the ui testing suite.
this is a great idea — if we do this, we should also remove the code that enables remap-path-prefix in CI.
I can reproduce this locally by cloning under a long path. I would like to work on this. I'll take a look to see if I can identify where we have the logic for spilling the type names to disk, and guard it with a flag. I'll ask questions if I have trouble with that. claim
alternatively, we could gate it under the existing flag
I have code that works for this, but there are some tests under that seem to actually test specifically this behaviour of spilling to disk. So I'm thinking, under we skip spilling to disk, unless there is another flag, enabled, in which case we spill long type names to disk so that logic can be tested as well. Thoughts?
Two examples I found where we are testing the long type name spilling behaviour: with
:+1: this seems good. i would bikeshed the name as and uncouple it from (i.e. compiletest would start passing instead of you changing the behavior of ), but i like the idea :)
I have a pull-request for this, but I'm getting an error in the CI pipeline that I haven't dug too deep into, was wondering if there is a simple explanation for this? Thanks
The pull-request is going through well, but I'm now wondering about this part: Do you mean to basically revert this pull-request:
Pull-request to remove remap-path-prefix code for CI builds:

use std::path::{Path, PathBuf}; use std::process::Command; <del> use build_helper::ci::CiEnv; </del> use tracing::*; use crate::common::{Config, Debugger, FailMode, Mode, PassMode};


Question:
I tried this code: and I expected to see this happen: All tests passing. No doc tests running when using Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The tests pass for me and they're passing in CI. So I suspect there is something about your system that differs from mine and CI. Can you post the contents of your ?
Also, could you share how these tests are failing? Failing tests usually explain why their stderr differs from expected, or otherwise explain why the test happened to fail.
Hi there, I just did a fresh clone and got the same failures (target x86_64-unknown-linux-gnu). The file has not been changed. The test pass when I used my Mac device. The test each have "The actual stderr differed from the expected stderr." The actual stderr seems to have extra lines " full type name has been written to.." which are not in the expected stderr. Could that be the cause of the failure? If so, what can a fix look like? Full output on terminal:
is your copy of rust cloned into some really deep directory path? like... ? the problem is that your tests are failing because your build is producing type names that hit the length limit and are spilled to disk, and that file limit is dependent (unfortunately) on the path that the rust clone is located at...
we should probably fix this so that UI tests don't spill any long type names to disk by default. We could do this by adding a compiler flag that disables this behavior, and enable that flag by default in the ui testing suite.
this is a great idea — if we do this, we should also remove the code that enables remap-path-prefix in CI.
I can reproduce this locally by cloning under a long path. I would like to work on this. I'll take a look to see if I can identify where we have the logic for spilling the type names to disk, and guard it with a flag. I'll ask questions if I have trouble with that. claim
alternatively, we could gate it under the existing flag
I have code that works for this, but there are some tests under that seem to actually test specifically this behaviour of spilling to disk. So I'm thinking, under we skip spilling to disk, unless there is another flag, enabled, in which case we spill long type names to disk so that logic can be tested as well. Thoughts?
Two examples I found where we are testing the long type name spilling behaviour: with
:+1: this seems good. i would bikeshed the name as and uncouple it from (i.e. compiletest would start passing instead of you changing the behavior of ), but i like the idea :)
I have a pull-request for this, but I'm getting an error in the CI pipeline that I haven't dug too deep into, was wondering if there is a simple explanation for this? Thanks
The pull-request is going through well, but I'm now wondering about this part: Do you mean to basically revert this pull-request:
Pull-request to remove remap-path-prefix code for CI builds:

/// `//[foo]`), then the property is ignored unless `cfg` is /// `Some("foo")`. fn load_from(&mut self, testfile: &Path, cfg: Option<&str>, config: &Config) { <del> // In CI, we've sometimes encountered non-determinism related to truncating very long paths. // Set a consistent (short) prefix to avoid issues, but only in CI to avoid regressing the // contributor experience. if CiEnv::is_ci() { self.remap_src_base = config.mode == Mode::Ui && !config.suite.contains("rustdoc"); } </del> let mut has_edition = false; if !testfile.is_dir() { let file = File::open(testfile).unwrap();


Question:
When using the flag, I stumbled upon a warning that I don't understand and assume to be a bug/missed implementation. If this is the intended behavior, could anyone please explain why? This is simplified code that generates the warning: But when adding a type restriction on self (in this case Sized)_ the warning does not appear anymore. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
This is in fact a bug.
Update: This issue is still present, and has now sneaked into stable with the release of ; as such I'm updating the title to reflect that.
This is similar to the bug report
This isn't the same bug. This just has to do with a false warning of the lint.
on this, also encountering this bug
Also encountering with

use rustc_middle::ty::{ self, fold::BottomUpFolder, print::TraitPredPrintModifiersAndPath, Ty, TypeFoldable, }; <del> use rustc_span::Span; </del> <ins> use rustc_span::{symbol::kw, Span}; </ins> use rustc_trait_selection::traits; use rustc_trait_selection::traits::query::evaluate_obligation::InferCtxtExt;


Question:
When using the flag, I stumbled upon a warning that I don't understand and assume to be a bug/missed implementation. If this is the intended behavior, could anyone please explain why? This is simplified code that generates the warning: But when adding a type restriction on self (in this case Sized)_ the warning does not appear anymore. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
This is in fact a bug.
Update: This issue is still present, and has now sneaked into stable with the release of ; as such I'm updating the title to reflect that.
This is similar to the bug report
This isn't the same bug. This just has to do with a false warning of the lint.
on this, also encountering this bug
Also encountering with

continue; } <ins> // HACK: `async fn() -> Self` in traits is "ok"... // This is not really that great, but it's similar to why the `-> Self` // return type is well-formed in traits even when `Self` isn't sized. if let ty::Param(param_ty) = *proj_term.kind() && param_ty.name == kw::SelfUpper && matches!(opaque.origin, hir::OpaqueTyOrigin::AsyncFn(_)) && opaque.in_trait { continue; } </ins> let proj_ty = Ty::new_projection(cx.tcx, proj.projection_ty.def_id, proj.projection_ty.args); // For every instance of the projection type in the bounds,


Question:
When using the flag, I stumbled upon a warning that I don't understand and assume to be a bug/missed implementation. If this is the intended behavior, could anyone please explain why? This is simplified code that generates the warning: But when adding a type restriction on self (in this case Sized)_ the warning does not appear anymore. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
This is in fact a bug.
Update: This issue is still present, and has now sneaked into stable with the release of ; as such I'm updating the title to reflect that.
This is similar to the bug report
This isn't the same bug. This just has to do with a false warning of the lint.
on this, also encountering this bug
Also encountering with

<ins> // check-pass // edition:2021 #![deny(opaque_hidden_inferred_bound)] trait Repository /* : ?Sized */ { async fn new() -> Self; } struct MyRepository {} impl Repository for MyRepository { async fn new() -> Self { todo!() } } fn main() {} </ins>


Question:
This is a regression from
in general the fix for this is usually to add before the line so that they don't overlap
we might want to consider changing to bypass the type-based cache so it catches ordering bugs like this cc
I don't understand how dry run is relevant here, isn't this a problem in all cases? Dry run and real should have roughly the same ensure graph to the extent possible and our tests rely on that... It also seems like based on the linked PR here this assertion is always guaranteed to show up at runtime pretty much constantly anytime someone accidentally adds additional nesting with a group? I could see that the right fix is to track the group and end + restart it so that there's no nesting and instead a linear non-nested list of groups...
dry-run and real have the same problems, yes. my idea was to do extra checks in dry-run so that without arguments would have caught this - the reason it only gets triggered with the filter is because normally, an earlier Step will happen to call , so the dynamic GHA check never gets run. correct. i was hoping that the check was eager enough they'd notice immediately and fix it in order to make CI pass, but this issue shows that it's non-trivial to do so because of the way it depends on the cache. this is how dry-run gets involved - when it's enabled, bypassing the cache is cheap and we can just do it unconditionally, which would have caught this bug before it got merged. hmm, that might handle our current cases ok, but it's not correct in general - consider something like that will split up the single message before and after, which doesn't seem quite right, although i suppose it might be better than panicking?
Ah, I see. I'm not convinced that we'd not stop catching other problems and/or introduce them by changing dry run. The split example you suggest feels right to me - in some sense more right - it means we are putting things in finest granularity groups. It also matches what we do for metrics emission, I believe... I will say that I don't really understand the value in the grouping, so perhaps that would change my thinking there.... At minimum, we might consider not panicking outside of GHA workloads, since the grouping doesn't matter then?

let mut tool = tool::ErrorIndex::command(builder); tool.arg("markdown").arg(&output); <del> let _guard = </del> <ins> let guard = </ins> builder.msg(Kind::Test, compiler.stage, "error-index", compiler.host, compiler.host); let _time = util::timeit(&builder); builder.run_quiet(&mut tool); <ins> drop(guard); </ins> // The tests themselves need to link to std, so make sure it is // available. builder.ensure(compile::Std::new(compiler, compiler.host));


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Not posting the entire 1.7K lines backtrace :upsidedownface: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
You can also reproduce this in the rustc repo itself where will encounter the error with
Reduced: label F-typealiasimpl_trait
Found another repro I think: this one bisects to
`
prioritize
going to also link and as other reports of the same issue
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Ok, after a bit more back ond forth , I'm tentatively bumping this issue to P-critical and raise these questions (echoing the comments from the discussion): would it make sense to revert ? cc or would it make sense to revert (which IIUC leaked in the std library an unstable nightly only feature) ? cc Next week Rust 1.72 will be released, artifacts are going to be build real soon, I think. Thanks for additional comments to help improve my understanding of the context here. label -P-medium +P-critical
The underlying issue here is an issue with TAIT. was an implementation-only change simplifying some backtrace code in that was made under the assumption that TAIT was reliable enough to be used inside . As it is not user-facing it should be easily revertible. So the question here is whether it is safer to get TAIT working (potentially by reverting ?) so it can be used internally or to just hold off on using it until the issue has been resolved, reapplying once that happens. I have no compiler experience, but my initial hunch would be that the library change is preferable for now. I'll get a PR ready until tomorrow, unless someone beats me to it.
should not be reverted. All it does is cause us to now eagerly reveal opaques that were being skipped over during normalization, which means that we're just not hitting this code anymore: It does not introduce a bug, it just reveals one that already existed. I'm gonna use the minimized example () here. What's happening here is that we're generating a drop shim for that looks like: which then tries to validate that . However, it has type , where is a , which does not hit the code I linked above. Before , we'd emit something that looks like: which is a field that is incompletely normalized, but does* hit the code above.
Submitted the PR reverting : .
fixes this issue by not considering mir validity on shims until they have been optimized, which uses the reveal-all param-env for that shim. This ICE shouldn't be possible to trigger without , since it has to do with one of the intra-pass mir validations that are only done when that flag is active: I don't personally think that needs to be reverted, either.
This was also possible to trigger even before using an associated type. The test in exercises this too.

}; debug!("make_shim({:?}) = untransformed {:?}", instance, result); <del> pm::run_passes( </del> <ins> // We don't validate MIR here because the shims may generate code that's // only valid in a reveal-all param-env. However, since we do initial // validation with the MirBuilt phase, which uses a user-facing param-env. // This causes validation errors when TAITs are involved. pm::run_passes_no_validate( </ins> tcx, &mut result, &[


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Not posting the entire 1.7K lines backtrace :upsidedownface: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
You can also reproduce this in the rustc repo itself where will encounter the error with
Reduced: label F-typealiasimpl_trait
Found another repro I think: this one bisects to
`
prioritize
going to also link and as other reports of the same issue
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Ok, after a bit more back ond forth , I'm tentatively bumping this issue to P-critical and raise these questions (echoing the comments from the discussion): would it make sense to revert ? cc or would it make sense to revert (which IIUC leaked in the std library an unstable nightly only feature) ? cc Next week Rust 1.72 will be released, artifacts are going to be build real soon, I think. Thanks for additional comments to help improve my understanding of the context here. label -P-medium +P-critical
The underlying issue here is an issue with TAIT. was an implementation-only change simplifying some backtrace code in that was made under the assumption that TAIT was reliable enough to be used inside . As it is not user-facing it should be easily revertible. So the question here is whether it is safer to get TAIT working (potentially by reverting ?) so it can be used internally or to just hold off on using it until the issue has been resolved, reapplying once that happens. I have no compiler experience, but my initial hunch would be that the library change is preferable for now. I'll get a PR ready until tomorrow, unless someone beats me to it.
should not be reverted. All it does is cause us to now eagerly reveal opaques that were being skipped over during normalization, which means that we're just not hitting this code anymore: It does not introduce a bug, it just reveals one that already existed. I'm gonna use the minimized example () here. What's happening here is that we're generating a drop shim for that looks like: which then tries to validate that . However, it has type , where is a , which does not hit the code I linked above. Before , we'd emit something that looks like: which is a field that is incompletely normalized, but does* hit the code above.
Submitted the PR reverting : .
fixes this issue by not considering mir validity on shims until they have been optimized, which uses the reveal-all param-env for that shim. This ICE shouldn't be possible to trigger without , since it has to do with one of the intra-pass mir validations that are only done when that flag is active: I don't personally think that needs to be reverted, either.
This was also possible to trigger even before using an associated type. The test in exercises this too.

<ins> // crate foo #![feature(type_alias_impl_trait)] type Tait = impl Sized; fn _constrain() -> Tait {} struct WrapperWithDrop<T>(T); impl<T> Drop for WrapperWithDrop<T> { fn drop(&mut self) {} } pub struct Foo(WrapperWithDrop<Tait>); trait Id { type Id: ?Sized; } impl<T: ?Sized> Id for T { type Id = T; } pub struct Bar(WrapperWithDrop<<Tait as Id>::Id>); </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Not posting the entire 1.7K lines backtrace :upsidedownface: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
You can also reproduce this in the rustc repo itself where will encounter the error with
Reduced: label F-typealiasimpl_trait
Found another repro I think: this one bisects to
`
prioritize
going to also link and as other reports of the same issue
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Ok, after a bit more back ond forth , I'm tentatively bumping this issue to P-critical and raise these questions (echoing the comments from the discussion): would it make sense to revert ? cc or would it make sense to revert (which IIUC leaked in the std library an unstable nightly only feature) ? cc Next week Rust 1.72 will be released, artifacts are going to be build real soon, I think. Thanks for additional comments to help improve my understanding of the context here. label -P-medium +P-critical
The underlying issue here is an issue with TAIT. was an implementation-only change simplifying some backtrace code in that was made under the assumption that TAIT was reliable enough to be used inside . As it is not user-facing it should be easily revertible. So the question here is whether it is safer to get TAIT working (potentially by reverting ?) so it can be used internally or to just hold off on using it until the issue has been resolved, reapplying once that happens. I have no compiler experience, but my initial hunch would be that the library change is preferable for now. I'll get a PR ready until tomorrow, unless someone beats me to it.
should not be reverted. All it does is cause us to now eagerly reveal opaques that were being skipped over during normalization, which means that we're just not hitting this code anymore: It does not introduce a bug, it just reveals one that already existed. I'm gonna use the minimized example () here. What's happening here is that we're generating a drop shim for that looks like: which then tries to validate that . However, it has type , where is a , which does not hit the code I linked above. Before , we'd emit something that looks like: which is a field that is incompletely normalized, but does* hit the code above.
Submitted the PR reverting : .
fixes this issue by not considering mir validity on shims until they have been optimized, which uses the reveal-all param-env for that shim. This ICE shouldn't be possible to trigger without , since it has to do with one of the intra-pass mir validations that are only done when that flag is active: I don't personally think that needs to be reverted, either.
This was also possible to trigger even before using an associated type. The test in exercises this too.

<ins> // aux-build:drop-shim-relates-opaque-aux.rs // compile-flags: -Zvalidate-mir --crate-type=lib // build-pass extern crate drop_shim_relates_opaque_aux; pub fn drop_foo(_: drop_shim_relates_opaque_aux::Foo) {} pub fn drop_bar(_: drop_shim_relates_opaque_aux::Bar) {} fn main() {} </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This is not an RPITIT bug, for the record.

use super::ResolverAstLoweringExt; use rustc_ast::visit::{self, BoundKind, LifetimeCtxt, Visitor}; use rustc_ast::{GenericBounds, Lifetime, NodeId, PathSegment, PolyTraitRef, Ty, TyKind}; <del> use rustc_hir::def::LifetimeRes; </del> <ins> use rustc_hir::def::{DefKind, LifetimeRes, Res}; </ins> use rustc_middle::span_bug; use rustc_middle::ty::ResolverAstLowering; use rustc_span::symbol::{kw, Ident};


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This is not an RPITIT bug, for the record.

} fn visit_ty(&mut self, t: &'ast Ty) { <del> match t.kind { </del> <ins> match &t.kind { TyKind::Path(None, _) => { // We can sometimes encounter bare trait objects // which are represented in AST as paths. if let Some(partial_res) = self.resolver.get_partial_res(t.id) && let Some(Res::Def(DefKind::Trait | DefKind::TraitAlias, _)) = partial_res.full_res() { self.current_binders.push(t.id); visit::walk_ty(self, t); self.current_binders.pop(); } else { visit::walk_ty(self, t); } } </ins> TyKind::BareFn(_) => { self.current_binders.push(t.id); visit::walk_ty(self, t);