Allow and implement recursive static variables. #26630
Conversation
|
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
|
This would be really neat for |
eefriedman
force-pushed
the
recursive-static
branch
from
e0349a3 to
6280c36
Compare
eefriedman
changed the title
|
Updated; should be safe now. Also added an extra commit to remove the restriction on types which can't be instantiated, to allow implementing a static doubly-linked list. |
|
cc @rust-lang/lang, not sure if this is a large enough change to warrant an RFC, it'd probably be nice to have a "static specification" but that may be a bit of a pipe dream. |
|
I don't think it needs an RFC and I think it is a good idea. I do think it probably deserves some eyes on it, so I created an announcement in our internals discourse: https://internals.rust-lang.org/t/heads-up-allowing-recursive-static-variables/2309 |
|
Are nonsensical cycles like Also, perhaps the tests that are deleted in this PR should instead just be moved to |
|
@P1start The initializer for a static item can't read the contents of any static item, so Not sure the tests are particularly useful, but I guess I could move them. |
eefriedman
force-pushed
the
recursive-static
branch
from
6280c36 to
a0055ef
Compare
|
Tests re-added. |
|
Surely this should at least be feature gated? |
|
(that is, I can understand side-stepping the RFC process, though I'm not 100% sure I agree with doing so, even for a feature like this. But with or without an RFC, it still seems prudent to feature-gate new functionality in the language, just so that we can kick the tires on it in nightly without worry about whether it could inadvertantly leak out into the other distribution channels.) |
eefriedman
force-pushed
the
recursive-static
branch
from
a0055ef to
3d8cae2
Compare
|
|
|
AFAICT you had to revert the removal of |
|
☔ The latest upstream changes (presumably #26747) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@eefriedman sorry I have not reviewed this yet. I hope I will get to it this week but I am not sure if I will. |
|
@pnkfelix Ping. |
|
@eefriedman sorry for the delay |
| @@ -131,6 +128,11 @@ pub struct LocalCrateContext<'tcx> { | |||
| /// Cache of closure wrappers for bare fn's. | |||
| closure_bare_wrapper_cache: RefCell<FnvHashMap<ValueRef, ValueRef>>, | |||
|
|
|||
| /// List of globals for static variables which need to be RAUW'ed when | |||
There was a problem hiding this comment.
nit: as far as I can tell the acronym "RAUW" does not occur elsewhere in our code.
So, please expand this occurrence and then include the acronym afterwards in parentheses, effectively defining the acronym. Like so: "static variables which need to be passed through the LLVM Replace All Uses With (RAUW) functionality"
|
okay looks good as far as my knowledge of LLVM goes. r=me after next rebase (and hopefully the noted nit is addressed). |
There isn't any particularly good reason for this restriction, so just get rid of it, and fix trans to handle this case.
The borrow checker doesn't allow constructing such a type at runtime using safe code, but there isn't any reason to ban them in the type checker. Included in this commit is an example of a neat static doubly-linked list. Feature-gated under the static_recursion gate to be on the safe side, but there are unlikely to be any reasons this shouldn't be turned on by default.
eefriedman
force-pushed
the
recursive-static
branch
from
3d8cae2 to
0eea0f6
Compare
|
@pnkfelix Rebased. |
|
@bors r+ |
|
📌 Commit 0eea0f6 has been approved by |
***Edit: Fixed now.*** I'm pretty sure the way I'm using LLVMReplaceAllUsesWith here is unsafe... but before I figure out how to fix that, I'd like a reality-check: is this actually useful?
brson
added
the
relnotes
_Edit: Fixed now._ I'm pretty sure the way I'm using LLVMReplaceAllUsesWith here is
unsafe... but before I figure out how to fix that, I'd like a
reality-check: is this actually useful?