Merge pull request #13 from RalfJung/const-refs

Consts cannot read from (mutable) statics

Author: oli-obk

README.md

@@ -21,7 +21,7 @@ which sort of is a virtual machine using `MIR` as "bytecode".
 ## Table of Contents
 
 * [Const Safety](const_safety.md)
-* [Constant References](const_refs.md)
+* [Constants](const.md)
 * [Promotion](promotion.md)
 
 ## Related RFCs

const.md

@@ -0,0 +1,73 @@
+# Further restrictions for constants
+
+The [const safety](const_safety.md) concerns apply to all computations happening
+at compile-time, `static` and `const` alike.  However, there are some additional
+considerations about `const` specifically.  These arise from the idea that
+```rust
+const CONST: T = EXPR;
+```
+is supposed to behave as-if `EXPR` was written at every use site of `CONST`.
+
+## References
+
+One issue is constants of reference type:
+```rust
+const REF: &u32 = &EXPR;
+```
+Instead of creating a new allocation for storing the result of `EXPR` on every
+use site, we just have a single global "static" allocation and every use of
+`REF` uses its address.  It's as if we had written:
+```rust
+const REF: &u32 = { const _VAL = EXPR; static _STATIC = EXPR; &_STATIC };
+```
+(`EXPR` is assigned to a `const` first to make it subject to the restrictions
+discussed in this document.)
+
+There are three reasons why this could be an issue.
+
+### Pointer equality
+
+We effectively "deduplicate" all the allocations that would otherwise locally be
+created at each use site of `REF`.  This is observable when the program compares
+these pointers for equality.  We consider this okay, i.e., programs may not rely
+on such constants all getting distinct addresses.  They may not rely on them all
+getting the same address either.
+
+### Interior mutability
+
+If the reference has type `&Cell<i32>` it is quite clear that the program can
+easily observe whether two references point to the same memory even without
+comparing their address: Changes through one reference will affect reads through
+the other.  So, we cannot allow constant references to types that have interior
+mutability (types that are not `Freeze`).
+
+However, we can do better than that: Even if a *type* is not `Freeze`, it can
+have *values* that do not exhibit any interior mutability.  For example, `&None`
+at type `&Option<Cell<i32>>` would be rejected by the naive analysis above, but
+is actually accepted by the compiler because we know that there is no
+`UnsafeCell` here that would permit interior mutability.
+
+### `Sync`
+
+Finally, the same constant reference is actually shared across threads.  This is
+very similar to multiple threads having a shared reference to the same `static`,
+which is why `static` must be `Sync`.  So it seems like we should reject
+non-`Sync` types, conforming with the desugaring described above.
+
+However, this does not currently happen, and there are several crates across the
+ecosystem that would break if we just started enforcing this now. See
+[this issue](https://github.com/rust-lang/rust/issues/49206) and the
+[PR attempting to fix this](https://github.com/rust-lang/rust/pull/54424/).
+
+## Reading statics
+
+Beyond values of reference type, we have to be careful that *computing* a
+`const` cannot read from a static that could get mutated (because it is `static
+mut`, or because it has interior mutability).  That would lead to the constant
+expression (being computed at compile-time) not having the same value any more
+when evaluated at run-time.
+
+This is distinct to the concern about interior mutability above: That concern
+was about first computing a `&Cell<i32>` and then using it at run-time (and
+observing the fact that it has been "deduplicated"), this here is about using
+such a value at compile-time even though it might be changed at run-time.

const_refs.md

@@ -9,8 +9,9 @@ four possible ways:
 * The program causes undefined behavior (e.g., dereferencing an out-of-bounds
   pointer).
 * The program panics (e.g., a failed bounds check).
-* The program loops forever, and this is detected by the loop detector.  Note
-  that this detection happens on a best-effort basis only.
+* The program exhausts its resources: It might overflow the stack, allocation
+  too much memory or loops forever.  Note that detecting these conditions
+  happens on a best-effort basis only.
 
 Just like panics and non-termination are acceptable in safe run-time Rust code,
 we also consider these acceptable in safe compile-time Rust code.  However, we

const_safety.md

@@ -89,23 +89,17 @@ but to abort compilation of a program that would have compiled fine if we would
 not have decided to promote.  It is the responsibility of `foo` to not fail this
 way when working with const-safe arguments.
 
-### 3. Drop
+### 3. Constraints on constants
 
-TODO: Fill this with information.
-
-### 4. Reference constraints
+All the [extra restrictions for constants](const.md) beyond const safety also
+apply to promoteds, for the same reason: Evaluating the expression at
+compile-time instead of run-time should not alter program behavior.
 
-[Constant references](const_refs.md) impose some restrictions on the data they
-point to; the same restrictions apply to promoteds.
+### 4. Drop
 
-### 5. Accessing statics
-
-Since the promoted code is evaluated at compile-time, we must make sure that it
-does not access any mutable statics (including safe `static` with interior
-mutability), not even read from them.  Their value could have changed at
-run-time, so we wouldn't be producing the correct result.
+TODO: Fill this with information.
 
 ## Open questions
 
-* There is a fourth kind of CTFE failure -- and endless loop being detected.
-  What do we do when that happens while evaluating a promoted?
+* There is a fourth kind of CTFE failure -- resource exhaustion.  What do we do
+  when that happens while evaluating a promoted?