update status of dynamic checks (#34)

update status of dynamic checks

Author: oli-obk

const.md

@@ -57,10 +57,7 @@ is actually accepted by the compiler because we know that there is no
 `UnsafeCell` here that would permit interior mutability.
 
 *Dynamic check.* The Miri engine enforces this dynamically by ensuring that the
-new data that is interned for a constant is all marked as immutable. However,
-note the FIXME added [by this PR](https://github.com/rust-lang/rust/pull/63955):
-for untyped data in a constant, we currently just *make* it immutable, instead
-of checking properly.
+new data that is interned for a constant is all marked as immutable.
 
 Note that a constant *referring to* some already existing mutable memory is
 fine: inlining that reference everywhere has the same behavior as computing a
@@ -113,5 +110,5 @@ 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.
 
-*Dynamic check.* The Miri engine could check this dynamically by refusing to
-access mutable global memory when computing a const.
+*Dynamic check.* The Miri engine checks this dynamically by refusing to access
+global memory when computing a const.

promotion.md

@@ -120,6 +120,13 @@ restrictions described there are needed because we want `const` to behave the
 same as copying the `const` initializer everywhere the constant is used; we need
 the same property when promoting expressions. But we need more.
 
+Note that there is no point in doing additional dynamic checks here.  The entire point of
+the promotion restrictions is to avoid failing compilation for code that would
+have been fine without promotion.  The best a dynamic check could do is tell us
+after the fact that we should not have promoted something, but then it is
+already too late -- and the dynamic checks for that are exactly the ones we are
+already doing for constants and statics.
+
 ### Panics
 
 Promotion is not allowed to throw away side effects.  This includes panicking.
@@ -153,9 +160,6 @@ earlier version of miri used to panic on arithmetic overflow even in release
 mode.  This breaks promotion, because now promoting code that would work (and
 could not panic!) at run-time leads to a compile-time CTFE error.
 
-*Dynamic check.* The Miri engine already dynamically detects panics, but the
-main point of promoteds is ruling them out statically.
-
 ### Const safety
 
 We have explained what happens when evaluating a promoted panics, but what about
@@ -202,9 +206,6 @@ way when working with const-safe arguments.
 For this reason, only `const fn` that were explicitly marked with the
 `#[rustc_promotable]` attribute are subject to promotion.
 
-*Dynamic check.* The Miri engine already dynamically detects const safety
-violations, but the main point of promoteds is ruling them out statically.
-
 ### Drop
 
 Expressions returning "needs drop" types can never be promoted. If such an