adjust docs to reality

Author: RalfJung

promotion.md

@@ -100,17 +100,22 @@ promotion.
 
 Currently, the following are considered explicit promotion contexts:
 * `#[rustc_args_required_const]` arguments and inline assembly `const` operands everywhere
-* lifetime extension in the bodies of `const` and `static` items and array lengths
-* lifetime extension in the bodies of `const fn` -- but this is not justified by the above discussion; since `const fn` can be runtime-evaluated, the concerns about introducing hard errors where there would be none apply for `const fn` in exactly the same way as for `fn`, but this was overlooked when implementing the checks
 
-Everything else is an implicit promotion context, in particular non-`Copy` array initializers.
-
-In an explicit promotion context, we consider almost everything promotable,
-subject to the usual restrictions of [consts](const.md). This means that
-interior mutability and values that need dropping are not promoted.
+In these contexts, we promote calls to arbitrary `const fn`. That is currently
+the only difference.
 
 [warn-rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1229-compile-time-asserts.md
 
+## Promotion in const contexts
+
+When promoting inside a const context (`const` and `static` items and `const fn`), we relax almost all promotion restrictions, except for basic constness restrictions (such as interior mutability or `Drop`).
+We do this for all kinds of promotion.
+
+For `const fn`, [this is a bug](https://github.com/rust-lang/rust/issues/75586).
+
+For `const` and `static` items, this can lead to promoting things that can fail to evaluate.
+Currently, this works out because in the first case it just leads to a warning, but longer-term it would be desirable to turn evaluation failures into hard errors, which for these promoteds means we have to guarantee that we only evaluate them on-demand.
+
 ## Promotability
 
 We have described the circumstances where promotion is desirable, but what