Explain additional rules for `unsafe` blocks in `const` and `const fn` #221

oli-obk · 2020-06-05T13:22:16Z

this is taken in large parts from https://github.com/rust-lang/const-eval/blob/master/const_safety.md

RalfJung · 2020-06-20T13:52:56Z

src/const-safety.md

@@ -0,0 +1,171 @@
+# Const safety
+
+The miri engine, which is used to execute code at compile time, can fail in


miri or Miri? I have often been writing the latter, but not consistently...^^

I've fairly consistently used the lower case form. 🤷 I have no opinion on it beyond "my fingers like not using more modifier keys than they need to".

More importantly though, I feel the first sentence is not a great introduction here. I wrote it in the context of the const-eval repo, but this is different.

I'd start with something like "As part of the compilation process, the Rust compiler has to evaluate some of the code of a program. This is called CTFE (compile-time function evaluation). CTFE is used for: array lengths, const/static initializers, ...". Then say that CTFE can go wrong and just like at run-time, safe Rust protects programmers from some of the ways CTFE can fail. "Programmers only writing safe code do not have to care about any of this, but if you want to write unsafe code that is run by CTFE, then there are some extra concerns you need to be aware of."

Then the following text makes much more sense IMO.^^

RalfJung · 2020-06-20T13:53:30Z

this is taken in large parts from https://github.com/rust-lang/const-eval/blob/master/const_safety.md

To avoid duplicating material, we should probably make that a link to the Nomicon after landing this.

src/const-safety.md

Co-authored-by: Ralf Jung <post@ralfj.de>

src/const-safety.md

Co-authored-by: Ralf Jung <post@ralfj.de>

src/const-safety.md

RalfJung · 2020-06-20T14:02:22Z

src/const-safety.md

+  * fails to run at compile time when it works perfectly fine at runtime
+  * produces a different result at compile time than at runtime
+
+is undefined behavior.


That would be a new kind of UB to be added to the reference, and to be checked by Miri. I think the latter will be really hard to do so I am not sure if it's worth it.

Yea, this is from before the guaranteed_* PR where I ended up agreeing that making it UB likely isn't worth it.

RalfJung · 2020-06-20T14:03:14Z

src/const-safety.md

+```
+
+If the function were invoked as `ptr_eq(&42, &42)` the result depends on the potential
+deduplication of the memory of the `42`s.


Or rather, the result is that we get an error of the first kind: an unsupported operation. That is what the const-safety definition says must not happen.
The reason it is unsupported is that it cannot, in general, be supported -- but the text is skipping a step here.

RalfJung · 2020-06-20T14:05:00Z

src/what-unsafe-does.md

@@ -7,6 +7,8 @@ The only things that are different in Unsafe Rust are that you can:
 * Implement `unsafe` traits
 * Mutate statics
 * Access fields of `union`s
+* Cast raw pointers to integers within const contexts
+* Compare raw pointers within const contexts


With the guaranteed_* intrinsics, we could actually disallow the latter entirely, even in unsafe code, right?

RalfJung · 2020-06-20T14:05:31Z

src/what-unsafe-does.md

@@ -18,6 +20,7 @@ language cares about is preventing the following things:

 * Dereferencing (using the `*` operator on) dangling or unaligned pointers (see below)
 * Breaking the [pointer aliasing rules][]
+* Violating the [const safety][] rules


Uh-oh... this list is synced with this one and changing it is a big deal.^^

To be clear, what I am saying is that I think this PR should not change this list.

RalfJung · 2020-06-24T18:36:49Z

So after the lang team design meeting that just happened, another alternative that emerged is to say that doing unconst things during CTFE is "simply" UB. And then we just have to describe what CTFE-UB is like, which we need to do anyway. I think that is actually my favorite plan so far. :D

Even if we adopt this (thus making most of the text here obsolete), some of the editing here could be incorporated into the const-eval version of this document.

JohnTitor · 2021-06-28T23:07:01Z

Triage: It has been about a year since the last comment, I presume this has been waiting for @oli-obk to address the review comments, right?

RalfJung · 2021-06-29T07:11:52Z

Also rust-lang/rfcs#3016 landed in the mean time (though I am not sure if that will affect this PR).

Co-authored-by: Ralf Jung <post@ralfj.de>

RalfJung · 2021-07-20T11:30:00Z

src/const-safety.md

+a pointer (`Scalar::Ptr`) *or* a bunch of bits representing an integer
+(`Scalar::Bits`), or uninitialized.  Every value of a variable of primitive type is stored as a
+`Scalar`.  In the code above, casting the pointer `&S` to `*const i32` and then
+to `usize` does not actually change the value -- we end up with a local variable


We don't allow ptr-to-int casts in const any more... should we adjust this story?

I'm going through the entire doc, too many things changed. I'm keeping everything in mind that was commented here, but the entire doc needs an overhaul

Explain additional rules for unsafe blocks in const and const fn

6d4b588

oli-obk mentioned this pull request Jun 5, 2020

[tracking issue] union field access inside const fn rust-lang/rust#51909

Closed