Invalid (unstable, ill-formed, ...) const code is evaluated even after emitting error

[RalfJung]

Nightly-only ICEs are exposed on stable because array lengths are evaluated even when they are invalid:

struct Bug([u8; panic!(1)]);

This first emits an error that a feature flag is missing, but then const-evaluates the array length anyway and later leads to an ICE. This is not a stability hole (there's an error, the code will not compile), but it's an ICE on stable, so it's a bug.

While the ICE should also be fixed, the underlying problem is that we should not const-evaluate code that failed stability checking (and there are possibly other kinds of checks to which this applies as well)

@oli-obk proposed some solutions:

• poison the mir Body if const checks fail (by adding a field like https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TypeckResults.html#structfield.tainted_by_errors or by just nuking the body by replacing it with _0 = ConstKind::Error; return;) and thus make allow const evaluation to check if the mir Body failed the checks and bail out before doing anything
• make the https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.ConstQualifs.html have an error field similar to https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.TypeckResults.html#structfield.tainted_by_errors

Cc @rust-lang/wg-const-eval

[ecstatic-morse]

Putting this on ConstQualifs seems reasonable. It seems better than adding more cruft to mir::Body at first glance. Currently each field of ConstQualifs is tied to an implementer of the Qualif trait but this isn't a hard requirement.

[RalfJung]

Once this is fixed, we can hopefully also get rid of the TransmuteSizeDiff hack. I am not sure if we carry any other similar hacks that we still carry around.

[RalfJung]

@oli-obk the solution at #78809, if I understand correctly, does not fix TransmuteSizeDiff... should that become a separate issue once this one is closed, or is there some reason that TransmuteSizeDiff cannot be fixed by adding a similar ErrorReported to the transmute size check?

[oli-obk]

It does indeed not fix TransmuteSizeDiff. We'll need to investigate what actually causes a transmute size check failure to not affect tainted_by_errors. We can likely fix this in a similar manner. Though we also have other bugs like { let x; &x } getting all the way to interning when it fails due to a dangling pointer. We'll be collecting more and more error flags to keep track of. I'm not sure how to address this properly. Maybe we'll need more Result<T, ErrorReported> on queries that don't return an enum which has an error variant (like ty::Err or ConstKind::Err)

[RalfJung]

I opened a new issue for the transmute problem: #79047.