mention the extra const UB

[RalfJung]

Cc @rust-lang/wg-const-eval @rust-lang/wg-unsafe-code-guidelines -- I think that is the only extra const UB but let me know if I missed anything. :)

[Havvy]

This is an editorial review. I have not verified the technical content.

Editorial feedback applied.

[RalfJung]

@Havvy @ehuss what is needed to move this PR forwards?

[ehuss]

Sorry for the delay. This looks good to me, but I don't actually know the specifics of what is UB, or how we should decide that. I trust that you are correct, but it might help to get one other person who is familiar with it to approve it.

Perhaps @oli-obk or someone on wg-unsafe-code-guidelines, can you find someone to take a look?

[RalfJung]

@rust-lang/wg-const-eval @rust-lang/opsem please have a look at this PR. :)

[digama0]

Is there a reason this needs to be UB and not simply an error? A more advanced implementation of const-eval could potentially handle this in limited situations, and in all the cases where rustc hits this issue, it reliably rejects the pattern.

[CAD97]

I believe this PR is an accurate description of the current state of affairs.

The one thing to pay attention to is that this implicitly confirms that ptr-int transmutes are permitted outside of const contexts (by stating it's UB specifically in const context). I believe we've decided this is both fine and desired (semantics: strip provenance when loading as integer (ptr::addr)), loading a pointer without provenance loads an integer then as casts to pointer (ptr::from_exposed_addr)), but it's probably still a good idea to have an FCP for that.

Is there a reason this needs to be UB and not simply an error?

A not insignificant reason is that we don't really have a way to say / precedent for an operation which is an error at const time but just permitted at runtime. The closest would I guess be panics, but those errors would be better understood as being an unwind, and were catch_unwind to be const, it should probably catch const panics as well.

There's also the fact that it decidedly was UB previously (exposing nondeterminism into const) before it was turned into an error.

The original unsafe in const RFC covers more motivation on why we chose to treat const UB the way we do. (Not the least being continuing confusion between lib and lang UB.) Rustc goes to decent lengths to diagnose unambiguous lang UB in const, and we should expect it and any alternative frontends to continue to do so, but from the opsem perspective const evaluation errors are basically UB by definition (they're raised by operations for which the evaluator defines no semantics).

(IIRC: const UB is permitted to fail compilation and/or compromise the output artifact arbitrarily, but must not result in the compiler doing anything it couldn't otherwise do. Rustc provides an additional QOI guarantee that when no error is produced, compiler behavior is further bound to that reachable by selecting arbitrary byte-valid results for the const context (e.g. won't cause a linked but never mentioned proc macro to be run).)

[digama0]

Right, I am aware that our const UB semantics are both much more constrained than regular UB, but also quite nondeterministic, which is why I think if at all possible we should opt for something more well defined than that.

A not insignificant reason is that we don't really have a way to say / precedent for an operation which is an error at const time but just permitted at runtime.

You could say likewise that we don't have a precedent for an operation which is UB at const time and permitted at runtime. If the RFC rust-lang/rfcs#3352 regarding const time / runtime divergence goes through (which I expect to happen), then having an operation that is an error at const time and works at runtime seems quite reasonable and tame to work with, while an operation that is UB at const time (and is allowed to corrupt any constant it is used in) couldn't really be part of a library at all.

[RalfJung]

The main reason is that there is no such thing as a const eval error. Also the current implementation doesn't error at transmute time, it errors later or not at all depending on what is done with the result. Detecting illegal transmutes is non-trivial as they can occur in many syntactic positions (e.g. any time a load from a raw pointer or reference occurs). So the status quo really is const UB, and it is unclear whether we can do qualitatively better in the given performance budget.

There's also the fact that it decidedly was UB previously (exposing nondeterminism into const) before it was turned into an error.

We never exposed non-det to const. The implementation has always been very much like what it is now, just less documented.

[RalfJung]

Note that this UB went through t-lang FCP here, 2 years ago. We just forgot to add it to the reference. So I think that should be sufficient justification to merge as-is.

@digama0 if you want to change this to a const-eval error and have a good idea for how to realize this, I'm not opposed, but I don't think that should block updating the reference to a consensus that was formed 2 years ago.

[digama0]

I'll retract my concern.

[ehuss]

Thanks! I did not realize this was part of rust-lang/rust#85769, I missed the UB part in #1081. Thanks all for taking a look, if there any other concerns or feedback, feel free to follow up with comments or PRs.