reference
reference copied to clipboard
`const` expression can borrow static items
Tracked by rust-lang/rust#119618
Blocked on rust-lang/rust#129759
Stabilization report: https://github.com/rust-lang/rust/issues/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 I updated the wording to include simply "use of statics".
I have updated static-items page as well with tweaks on wording.
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.
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.
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 https://github.com/rust-lang/rust/issues/128183.
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.
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.
I opened https://github.com/rust-lang/reference/pull/1624 to fix the part about "address of a constant".
@rustbot ready
- I sieved through the document and I believe these are the places where use of
staticis mentioned. - I managed to add some sort of document about
Freezewithout mentioning it, given that it is not stabilized. In case rust-lang/rfcs#3633 lands and stabilization of the trait actually happens, I will follow up with the edits.
@ehuss I added a section on extern { static }.
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.
@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.
@rustbot ready
- Rebased with merge conflict resolutions
- Clarify the accepted use of mutable
staticitems.
@RalfJung How do you feel about the final wording here?
Ah right they all got fixed, great. Thanks all!