const-eval.const-expr.borrows: mention indirect places #1865

RalfJung · 2025-06-18T00:35:06Z

Follow-up to #1858.

RalfJung · 2025-06-18T02:17:40Z

Based on the last commit I added in rust-lang/rust#140942, instead of a list of things we allow, we could consider just saying what is not allowed -- mutable / interior mutable borrows of lifetime-extended places. Maybe that would be better?

traviscross · 2025-06-19T16:32:07Z

Thanks @RalfJung; @ehuss and talked about this new language. On first pass, it looks pretty good to us. To your question about stating this in terms of what's not allowed, that also had some appeal to us, and we actually think it'd be best in this case to do both, i.e. to state what's allowed, as is done here, and to then also approach the same truth from the other side by stating what's not allowed. We do that in a number of places, and this seems like a good candidate for it, in terms of being as clear as possible.

RalfJung · 2025-06-20T01:59:06Z

I've given that a shot, please let me know what you think.

I also realized destructors.scope.lifetime-extension.static fails to mention that it applies specifically to the top-level scope of const/static initializers.

traviscross · 2025-06-23T23:49:50Z

Thanks. Probably we'll want to add some examples here for each.

Regarding the "top-level scope" bit, I wonder if there's a more clear way we could say that. We allow, of course, e.g.:

struct S;
const fn temp() -> S { S }
const C1: &S = { let y = { let x = &temp(); x }; y };
const C2: &S = 'top: { let y = { let x = &temp(); break 'top x; }; };

That is, there's a distinction between the temporary being created in the top-level scope and being referenced by the final value.

RalfJung · 2025-06-25T15:50:02Z

All of those are immutable references so yes of course we allow them. That doesn't really exercise the clauses this PR is about, though.

There are no examples for any of the surrounding text here so I'll not try to figure out the best way to integrate examples into this part of the docs.

traviscross · 2025-06-26T16:55:24Z

All of those are immutable references so yes of course we allow them. That doesn't really exercise the clauses this PR is about, though.

The question is about this change specifically, which is independent of mutability:

 r[destructors.scope.lifetime-extension.static]
-Lifetime extension also applies to `static` and `const` items, where it makes temporaries live until the end of the program. 
+Lifetime extension also applies to the top-level scope of `static` and `const` items, where it makes temporaries live until the end of the program.

It seems that the rule for this should be essentially the same as the rule that precedes it, except that we're extending to 'static rather than to the scope of the containing block:

r[destructors.scope.lifetime-extension.let]
The temporary scopes for expressions in let statements are sometimes extended to the scope of the block containing the let statement. This is done when the usual temporary scope would be too small, based on certain syntactic rules.

(Admittedly, that rule is rather ambiguous itself.)

So if this "top-level scope" qualification makes sense for one, then it would seem to make sense for the other.

But I think it gets into some ambiguity about "are we talking about the temporary being created in the top-level scope or about the temporary being referenced by the value returned from the top-level scope?". Clearly we don't mean the former.

RalfJung · 2025-06-26T17:28:55Z

We mean "the temporary is extended to the scope outside the const initializer expression". Not sure what is the best way to put that...

traviscross · 2025-06-26T17:34:46Z

There are no examples for any of the surrounding text here so I'll not try to figure out the best way to integrate examples into this part of the docs.

We'll take care of integrating these, but @ehuss and I would be interested if you could provide here, just as a reply, differentiating examples (i.e. examples that fit in exactly one category) for each of the things we're defining here, i.e. transient places, indirect places, places based on static items, and places based on promoted expressions.

traviscross · 2025-06-26T17:59:11Z

We mean "the temporary is extended to the scope outside the const initializer expression". Not sure what is the best way to put that...

Thanks. I pushed a clarification to define this in terms of the other rule that touches on this.

RalfJung · 2025-06-27T05:51:20Z

src/destructors.md

-Lifetime extension also applies to the top-level scope of `static` and `const` items,
-where it makes temporaries live until the end of the program.
-For example:
+The temporary scopes for expressions in `const` and `static` item initializers are sometimes extended until the end of the program following the same rule as in [destructors.scope.lifetime-extension.let]. For example:


"sometimes" isn't very helpful, is it? Can't we say something more precise, such as what you say in the commit message?

In const and static item initializers, if the scope of a temporary would be extended to a scope outside that of the initializer expression, then the temporary lives until the end of the program.

And then maybe we want to add something like this somewhere:

This effectively makes such a temporary a new global variable. This global variable is always immutable; the limitations in [const-eval.const-expr.borrows] rule out constants where a mutable temporary would have to live until the end of the program.

In reading the rest of the section more carefully, I actually feel like we should just defer this to another PR. The existing language has to be read in the context of everything that follows it -- most of which is talking about let statements even though it also applies to const and static items -- and in that context, all this is trying to say, when it says,

Lifetime extension also applies to static and const items, where it makes temporaries live until the end of the program.

is that the rules that precede and follow this rule, even though they're referring to let statements, "also" apply to static and const items, modulo that in this case, rather than extending to the scope of the enclosing block, "it makes temporaries live until the end of the program."

Probably there's a way to improve this section overall, but I'm now convinced doing that coherently requires touching many of the rules here.

(I pulled the change to this rule out of the commit and dropped my commit.)

rust-lang/rust#140942 now already introduced the "top-level" wording into compiler errors. That should then probably be adjusted if that is not the term we use in the reference. Any suggestion for what the error should say?

I'm thinking about this. My first inclination is to say something to the effect of:

mutable borrow of a temporary whose lifetime would be extended to 'static is not allowed in a const initializer

and:

shared borrow of an interior mutable temporary whose lifetime would be extended to 'static is not allowed in a const initializer

(This is maybe a bit of a pun, because strictly speaking references have their lifetimes extended while temporaries have their scopes extended, and as phrased, it's not clear whether we're talking about the reference (due to the borrow) or the temporary, but it doesn't matter here, so it seems OK to me, and it seems probably more familiar here to talk about lifetime extension to 'static rather than about scope extension to the end of the program.)

That's very close to what I did in rust-lang/rust#143092, except I do refer to scopes there.
(Sorry, I should have mentioned here that I made a PR.)

Ah, yes, that looks good too.

...except I do refer to scopes there.

(Looking at the diff, it actually went with "lifetime extended until the end of the program".)

Ah, right. So a mix of "scope extended" and "lifetime becomes 'static", I guess.

RalfJung · 2025-06-27T05:54:48Z

differentiating examples (i.e. examples that fit in exactly one category) for each of the things we're defining here, i.e. transient places, indirect places, places based on static items, and places based on promoted expressions.

static mut S: i32= 0;

#[allow(static_mut_refs)]
const C: () = {
  let mut x = 0;
  let mref = &mut x; // reference to transient place
  let mref2 = &mut *mref; // reference to indirect place
  let sref = unsafe { &mut S }; // reference to static place
  let pref: &mut [i32] = &mut []; // reference to promoted
};

traviscross · 2025-06-27T07:26:34Z

Thanks @RalfJung for the examples. I've pushed commits to integrate those and some others and to hopefully clarify some language. Let me know if that all looks right.

traviscross · 2025-06-27T08:07:57Z

In testing, I notice this:

---- const_eval.md - Constant_evaluation::Constant_expressions (line 212) stdout ----
error[E0764]: mutable borrows of lifetime-extended temporaries in the top-level scope of a constant are not allowed
 --> const_eval.md:213:18
  |
3 | const C: &[u8] = &mut [];
  |                  ^^^^^^^

error: aborting due to 1 previous error

This borrow isn't of an interior mutable temporary. Does this imply a second or a broader exception, you think, or is this covered by something else?

Thanks to RalfJ for the substance of many of these.

Rather than talking about lifetime-extended temporaries in the top-level scope of an initializer, which is maybe a bit ambiguous, let's speak directly to the result of the lifetime extension, which is that these temporaries disallowed for borrows (in cases of interior mutability) would have their lifetimes extended to the end of the program.

RalfJung · 2025-06-27T09:36:46Z

It's mutable, but not interior mutable.

Though what I find odd is that &mut [] should be promoted, and then I'd expect this to actually compile...

RalfJung · 2025-06-27T13:16:11Z

src/const_eval.md

-  are only allowed to refer to *transient* places or to *static* places. A place is *transient*
-  if its lifetime is strictly contained inside the current [const context].
-  A place is *static* if it is a `static` item or a [promoted expression].
+* All forms of [borrow]s, including raw borrows, with one limitation: mutable borrows and shared borrows of expressions whose temporary scope would be extended (see [temporary lifetime extension]) to the end of the program are not allowed when those borrows refer to values with interior mutability.


This makes it sound like the "when those borrows refer to values with interior mutability" part applies to everything, which isn't correct, it only applies to "shared borrows". Basically, borrows with any form of mutability are disallowed to refer to such temporaries, and we have two kinds of mutable borrows: actually mutable borrows, and shared borrows with interior mutability.

Interesting. Prior to my commit, the language was:

All forms of [borrow]s, including raw borrows, with one limitation: mutable borrows and shared borrows to values with interior mutability are not allowed to refer to lifetime-extended temporaries in the top-level scope of a const or static initializer expression.

I had read this same ambiguity into this verbiage. Thinking about it now, of course, this doesn't make any sense, as mutable references to UnsafeCell aren't special. I'll clarify the verbiage.

"mutable borrows and shared borrows to values with interior mutability" was intended to parse as

mutable borrows, and

shared borrows to values with interior mutability

English makes it hard to express this unambiguously...

RalfJung · 2025-06-27T13:16:39Z

src/const_eval.md

+  ```rust,compile_fail,E0492
+  # use core::sync::atomic::AtomicU8;
+  let _: &'static _ = const { &AtomicU8::new(0) }; // ERROR not allowed
+  ```


I can't figure out which of these examples is meant to demonstrate what.

Fair enough. I'll add some comments.

RalfJung · 2025-06-27T13:17:35Z

src/const_eval.md

+  ```
+
+  ```rust
+  const C: &[u8] = &[]; // Borrow of promoted expression.


This isn't even in the class of "borrows with some form of mutability", so I don't understand how it makes sense as an example here.

This needs to be reworked due to #1865 (comment) as well.

RalfJung · 2025-06-27T13:18:05Z

src/const_eval.md

+
+  ```rust,compile_fail,E0764
+  # use core::sync::atomic::AtomicU8;
+  const C: &AtomicU8 = &mut AtomicU8::new(0); // ERROR not allowed


Mixing &mut and interior mutability just causes confusion about which source of mutability actually matters here, I think we should avoid it in these examples.

Ah, I see in the comment over in #1865 (comment) this does touch on an ambiguity in the text.

RalfJung · 2025-06-27T13:28:34Z

So, uh, looks like we are doing the static const checks before we do promotion? @oli-obk is that expected?

That means we should remove promotion from the text and examples in this PR.

oli-obk · 2025-06-27T14:26:40Z

static const checks happen before promotion intentionally. I think they should even be a part of typeck, and I think we should be able to move more of it into typeck

RalfJung · 2025-06-27T14:35:00Z

Okay, looks like I just entirely forgot about that then.

That's good, discussing promoteds here got a bit awkward IMO...

… r=oli-obk const checks for lifetime-extended temporaries: avoid 'top-level scope' terminology This error recently got changed in rust-lang#140942 to use the terminology of "top-level scope", but after further discussion in rust-lang/reference#1865 it seems the reference will not be using that terminology after all. So let's also remove it from the compiler again, and let's focus on what actually happens with these temporaries: their lifetime is extended until the end of the program. r? `@oli-obk` `@traviscross`

… r=oli-obk const checks for lifetime-extended temporaries: avoid 'top-level scope' terminology This error recently got changed in rust-lang#140942 to use the terminology of "top-level scope", but after further discussion in rust-lang/reference#1865 it seems the reference will not be using that terminology after all. So let's also remove it from the compiler again, and let's focus on what actually happens with these temporaries: their lifetime is extended until the end of the program. r? ``@oli-obk`` ``@traviscross``

traviscross · 2025-06-27T21:08:46Z

It seems a rather subtle point to document, given that:

const C1: &[u8] = { let x: &'static mut [u8] = &mut []; x }; //~ OK
const C2: &[u8] = { &mut [] }; //~ ERROR

Rollup merge of #143092 - RalfJung:const-check-lifetime-ext, r=oli-obk const checks for lifetime-extended temporaries: avoid 'top-level scope' terminology This error recently got changed in #140942 to use the terminology of "top-level scope", but after further discussion in rust-lang/reference#1865 it seems the reference will not be using that terminology after all. So let's also remove it from the compiler again, and let's focus on what actually happens with these temporaries: their lifetime is extended until the end of the program. r? ``@oli-obk`` ``@traviscross``

const checks for lifetime-extended temporaries: avoid 'top-level scope' terminology This error recently got changed in rust-lang/rust#140942 to use the terminology of "top-level scope", but after further discussion in rust-lang/reference#1865 it seems the reference will not be using that terminology after all. So let's also remove it from the compiler again, and let's focus on what actually happens with these temporaries: their lifetime is extended until the end of the program. r? ``@oli-obk`` ``@traviscross``

RalfJung · 2025-06-28T07:02:30Z

Yeah, that is kind of odd -- the fact that lifetime extension kicks in here means that code that would otherwise have compiled (if there was no lifetime extension) now does not compile.

rustbot added the S-waiting-on-review Status: The marked PR is awaiting review from a maintainer label Jun 18, 2025

const-eval.const-expr.borrows: mention indirect places

9d83c64

RalfJung force-pushed the const-expr-borrows-indirect branch from 9fe65cb to 9d83c64 Compare June 18, 2025 00:36

RalfJung mentioned this pull request Jun 21, 2025

const-eval: allow constants to refer to mutable/external memory, but reject such constants as patterns rust-lang/rust#140942

Merged

traviscross force-pushed the const-expr-borrows-indirect branch from ae67917 to 2ee9fd4 Compare June 26, 2025 17:51

RalfJung commented Jun 27, 2025

View reviewed changes

also spell out which borrows are *not* allowed

62a33ad

traviscross force-pushed the const-expr-borrows-indirect branch 2 times, most recently from 691ec18 to 846f675 Compare June 27, 2025 07:25

traviscross force-pushed the const-expr-borrows-indirect branch 2 times, most recently from bf9bc37 to 07b3859 Compare June 27, 2025 07:53

traviscross added 2 commits June 27, 2025 08:09

Add examples

0955af2

Thanks to RalfJ for the substance of many of these.

traviscross force-pushed the const-expr-borrows-indirect branch from 07b3859 to c55401b Compare June 27, 2025 08:10

RalfJung commented Jun 27, 2025

View reviewed changes

RalfJung mentioned this pull request Jun 27, 2025

const checks for lifetime-extended temporaries: avoid 'top-level scope' terminology rust-lang/rust#143092

Merged

RalfJung mentioned this pull request Jun 28, 2025

Lifetime extension in consts/statics sometimes makes *less* code compile rust-lang/rust#143129

Open

const-eval.const-expr.borrows: mention indirect places #1865

Are you sure you want to change the base?

const-eval.const-expr.borrows: mention indirect places #1865

Conversation

RalfJung commented Jun 18, 2025

Uh oh!

RalfJung commented Jun 18, 2025

Uh oh!

traviscross commented Jun 19, 2025

Uh oh!

RalfJung commented Jun 20, 2025

Uh oh!

traviscross commented Jun 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RalfJung commented Jun 25, 2025

Uh oh!

traviscross commented Jun 26, 2025

Uh oh!

RalfJung commented Jun 26, 2025

Uh oh!

traviscross commented Jun 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

traviscross commented Jun 26, 2025

Uh oh!

RalfJung Jun 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

traviscross Jun 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

traviscross Jun 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Jun 27, 2025

Uh oh!

traviscross commented Jun 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

traviscross commented Jun 27, 2025

Uh oh!

RalfJung commented Jun 27, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

traviscross Jun 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as resolved.

Uh oh!

traviscross Jun 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as resolved.

traviscross commented Jun 23, 2025 •

edited

Loading

traviscross commented Jun 26, 2025 •

edited

Loading

RalfJung Jun 27, 2025 •

edited

Loading

traviscross Jun 27, 2025 •

edited

Loading

traviscross Jun 27, 2025 •

edited

Loading

traviscross commented Jun 27, 2025 •

edited

Loading

traviscross Jun 27, 2025 •

edited

Loading

traviscross Jun 27, 2025 •

edited

Loading

traviscross Jun 27, 2025 •

edited

Loading