jiebi/CodeConvo huggingface dataset:
Code change:
iterates over (which point to a slice of bytes in memory). When the code points expire (no more bytes available in the slice), there is no chance of the iterator ever returning more values. Therefore, should implement . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It is currently fused in practice and I don't think there's a good reason to change that in the future. This would technically be an API change but one that should have no negative impact to existing code. Which is the long winded way of saying I agree.
Thanks for the quick response! I realize that this is an API change but didn't feel it'd warrant a "feature suggestion". I guess for now I'm just throwing the idea out there.
This is a great idea and I'd be happy to see a PR that implements it. I was just ticking off a checklist. It's not a breaking change and it is useful, so implementing it should not be at all controversial.
Sounds good, I'll get to it tomorrow! claim
Note that, procedurally, a new trait impl is insta-stable so will need a FCP. (That's totally ok, just wanted to note it. You can and should send a PR for it.)

Related discussion:
text: } } <ins> #[stable(feature = "encode_wide_fused_iterator", since = "1.62.0")] impl FusedIterator for EncodeWide<'_> {} </ins> impl Hash for CodePoint { #[inline] fn hash<H: Hasher>(&self, state: &mut H) {
Code change:
I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.

Related discussion:
text: | PathSource::Struct | PathSource::TupleStruct(..) => false, }; <del> let mut error = false; </del> <ins> let mut res = LifetimeRes::Error; </ins> for rib in self.lifetime_ribs.iter().rev() { match rib.kind { // In create-parameter mode we error here because we don't want to support
Code change:
I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.

Related discussion:
text: //     impl Foo for std::cell::Ref<u32> // note lack of '_ //     async fn foo(_: std::cell::Ref<u32>) { ... } LifetimeRibKind::AnonymousCreateParameter(_) => { <del> error = true; </del> break; } // `PassThrough` is the normal case.
Code change:
I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.

Related discussion:
text: // `PathSegment`, for which there is no associated `'_` or `&T` with no explicit // lifetime. Instead, we simply create an implicit lifetime, which will be checked // later, at which point a suitable error will be emitted. <del> LifetimeRibKind::AnonymousPassThrough(..) | LifetimeRibKind::AnonymousReportError | LifetimeRibKind::Item => break, </del> <ins> LifetimeRibKind::AnonymousPassThrough(binder) => { res = LifetimeRes::Anonymous { binder, elided: true }; break; } LifetimeRibKind::AnonymousReportError | LifetimeRibKind::Item => { // FIXME(cjgillot) This resolution is wrong, but this does not matter // since these cases are erroneous anyway.  Lifetime resolution should // emit a "missing lifetime specifier" diagnostic. res = LifetimeRes::Anonymous { binder: DUMMY_NODE_ID, elided: true }; break; } </ins> _ => {} } } <del> let res = if error { LifetimeRes::Error } else { LifetimeRes::Anonymous { binder: segment_id, elided: true } }; </del> let node_ids = self.r.next_node_ids(expected_lifetimes); self.record_lifetime_res( segment_id,
Code change:
I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.

Related discussion:
text: // originating from macros, since the segment's span might be from a macro arg. segment.ident.span.find_ancestor_inside(path_span).unwrap_or(path_span) }; <del> if error { </del> <ins> if let LifetimeRes::Error = res { </ins> let sess = self.r.session; let mut err = rustc_errors::struct_span_err!( sess,
Code change:
I tried this code: I expected to see this happen: it compile Instead, this happened: it didnt It most recently worked on Rust 1.60 and this nighty: : searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29 regressed nightly: nightly-2022-04-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Slightly simplified reproduction: In other words, this isn't specific to .
Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested , but that appears not to have been correct.

Related discussion:
text: <ins> // check-pass struct Foo<'a>(&'a ()); fn with_fn() -> fn(Foo) { |_| () } fn with_impl_fn() -> impl Fn(Foo) { |_| () } fn with_where_fn<T>() where T: Fn(Foo), { } fn main() {} </ins>
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Et Voila! ! Here's the final result, pushing a PR soon
Should be fixed by

Related discussion:
text: ); err.span_label(self.span, "invalid cast"); if self.expr_ty.is_numeric() { <del> err.span_help( self.span, if self.expr_ty == fcx.tcx.types.i8 { "try casting from `u8` instead" } else if self.expr_ty == fcx.tcx.types.u32 { "try `char::from_u32` instead" } else { "try `char::from_u32` instead (via a `u32`)" }, ); </del> <ins> if self.expr_ty == fcx.tcx.types.u32 { match fcx.tcx.sess.source_map().span_to_snippet(self.expr.span) { Ok(snippet) => err.span_suggestion( self.span, "try `char::from_u32` instead", format!("char::from_u32({snippet})"), Applicability::MachineApplicable, ), Err(_) => err.span_help(self.span, "try `char::from_u32` instead"), }; } else if self.expr_ty == fcx.tcx.types.i8 { err.span_help(self.span, "try casting from `u8` instead"); } else { err.span_help(self.span, "try `char::from_u32` instead (via a `u32`)"); }; </ins> } err.emit(); }
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Et Voila! ! Here's the final result, pushing a PR soon
Should be fixed by

Related discussion:
text: --> $DIR/E0604.rs:2:5 | LL |     1u32 as char; <del> |     ^^^^^^^^^^^^ invalid cast | help: try `char::from_u32` instead --> $DIR/E0604.rs:2:5 | LL |     1u32 as char; </del> |     ^^^^^^^^^^^^ <ins> |     | |     invalid cast |     help: try `char::from_u32` instead: `char::from_u32(1u32)` </ins> error: aborting due to previous error
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Et Voila! ! Here's the final result, pushing a PR soon
Should be fixed by

Related discussion:
text: --> $DIR/error-festival.rs:25:5 | LL |     0u32 as char; <del> |     ^^^^^^^^^^^^ invalid cast | help: try `char::from_u32` instead --> $DIR/error-festival.rs:25:5 | LL |     0u32 as char; </del> |     ^^^^^^^^^^^^ <ins> |     | |     invalid cast |     help: try `char::from_u32` instead: `char::from_u32(0u32)` </ins> error[E0605]: non-primitive cast: `u8` as `Vec<u8>` --> $DIR/error-festival.rs:29:5
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Et Voila! ! Here's the final result, pushing a PR soon
Should be fixed by

Related discussion:
text: --> $DIR/cast-rfc0401.rs:41:13 | LL |     let _ = 0x61u32 as char; <del> |             ^^^^^^^^^^^^^^^ invalid cast | help: try `char::from_u32` instead --> $DIR/cast-rfc0401.rs:41:13 | LL |     let _ = 0x61u32 as char; </del> |             ^^^^^^^^^^^^^^^ <ins> |             | |             invalid cast |             help: try `char::from_u32` instead: `char::from_u32(0x61u32)` </ins> error[E0606]: casting `bool` as `f32` is invalid --> $DIR/cast-rfc0401.rs:43:13
Code change:
: <!-- 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 --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Related discussion:
text: let second_input_ty = self.resolve_vars_if_possible(expected_input_tys[second_idx]); let third_input_ty = <del> self.resolve_vars_if_possible(expected_input_tys[second_idx]); </del> <ins> self.resolve_vars_if_possible(expected_input_tys[third_idx]); </ins> let span = if third_idx < provided_arg_count { let first_arg_span = provided_args[first_idx].span; let third_arg_span = provided_args[third_idx].span;
Code change:
: <!-- 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 --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Related discussion:
text: } missing_idxs => { let first_idx = *missing_idxs.first().unwrap(); <del> let second_idx = *missing_idxs.last().unwrap(); </del> <ins> let last_idx = *missing_idxs.last().unwrap(); </ins> // NOTE: Because we might be re-arranging arguments, might have extra arguments, etc. // It's hard to *really* know where we should provide this error label, so this is a // decent heuristic <del> let span = if first_idx < provided_arg_count { </del> <ins> let span = if last_idx < provided_arg_count { </ins> let first_arg_span = provided_args[first_idx].span; <del> let second_arg_span = provided_args[second_idx].span; </del> <ins> let last_arg_span = provided_args[last_idx].span; </ins> Span::new( first_arg_span.lo(), <del> second_arg_span.hi(), </del> <ins> last_arg_span.hi(), </ins> first_arg_span.ctxt(), None, )
Code change:
: <!-- 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 --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Related discussion:
text: <ins> fn main() { g((), ()); //~^ ERROR this function takes 6 arguments but 2 arguments were supplied } pub fn g(a1: (), a2: bool, a3: bool, a4: bool, a5: bool, a6: ()) -> () {} </ins>
Code change:
: <!-- 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 --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Related discussion:
text: <ins> error[E0061]: this function takes 6 arguments but 2 arguments were supplied --> $DIR/issue-97197.rs:2:5 | LL |     g((), ()); |     ^-------- multiple arguments are missing | note: function defined here --> $DIR/issue-97197.rs:6:8 | LL | pub fn g(a1: (), a2: bool, a3: bool, a4: bool, a5: bool, a6: ()) -> () {} |        ^ ------  --------  --------  --------  --------  ------ help: provide the arguments | LL |     g((), {bool}, {bool}, {bool}, {bool}, ()); |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: aborting due to previous error For more information about this error, try `rustc --explain E0061`. </ins>
Code change:
: <!-- 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 --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Related discussion:
text: --> $DIR/missing_arguments.rs:39:3 | LL |   complex(   1,                     ""   ); <del> |   ^^^^^^^--------------------------------- three arguments of type `f32`, `i32`, and `i32` are missing </del> <ins> |   ^^^^^^^--------------------------------- three arguments of type `f32`, `i32`, and `f32` are missing </ins> | note: function defined here --> $DIR/missing_arguments.rs:7:4
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: runs infinitely Instead, this happened: return directly The is set to :
According to and , rustc doesn't emit , which means the loop generated by the tail call shouldn't be removed(I guess).
This was apparently working in 1.58 and regressed in 1.59. label regression-from-stable-to-stable
Small reproducer:
From a cursory look, probably due to:
From cargo bisect: Probably related to
I'm tagging this as , as discussed in the . The following reproduction is concerning: This exits with an , which is not good. Presumably, is returning even though it returns . One of many ways in which this can likely be unsound.
Upstream fix: Upstream backport issue:
Reopening to beta-nominate. This regression is a nasty miscompilation that can silently induce unsoundness in valid code, given a certain opt-level setting, and is not platform-specific. The patch to LLVM to fix this is quite small:
As per T-compiler meeting (), lowering priority of this issue since has been there for a long time and the "illegal hardware instruction" mentioned is the we generate intentionally here. label +P-high -P-critical
Closing this as the beta backport has happened.

Related discussion:
text: <del> Subproject commit 47848665966fc7393cb6f898077994f6dec2b591 </del> <ins> Subproject commit c9e2e89ed3aa5a3be77143aa0c86906b4138374a </ins>
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

Related discussion:
text: "libc", "once_cell", "opener", <del> "pretty_assertions", </del> <ins> "pretty_assertions 0.7.2", </ins> "serde", "serde_json", "tar",
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

Related discussion:
text: ] [[package]] <ins> name = "crossbeam" version = "0.8.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "4ae5588f6b3c3cb05239e90bd110f257254aecd01e4635400391aeae07497845" dependencies = [ "cfg-if 1.0.0", "crossbeam-channel", "crossbeam-deque", "crossbeam-epoch", "crossbeam-queue", "crossbeam-utils", ] [[package]] </ins> name = "crossbeam-channel" version = "0.5.4" source = "registry+https://github.com/rust-lang/crates.io-index"
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

Related discussion:
text: ] [[package]] <ins> name = "crossbeam-queue" version = "0.3.5" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "1f25d8400f4a7a5778f0e4e52384a48cbd9b5c495d110786187fc750075277a2" dependencies = [ "cfg-if 1.0.0", "crossbeam-utils", ] [[package]] </ins> name = "crossbeam-utils" version = "0.8.8" source = "registry+https://github.com/rust-lang/crates.io-index"
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Tons of test suite failures when testing with mir-opt; probably because the dead stores that cause UB got removed.
claim
I'd like to land before we update the in-tree Miri.

Related discussion:
text: version = "0.1.0" dependencies = [ "colored", <del> "compiletest_rs", </del> "env_logger 0.9.0", "getrandom 0.2.0", <ins> "lazy_static", </ins> "libc", "log", "measureme 9.1.2", "rand 0.8.5", <ins> "regex", </ins> "rustc-workspace-hack", <del> "rustc_version", </del> "shell-escape", "smallvec", <ins> "ui_test", </ins> ] [[package]]