Using `Option` to get undefined behaviour in a `const`

[arnaudgolfouse]

I tried this code:

use std::num::NonZeroU8;

pub const UNDEFINED: Option<NonZeroU8> = Some(unsafe { NonZeroU8::new_unchecked(0) });

And assumed the compiler would reject it, but there was no compilation errors.

Note that the following also compiled:

use std::num::NonZeroU8;

pub const UNDEFINED: Option<NonZeroU8> = Some(unsafe { NonZeroU8::new_unchecked(0) });

// Sometime using the undefined constant triggers an error: not here...
pub use_undefined() -> Option<NonZeroU8> { UNDEFINED }

// This is not limited to Option !
pub enum MyOption {
    Some(NonZeroU8),
    None
}

pub const UNDEFINED2: MyOption = MyOption::Some(unsafe { NonZeroU8::new_unchecked(0) });

pub use_undefined2() -> MyOption { UNDEFINED2 }

I am assuming this is caused by layout optimizations ?

Meta

rustc --version --verbose:

rustc 1.59.0 (9d1b2106e 2022-02-23)
binary: rustc
commit-hash: 9d1b2106e23b1abd32fce1f17267604a5102f57a
commit-date: 2022-02-23
host: x86_64-unknown-linux-gnu
release: 1.59.0
LLVM version: 13.0.0

rustc +nightly --version --verbose:

rustc 1.61.0-nightly (68369a041 2022-02-22)
binary: rustc
commit-hash: 68369a041cea809a87e5bd80701da90e0e0a4799
commit-date: 2022-02-22
host: x86_64-unknown-linux-gnu
release: 1.61.0-nightly
LLVM version: 14.0.0

[RalfJung]

And assumed the compiler would reject it, but there was no compilation errors.

We do not guarantee that all Undefined Behavior is detected, not at run-time and not at compile-time. When you use unsafe, it is up to you to make sure you follow the rules.

We do detect some UB, e.g. here:

pub const UNDEFINED: NonZeroU8 = unsafe { NonZeroU8::new_unchecked(0) };

But exhaustively checking for all UB is super expensive at best. Even Miri, which does a lot more work than CTFE, does not detect all UB.

So I consider this not a bug.
Cc @rust-lang/wg-const-eval

[saethlin]

Miri detects this if the code is shifted to normal runtime eval. Is it worth considering moving this check into CTFE or does that just open up too many questions?

[Lokathor]

on the one hand i would like CTFE to catch it, on the other I'm worried if people might think that it'll then catch the runtime version as well (which it won't).

[saethlin]

I'm not so sure about that. C++ has set a precedent that const-eval has extra UB checking powers that normal runtime eval does not have.

[oli-obk]

As Ralf noted, this can be very expensive. We can benchmark it to see how expensive and make a decision based on that.

We can also consider using a lint for these extra checks and only turning them on if the lint is warn/deny (and set it to allow by default for speed).

Oh, even funnier idea: clippy can overwrite the const eval query to make it run with validation. This way cargo clippy will catch more UB than cargo check

[ChrisDenton]

Specifically in the narrow case of NonZero* integer types, would it be quicker for Rust to warn against any use of new_unchecked while in a const context?

[saethlin]

I am suspicious of claims that this check is expensive. Miri is poorly-benchmarked, does CTFE have any benchmarks?

[oli-obk]

Yes, CTFE is benchmarked with the rustc benchmarks. Trying it out is as simple as opening a PR removing

rust/compiler/rustc_const_eval/src/interpret/machine.rs

Line 424 in 8876ca3

fn enforce_validity(_ecx: &InterpCx<$mir, $tcx, Self>) -> bool {

and manually adding it to the two use sites of the macro. Then flip the bool for the const_eval case.

[fee1-dead]

It feels like it can just have debug_assert! inside the unchecked functions, or would it not be ideal?

[saethlin]

@fee1-dead I've had a PR up for the past few months that does just that :) #92686

[RalfJung]

That wouldn't make any difference here though, since the stdlib we ship is compiled without debug assertions.

[saethlin]

sigh of course the bigger problem is that all those checks are disabled in const eval. And I did that because I assumed while writing it that const eval would catch all these things. Around and around we go...

@oli-obk What's wrong with just doing this? I found out what is wrong with this (MIR transforms panic if they do validation).

diff --git a/compiler/rustc_const_eval/src/interpret/machine.rs b/compiler/rustc_const_eval/src/interpret/machine.rs
index 7d75c84d108..121121cdab2 100644
--- a/compiler/rustc_const_eval/src/interpret/machine.rs
+++ b/compiler/rustc_const_eval/src/interpret/machine.rs
@@ -422,7 +422,7 @@ fn force_int_for_alignment_check(_memory_extra: &Self::MemoryExtra) -> bool {
 
     #[inline(always)]
     fn enforce_validity(_ecx: &InterpCx<$mir, $tcx, Self>) -> bool {
-        false // for now, we don't enforce validity
+        true
     }
 
     #[inline(always)]

[fee1-dead]

That wouldn't make any difference here though, since the stdlib we ship is compiled without debug assertions.

Then an unconditional check using const_eval_select would suffice?

[RalfJung]

Then an unconditional check using const_eval_select would suffice?

Yes that would be an option.