Oli Scherer

> by invoking the machinery that powers `include_bytes!`. It's not yet possible to share the machinery between `include_bytes` and the hypothetical machinery for const eval reading files, because `include_bytes` runs...

> Why that? Does include_bytes! do that? Certainly build.rs and proc macros can read anywhere on the file system... (IMO they should be sandboxed but that's a long and separate...

I think the root issue is ```rust static FOO: AtomicUsize = AtomicUsize::new(42); // hides the static behind a regular reference const BAR: &AtomicUsize = &FOO; const fn bar() -> usize...

Additionally ```rust const WAT: usize = BAR.load(Ordering::Relaxed); ``` seems very weird, because `WAT` always has the compile-time value of the static, even though the static can change.

The problem is that any static (even a truly immutable one) can refer to other statics (which may then have interior mutability). So we'd need to enforce transitive immutability. Of...

Last attempt: https://github.com/rust-lang/rust/pull/66302

Cool, so I guess the first step is to give https://github.com/rust-lang/rust/blob/57e1da59cd0761330b4ea8d47b16340a78eeafa9/src/librustc_mir/transform/check_consts/ops.rs#L341 a feature gate that turns it on. Then you need to make it more fine grained by giving https://github.com/rust-lang/rust/blob/57e1da59cd0761330b4ea8d47b16340a78eeafa9/src/librustc_mir/transform/check_consts/ops.rs#L340...

> With unsafe code, type-based analyses can probably be circumvented, but I presume having post-monomorphization errors when people write "unconst" code is acceptable? Yes, I don't think we can ever...

> Given that an end user should only ever see evaluation-time or validation errors if they are using unsafe to circumvent the conservative static check, this is mostly just a...

> If this is too expensive for performance, we could have an analysis that remembers for each static "is mutable memory reachable from this". Then we could easily allow consts...