move 'enclosing scope' discussion

Author: RalfJung

promotion.md

@@ -47,36 +47,6 @@ corresponding arguments.
 Similarly, inline assembly has `const` operands, which are treated the same way
 as `rustc_args_required_const` arguments.
 
-### Promotion inside `const` and `static`
-
-Lifetime extension is also responsible for making code like this work:
-
-```rust
-const FOO: &'static i32 = {
-    let x = &13;
-    x
-};
-```
-
-Like in run-time code, a part of the MIR (the one computing `13`) is spliced
-into a separate MIR body, and evaluated like a separate constant.  In the case
-of `const` and `static` initializers, this does not affect how the code is
-evaluated (everything happens at compile-time), but it still affects the
-lifetimes.
-
-Notice that some code involving `&` *looks* like it relies on lifetime
-extension but actually does not:
-
-```rust
-const EMPTY_BYTES: &Vec<u8> = &Vec::new(); // Ok without lifetime extension
-```
-
-`Vec::new()` cannot get promoted because it needs dropping. And yet this
-compiles. Why that? The reason is that the reference obtains the lifetime of
-the "enclosing scope", similar to how `let x = &mut x;` creates a reference
-whose lifetime lasts for the enclosing scope. This is decided during MIR
-building already, and does not involve lifetime extension.
-
 ## Implicit and explicit promotion
 
 On top of what applies to [consts](const.md), promoteds suffer from the additional issue that *the user did not ask for them to be evaluated at compile-time*.
@@ -116,6 +86,23 @@ 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.
 
+## "enclosing scope" rule
+
+Notice that some code involving `&` *looks* like it relies on lifetime
+extension but actually does not:
+
+```rust
+const EMPTY_BYTES: &Vec<u8> = &Vec::new(); // Ok without lifetime extension
+```
+
+`Vec::new()` cannot get promoted because it needs dropping. And yet this
+compiles. Why that? The reason is that the reference obtains the lifetime of
+the "enclosing scope", similar to how `let x = &mut x;` creates a reference
+whose lifetime lasts for the enclosing scope. This is decided during MIR
+building already, and does not involve lifetime extension.
+
+This is also sometimes called "outermost scope" rule.
+
 ## Promotability
 
 We have described the circumstances where promotion is desirable, but what