`const` expression can borrow static items #1610

dingxiangfei2009 · 2024-09-11T13:04:53Z

Tracked by rust-lang/rust#119618

Stabilization report: rust-lang/rust#128183

This PR updates the documentation to mention that now static items can be used for borrowing, explicitly or implicitly, which permits general use of them in const context.

ehuss

Can you also update https://github.com/rust-lang/reference/blob/master/src/items/static-items.md which mentions this isn't possible?

I'm wondering if this might be confusion (and perhaps my understanding is missing) with regards to what counts as a borrow. IIUC, statics have an implied &, is that correct? For example, if you see const C: i32 = SOME_STATIC;, there's no obvious borrow there.

dingxiangfei2009 · 2024-09-11T17:34:14Z

@ehuss I updated the wording to include simply "use of statics".

I have updated static-items page as well with tweaks on wording.

traviscross · 2024-09-17T21:18:41Z

We probably want to update the constant-items page that currently says:

Constants may refer to the address of other constants...

Since it'd now make sense for that to also address the fact that constants may refer to statics with some limitations.

traviscross · 2024-09-17T21:24:59Z

Also in const_eval.md, where it says:

Paths to statics. These are only allowed within the initializer of a static.

...that seems to need to change also.

traviscross · 2024-09-17T21:27:56Z

More generally, it seems what we need to do here is to loosen the various places in the Reference that have these restrictions, and in loosening them, add the necessary caveats, e.g. with respect to Freeze as described in rust-lang/rust#128183.

RalfJung · 2024-09-21T21:12:50Z

For example, if you see const C: i32 = SOME_STATIC;, there's no obvious borrow there.

There's no borrow at all there, obvious or otherwise.

MIR happens to represent SOME_STATIC as a pointer, making this look like *SOME_STATIC_PTR -- so even there, there's no borrow. Also that is an implementation detail and should not affect the reference at all.

RalfJung · 2024-09-21T21:14:53Z

src/items/constant-items.md

+## Use and reference to `static` items
+
+When a constant item or constant block is defined, [`static` items] can be used, borrowed or taken address of.
+By extension, you are allowed to call methods that immutably borrows the `static` items as receivers.


Yeah this should definitely explain that it is not allowed to read from or write to any mutable static (static mut and static !Freeze).

Do we already have a link into the reference to explain the static !Freeze items? It makes sense to me to make a reference here.

Oh this is largely missing. I guess I have to expand this section in const_eval.md. I can do that.

RalfJung · 2024-09-21T21:15:13Z

Constants may refer to the address of other constants...

That's a somewhat nonsensical statement as constants are values, they don't have an address.

RalfJung · 2024-09-22T06:02:41Z

I opened #1624 to fix the part about "address of a constant".

dingxiangfei2009 · 2024-09-22T19:39:25Z

@rustbot ready

I sieved through the document and I believe these are the places where use of static is mentioned.
I managed to add some sort of document about Freeze without mentioning it, given that it is not stabilized. In case [RFC] core::marker::Freeze in bounds rfcs#3633 lands and stabilization of the trait actually happens, I will follow up with the edits.

ehuss

Is there anywhere that mentions the extern static restrictions mentioned in the stabilization report?

src/const_eval.md

dingxiangfei2009 · 2024-10-01T21:29:04Z

@ehuss I added a section on extern { static }.

ehuss · 2024-10-09T14:25:11Z

I pushed a commit to simplify things. After reading more carefully, I was feeling like this was duplicating content that is already specified in the const_eval chapter. I'm reluctant to duplicate things since it makes it more challenging to maintain. I'm also a little reluctant to add deeper "exploration" style content which is essentially restating other rules. There is more specific reasoning in the commit message. If you disagree or think there is something that is now not documented, please let me know!

I realize this removes a lot of content from this PR, and I apologize for that. I probably should have been paying more attention earlier on and provided some guidance.

As for having more examples that illustrate specific const-eval limitations, I expect those to be added later over time (perhaps through the test suite links).

@traviscross Would you be willing to give this a final look? I think this is ready to go from my perspective.

ehuss

Thanks! ❤️

RalfJung · 2024-10-09T14:32:49Z

src/items/static-items.md

-* The type must have the `Sync` trait bound to allow thread-safe access.
-* Constants cannot refer to statics.
+All access to a static is safe,
+provided that the type must have the `Sync` trait bound to allow thread-safe access.


This makes it sound like a !Sync static would be unsafe to access. But actually it's just rejected.

Thanks! I have rewritten this to use more direct language. I'm not sure why the original was written to say "it is safe to ...", since there isn't anything to imply that it was unsafe.

I fixed the wording, to mention that a type with !Sync is rejected.

I picked the changeset from @ehuss actually. I think those wordings are better.

RalfJung · 2024-10-09T14:38:24Z

src/const_eval.md

@@ -23,7 +23,8 @@ to be run.
 * [Const parameters].
 * [Paths] to [functions] and [constants].
  Recursively defining constants is not allowed.
-* Paths to [statics]. These are only allowed within the initializer of a static.
+* Paths to immutable [statics].
+    * Reads of [`extern` statics] are not allowed.


Reads from and writes to static mut and static with interior mutability are also not allowed.

And then there are restrictions on references that escape into the final value of the const/static. More precisely, this is about expressions that have been subject to lifetime extension in the top-level scope of a const/static initializer. Those references must also be of type &T and point to a value without an UnsafeCell.

And finally, specifically for const there also can't be any references to anything mutable in the final value.

Hm, I'm trying to unpack what you are saying here and align that with the current rules.

Reads from and writes to static mut …

Isn't this implied by the fact that you are not allowed to refer to static mut at all by the rule that says paths only to immutable statics are allowed?

Reads from and writes to [..] static with interior mutability are also not allowed.

Thanks, I have added that.

And then there are restrictions on references that escape into the final value of the const/static.

Isn't this specified in the later rule that limits borrows of UnsafeCell that are transient? (That was my reading of it, and why I didn't say it explicitly.)

And finally, specifically for const there also can't be any references to anything mutable in the final value.

Thanks, I have added that to the constant-items chapter.

I actually have found the points mentioned down in the list here, in a bullet point starting with All forms of [borrow]s, including raw borrows, with one limitation .... I think we have it covered.

Isn't this implied by the fact that you are not allowed to refer to static mut at all by the rule that says paths only to immutable statics are allowed?

That's not correct, referring to static mut is permitted.
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=7519fded08041a618e0b57c710ab6c25

Isn't this specified in the later rule that limits borrows of UnsafeCell that are transient? (That was my reading of it, and why I didn't say it explicitly.)

Ah right, I forgot that those are already documented.

That's not correct, referring to static mut is permitted.

OK, then I go back to my comment earlier about why the word "immutable" is being added here.

I would think this PR shouldn't add the word immutable, and the edit @dingxiangfei2009 just added about not being allowed to read or write from static mut should cover everything?

(Because as written now, it says you can only do paths to immutable statics, but that does not seem to be true based on the playground above.)

Yeah you are right, immutable should not be mentioned here.

ehuss

I think this should be the last edit, do you agree?

ehuss · 2024-10-10T01:48:24Z

src/const_eval.md

@@ -23,7 +23,10 @@ to be run.
 * [Const parameters].
 * [Paths] to [functions] and [constants].
  Recursively defining constants is not allowed.
-* Paths to [statics]. These are only allowed within the initializer of a static.
+* Paths to immutable [statics] with these exception with these restrictions.


Suggested change

* Paths to immutable [statics] with these exception with these restrictions.

* Paths to [statics] with the following restrictions:

RalfJung · 2024-10-10T06:02:02Z

src/const_eval.md

+* Paths to immutable [statics] with these exception with these restrictions.
+    * Reads out of and writes into [`extern` statics] are not allowed.
+    * Reads out of and writes into either a `static` with data equipped with interior mutability,
+      or a whole or parts of `static mut`, are not allowed.


I am confused by the wording here. Why does static mut emphasize this "whole or part of", but interior mutable static does not? The two are treated exactly the same so they should also be described the same.

The actual underlying check is simply "is this global mutable memory -- if yes, reject read", and "if this memory global -- if yes, reject write".

Is this code accepted?

static FOO: (u8, UnsafeCell<u8>) = (0, UnsafeCell::new(1)); const BAR: u8 = FOO.0;

Edit: Checked and indeed it is not. So yeah, the text shouldn't differ in wording between the two.

traviscross · 2024-10-22T21:22:18Z

@rustbot author

We reviewed this in the call today. This still needs the edits about to cover the case of accesses to mutable statics being allowed.

ehuss · 2024-10-22T21:24:07Z

src/const_eval.md

@@ -23,7 +23,10 @@ to be run.
 * [Const parameters].
 * [Paths] to [functions] and [constants].
  Recursively defining constants is not allowed.
-* Paths to [statics]. These are only allowed within the initializer of a static.
+* Paths to immutable [statics] with these restrictions and observations.


I think this might still need to be updated, since it allows static mut.

Suggested change

* Paths to immutable [statics] with these restrictions and observations.

* Paths to [statics] with these restrictions and observations:

dingxiangfei2009 · 2024-10-23T18:47:02Z

@rustbot ready

Rebased with merge conflict resolutions
Clarify the accepted use of mutable static items.

ehuss · 2024-10-25T15:01:45Z

@RalfJung How do you feel about the final wording here?

RalfJung · 2024-10-25T17:53:59Z

src/const_eval.md

@@ -42,7 +42,10 @@ r[const-eval.const-expr.path-item]
  Recursively defining constants is not allowed.

 r[const-eval.const-expr.path-static]
-* Paths to [statics]. These are only allowed within the initializer of a static.
+* Paths to [statics] with these restrictions and observations.
+    * In particular, reads and writes to any `static`, `static mut` or [`extern` statics] is not allowed.


Reads from immutable statics are allowed.

RalfJung · 2024-10-25T17:55:57Z

src/const_eval.md

+    * Immutable borrows and pointers into immutable part of a `static` are allowed and observes the same restriction
+      on all other forms of [borrow]s as mentioned below.


This doesn't quite parse for me. I'm also not sure what the point of this bullet is -- is there any reason to not just entirely remove it?

traviscross · 2024-11-05T23:07:20Z

src/const_eval.md

@@ -42,7 +42,8 @@ r[const-eval.const-expr.path-item]
  Recursively defining constants is not allowed.

 r[const-eval.const-expr.path-static]
-* Paths to [statics]. These are only allowed within the initializer of a static.
+* Paths to [statics] with these restrictions and observations.
+  * In particular, reads and writes to any `static mut` or [`extern` statics] is not allowed.


So over in #1657, there is proposed language:

Static initializers may refer to and even read from other statics.
When reading from mutable statics, they read the initial value of that static.

The language in this PR seems contradictory to the language in that one, no? Or is there a subtle distinction we're making? Do we need some carve-out here?

(We talked this through on the lang-docs call and couldn't immediately work it out.)

Yeah this already works on stable
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=59b79563db4fe5d5df26ab3f27cd4f1c

@RalfJung Can you write down exactly what we should say here? It would be helpful since we don't know exactly what the rules are. From looking at the implementation, I'm guessing, is it the CanAccessMutGlobal setting, which appears to be set only when in a static initializer? Does this need to say that you cannot read from static mut unless inside a static initializer, and that you can never write to a static mut, and that reading and writing extern statics always disallowed?

Yes:

reads from mutable statics (static mut, and interior mutable static) are forbidden except when evaluating the initializer expression of a static/static mut (so to be clear, the read can be syntactically inside a const fn or not, what matters is the const context, i.e. whether this is computing the initial value of a static or not)

writes to mutable statics are forbidden everywhere

reads from and writes to extern static are forbidden everywhere

ehuss added the S-waiting-on-stabilization Waiting for a stabilization PR to be merged in the main Rust repository label Sep 11, 2024

dingxiangfei2009 changed the title ~~const expression can borrow static items~~ const expression can borrow static items Sep 11, 2024

ehuss reviewed Sep 11, 2024

View reviewed changes

dingxiangfei2009 force-pushed the const-ref-to-static branch 2 times, most recently from 3d0233b to 75faa87 Compare September 11, 2024 17:32

traviscross mentioned this pull request Aug 28, 2024

Tracking Issue for const_refs_to_static rust-lang/rust#119618

Open

6 tasks

ehuss mentioned this pull request Sep 17, 2024

Places based on misaligned pointers: also mention 'static's as a possible base for place projections #1606

Merged

RalfJung mentioned this pull request Sep 21, 2024

Stabilize const_refs_to_static rust-lang/rust#129759

Merged

RalfJung reviewed Sep 21, 2024

View reviewed changes

rustbot added the S-waiting-on-review Status: The marked PR is awaiting review from the PR author. label Sep 22, 2024

ehuss reviewed Sep 28, 2024

View reviewed changes

src/const_eval.md Outdated Show resolved Hide resolved

src/const_eval.md Outdated Show resolved Hide resolved

src/const_eval.md Outdated Show resolved Hide resolved

RalfJung reviewed Sep 28, 2024

View reviewed changes

src/const_eval.md Outdated Show resolved Hide resolved

dingxiangfei2009 requested a review from ehuss October 1, 2024 21:29

dingxiangfei2009 force-pushed the const-ref-to-static branch from a2dde9c to 8f8cf46 Compare October 1, 2024 21:30

ehuss force-pushed the const-ref-to-static branch from 8f8cf46 to 97abd04 Compare October 9, 2024 14:17

ehuss approved these changes Oct 9, 2024

View reviewed changes

RalfJung reviewed Oct 9, 2024

View reviewed changes

ehuss reviewed Oct 10, 2024

View reviewed changes

RalfJung reviewed Oct 10, 2024

View reviewed changes

dingxiangfei2009 force-pushed the const-ref-to-static branch from 67f4754 to e8c43a6 Compare October 12, 2024 16:37

traviscross removed the S-waiting-on-stabilization Waiting for a stabilization PR to be merged in the main Rust repository label Oct 22, 2024

rustbot added S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. and removed S-waiting-on-review Status: The marked PR is awaiting review from the PR author. labels Oct 22, 2024

ehuss reviewed Oct 22, 2024

View reviewed changes

dingxiangfei2009 force-pushed the const-ref-to-static branch from 36c84b0 to 86e6f2e Compare October 23, 2024 18:46

rustbot added S-waiting-on-review Status: The marked PR is awaiting review from the PR author. and removed S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. labels Oct 23, 2024

RalfJung reviewed Oct 25, 2024

View reviewed changes

dingxiangfei2009 added 2 commits November 1, 2024 16:38

const expression can borrow static items

dec67c2

apply suggestions

4a6ac9c

dingxiangfei2009 force-pushed the const-ref-to-static branch from 51f2499 to 4a6ac9c Compare November 1, 2024 08:38

traviscross reviewed Nov 5, 2024

View reviewed changes

nikomatsakis mentioned this pull request Nov 6, 2024

Resolve the biggest blockers to Linux building on stable Rust rust-lang/rust-project-goals#116

Open

40 tasks

	* Paths to immutable [statics] with these exception with these restrictions.
	* Paths to [statics] with the following restrictions:

	* Paths to immutable [statics] with these restrictions and observations.
	* Paths to [statics] with these restrictions and observations:

		* Immutable borrows and pointers into immutable part of a `static` are allowed and observes the same restriction
		on all other forms of [borrow]s as mentioned below.

const expression can borrow static items #1610

Are you sure you want to change the base?

const expression can borrow static items #1610

Conversation

dingxiangfei2009 commented Sep 11, 2024 • edited Loading

ehuss left a comment

Choose a reason for hiding this comment

dingxiangfei2009 commented Sep 11, 2024

traviscross commented Sep 17, 2024

traviscross commented Sep 17, 2024

traviscross commented Sep 17, 2024 • edited Loading

RalfJung commented Sep 21, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RalfJung commented Sep 21, 2024 • edited Loading

RalfJung commented Sep 22, 2024

dingxiangfei2009 commented Sep 22, 2024 • edited Loading

ehuss left a comment

Choose a reason for hiding this comment

dingxiangfei2009 commented Oct 1, 2024

ehuss commented Oct 9, 2024

ehuss left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RalfJung Oct 9, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ehuss left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chorman0773 Oct 12, 2024 • edited Loading

Choose a reason for hiding this comment

traviscross commented Oct 22, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dingxiangfei2009 commented Oct 23, 2024

ehuss commented Oct 25, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

traviscross Nov 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RalfJung Nov 6, 2024 • edited Loading

Choose a reason for hiding this comment

`const` expression can borrow static items #1610

`const` expression can borrow static items #1610

dingxiangfei2009 commented Sep 11, 2024 •

edited

Loading

traviscross commented Sep 17, 2024 •

edited

Loading

RalfJung commented Sep 21, 2024 •

edited

Loading

RalfJung commented Sep 21, 2024 •

edited

Loading

dingxiangfei2009 commented Sep 22, 2024 •

edited

Loading

RalfJung Oct 9, 2024 •

edited

Loading

chorman0773 Oct 12, 2024 •

edited

Loading

traviscross Nov 5, 2024 •

edited

Loading

RalfJung Nov 6, 2024 •

edited

Loading