The const-eval interpreter is called on incomplete/invalid/ill-formed code

[RalfJung]

It looks like #76064 is back. This is the source of countless ICEs. Just in the last few weeks:

• ICE: invalid asymmetric binary op #121858
• ICE: Unsigned value 0x100 does not fit in 8 bits #123690
• ICE: !base.layout().is_sized() #124436
• ICE during validation of ill-typed static: assertion left == right failed at rustc_const_eval/src/interpret/validity.rs #124164

As member of @rust-lang/wg-const-eval my position is that generally these are not const-eval bugs, but bugs in whatever part of the compiler is passing invalid data to const-eval. However, which part would that be? I am not sure whom to ping for this.^^

[jieyouxu]

IIRC @oli-obk has been trying to make compilation abort as late as possible to report as many errors as possible (at the item granularity). I'm not sure how to "suspend further compilation processes" for specific items that contain errors prior to const-eval.

[jieyouxu]

It's probably desirable to discuss some error handling strategy that preserves the "fail as late as possible, report as many errors as possible" idea and yet does not let inputs that const-eval does not expect to handle to go through, at the item granularity. Maybe this involves some pre-const-eval validation/guard, or hardening const-eval against invalid inputs, or some other strategy. Nominating for T-compiler discussion.

@rustbot label +I-compiler-nominated

[RalfJung]

On Zulip, @lcnr said that we already have the tainted_by_errors mechanism for this. But either the MIR bodies containing these invalid operations do not get tainted properly, or the interpreter is not properly skipping execution of tainted MIR bodies.

[apiraino]

Discussed in T-compiler triage on Zulip.

We'll circle back on this, maybe in a dedicated meeting (cc: @oli-obk who maybe has more context here)

@rustbot label -I-compiler-nominated