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

[RalfJung]

Follow-up to #1858.

[RalfJung]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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?

[RalfJung]

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]

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.

[traviscross]

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

[RalfJung]

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.

[traviscross]

I may yet make some further editorial revisions, but @RalfJung, how does this look?

[traviscross]

Thanks @RalfJung for the follow-up here.

[RalfJung]

Should all these here be marked as "NOTE" or "EXAMPLE" or so?

[traviscross]

No, when we put an example under a rule that's directly demonstrating what that rule means we just put it inline. It's a bit nuanced. It's a distinction we've been been working out recently.