Change:
providers.eval_to_const_value_raw = const_eval::eval_to_const_value_raw_provider; providers.eval_to_allocation_raw = const_eval::eval_to_allocation_raw_provider; providers.const_caller_location = const_eval::const_caller_location; <del> providers.destructure_const = |tcx, param_env_and_value| { </del> <ins> providers.try_destructure_const = |tcx, param_env_and_value| { </ins> let (param_env, value) = param_env_and_value.into_parts(); <del> const_eval::destructure_const(tcx, param_env, value) </del> <ins> const_eval::try_destructure_const(tcx, param_env, value).ok() </ins> }; providers.const_to_valtree = |tcx, param_env_and_value| { let (param_env, raw) = param_env_and_value.into_parts();

Discussion:
<!-- 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
For the record, it is due to and doesn't require (but does require that flag, and only happens during ) I've tracked this down (possibly) to which is only enabled when opt-level = 3. I might take a look at this..
So actually this doesn't even depend on . I'm not sure which mir pass is causing this actually, but only happens when we match which is inlined in a match block (not in a separate statement). The variable binding for the case is also important, and the issue seems to be a discriminant value of being produced somewhere... minimized (ICEs with ):
Yeah so it just seems like we're creating invalid scalar values as intermediates in optimization passes (e.g. after const propagation), and then panicking when we pretty-print those invalid values when dumping MIR. I can give a more detailed explanation why we're creating an invalid scalar, but that scalar is being optimized out anyways in subsequent optimization passes, so I don't think this would ever affect codegen... So not sure how scary this ICE is in practice. I would claim this issue, but I don't know what the best fix for this would be. Perhaps making return a instead of a value...? Not sure who to ask -- or perhaps either of y'all have an opinion on this? <details<summary<breason why we're creating an invalid scalar</b</summaryvalue is const-evaluated into the scalar value . we generate the MIR branch for , we emit the MIR expression where is that scalar value above. const-propagation, we try to inline (that is, scalar value ) into all places that reference it, even those that are invalid, such as the unreachable branch. , we end up basically calculating . This ends up creating an with an invalid scalar value of (we only expect the values and ).

then try to pretty print that value by getting its discriminant and values, but we are unable to tell what the discriminant of an with an invalid scalar value is. So we ICE. </details
An optimization pass that introduces invalid scalars literally introduces UB into well-defined code (unless this is in dead code), so -- I would say this is rather scary, on the level of "I-unsound".
Fairly certain this only happens in unreachable branches (default branches of exhaustive switches), but i'll dig into it.
Sorry, yes, it only seems to happen (as far as I know) in dead branches. The issue here only seems to be printing MIR with these dead branches still in the code.
Okay that is less critical then. Arguably printing should work even for invalid code. It still seems interesting to figure out why this happens. I would understand if this was an uninhabited variant, but seeing an entirely non-existing discriminant is surprising.
I left an explanation above in an collapsible block as to why we're creating this invalid value. I believe the root cause is that we perform operations in const propagation infallibly. It would probably be desirable to prevent this by making const propagation fallible if the const is incompatible with the layout of the result of the operation being applied to it. Then when we apply something like when to access the field of the variant on a dead branch, we don't create an invalid value.
Okay so it looks like possibly we should adjust the "downcast" projection(s) to verify that the place has the right variant, and otherwise? Then evaluating would fail and ConstProp would not touch that code, I think.
yup that sounds correct. do you want me to make that change?
One thing I am wondering about is if this will work correctly for generators -- the have more complicated variants than enums do, and maybe there are situations there where projections to the "wrong" variant are actually okay? Cc
are you proposing to declare downcast to an inactive variant to be undefined behaviour? This is probably larger change, in a sense that it would be incompatible with how downcast is currently used: In generators each field is accessed through a single representative variant, regardless of the current variant. Aggregate enum assignments are lowered to a field-wise assignments (using downcast) with a discriminant set last.
Yes, basically.

But it seems like that plan won't work. Interesting. I should probably add a comment in the code explaining why this is not currently considered UB. Well then it seems the best we can do for this ICE is to make the printing code more robust. It is anyway a good idea to be able to print invalid values; otherwise, debugging invalid values can be quite frustrating.