Change:
<ins> // compile-flags: -Z mir-opt-level=2 // run-pass fn e220() -> (i64, i64) { #[inline(never)] fn get_displacement() -> [i64; 2] { [139776, 963904] } let res = get_displacement(); match (&res[0], &res[1]) { (arg0, arg1) => (*arg0, *arg1), } } fn main() { assert_eq!(e220(), (139776, 963904)); } </ins>

Discussion:
On the last Nightly:
Reduced to:
Mir of with : Mir of with : and got removed while is still assigned and used. Also the fields of now get and assigned.
The are a couple of things going on here: The immediate cause is the fact that we . This means that never gets evaluated, leaving uninitialized. Normally, this would not be a problem - const-prop explicitly when trying to access an uninitialized local, so failing to evaluate should just mean that we don't const-propagate anything that relies on . Unfortunately, it's possible for an uninitialized local to be incorrectly marked as initialized. Inside , we , even if it was previously uninitialied. When processing an , , which will incorrectly mark an uninitialized source as initialized. While implementing const-propagation for would fix this specific issue, the issue means that we risk introducing undefined behavior into valid programs whenever const-propagation doesn't evaluate something that would initialize a local. I see a few ways different of solving this: Change to . When is called on an uninitialized local, we keep the local as a , but would store in it. This would ensure that has no user-visible effect - uninitialized locals will remain uninitialized until actually written to. Make aware of whether not or not it is being used for 'reading' or 'writing'. When 'reading', we call before overwriting a local with , allowing the machine to assert that it is valid. When 'writing', we skip calling , allowing to be used when initializing a previously uninitialized local (which does not require that the target local be initialized). cc
Without having digested all the details yet, my first thought is: this is caused by const-prop trying to shoehorn the Miri engine (built for evaluation of whole programs) into an engine for partial evaluation. The was never meant for tracking things like "unkown value", it is a hack introduced for handling unsized locals as I didn't find a better way to implement them. It's meaning is "a local whose size we don't know yet". can determine the size, and thus complete allocation of the local. In terms of the Rust Abstract Machine (which the Miri engine models), I don't know what an "uninitialized local" is -- but a local that's marked but whose memory is entirely uninitialized should certainly qualify. Thus I would say that correctly preserves the uninitialized nature of the local.

The issue is that const-prop is taking the difference between and , which is an implementation detail of the engine (but doesn't correspond to anything real, it's basically just an optimization), and tries to assign meaning to it. No wonder this went wrong. What exactly is it that const-prop needs?
Cc
Zero cost uninitialized locals is the base feature we need. Essentially if we decide we don't need a local, reading its memory should yield an uninit value and its memory should not require any heap allocations. I get the shoehorning, we so are doing this a lot in const prop, mainly to keep the engine modifications minimal. I guess we could add some more machine hooks to get rid of hacks.
Even with , reading it will yield an uninit value. So not requiring heap allocations is a correctness condition? That's what analysis says, basically.
Well... it shouldn't be. The check is actually just a check ensuring we don't ICE for unsized values. This is not worded correctly. The uninitialized local is marked as live its memory is still uninitialized. But that doesn't change the fact that the analysis is spot on. We take references to locals that may never get a value propagated into. The early bail out in is just so we don't hit the panic in it's also not for correctness. Yea, so basically whenever we don't fully propagate into a local, but later take a reference to that local, we end up with a const pointer to an uninitialized const allocation. Basically unless the local's memory is valid (as per the validation rules for statics), we should not permit taking references to it.
Doesn't this also affect normal uses of an un-propagated local? We'll end up copying data from an uninitialized allocation, which will result in the same issue.
Yes, any local that we don't fully propagate into but that is referred to by a local that we marked as "could be propagated".
I'd say it's less about validity and more about whether we actually did all the computation for this local. That's not the same thing. Basically, const-prop needs a state representing "unknown". This is distinct from "(known to be) uninitialized". And that's not surprising at all, static analyses and optimizations almost always have such a state. This is a first step towards supporting abstract interpretation in Miri.

We inverted this by treating any initialized values as "!unknown". The issue here is that taking a reference to a value works even if the value is not fully initialized. We have no concept of fully initialized, and in case the local is of union type, we can't rely on the uninitialized state to signal "maybe unknown". So yea, the validity check won't work here either. and I talked about using dataflow for const prop, so we'd mark locals only as known when they have been successfully propagated into instead of relying on the initialization state. Until we do this we should probably just turn off propagating reference taking.
I agree disabling ref propagation makes sense. We have quite a few bugs that I believe would be resolved by that. In addition, I believe there's only 1 or 2 MIR tests that would be affected. Going forward, perhaps we should try to find some way to get more coverage of mir-opt=2?
The other problem is (as you hinted at) that things, at least in theory, might be "partially known", such as in where is, say, a pair: now the first field is known but the second is not.
A general worry about this is how our const-prop looks not at all like the usual "compiler construction literature const-prop": the usual thing is to do a fixed-point (static) analysis on a domain including all possible values as well as "unknown". That could also handle loops, which I suppose you currently have to carefully avoid. It is certainly possible to implement constant propagation differently, but that means none of the standard intuition about it applies.

file:  rustc @
cc
Heh, the first victim of const prop acting as if it were creating constants. Previous discussion on zulip: https://rust-

Derived from <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It works with . (at least for cg_clif) Edit: works with too.
<details<summaryMir of the second example (-Zmir-opt-level=2)</summary</details<details<summaryMir of the second example (-Zmir-opt-level=3)</summary</details
modify labels: +A-mir +C-bug
This is only miscompiled when const prop runs.
Bisected to . I'm a relatively new contributor, but I'd like to try and see if I can fix this. claim