jiebi/CodeConvo huggingface dataset:
Code change:
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

Related discussion:
text: 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> } } }
Code change:
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

Related discussion:
text: <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>
Code change:
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

Related discussion:
text: 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
Code change:
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

Related discussion:
text: 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
Code change:
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.

Related discussion:
text: 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);
Code change:
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.

Related discussion:
text: DlSym(String), LocatorCombined(Box<CombinedLocatorError>), NonDylibPlugin(Symbol), <ins> NotFound(Symbol), </ins> } enum MetadataError<'a> {
Code change:
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.

Related discussion:
text: 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> } } }
Code change:
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.

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

Related discussion:
text: } 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); }
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
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

Related discussion:
text: 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 {
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
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

Related discussion:
text: } } <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() }
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
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

Related discussion:
text: 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)) }
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
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

Related discussion:
text: 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);
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
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

Related discussion:
text: // 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), };
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
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

Related discussion:
text: check_suspend_tys(tcx, &generator_layout, &body); <del> generator_layout </del> <ins> Some(generator_layout) </ins> } impl<'tcx> MirPass<'tcx> for StateTransform {
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
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

Related discussion:
text: && 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) {