Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow and implement recursive static variables. #26630

Merged
merged 3 commits into from Jul 25, 2015

Conversation

Projects
None yet
9 participants
@eefriedman
Copy link
Contributor

eefriedman commented Jun 28, 2015

_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?

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Jun 28, 2015

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

@eddyb

This comment has been minimized.

Copy link
Member

eddyb commented Jun 28, 2015

This would be really neat for &'static cycles, e.g. a safe doubly linked static list.

@eefriedman eefriedman force-pushed the eefriedman:recursive-static branch from e0349a3 to 6280c36 Jun 28, 2015

@eefriedman eefriedman changed the title [WIP] Allow and implement recursive static variables. Allow and implement recursive static variables. Jun 28, 2015

@eefriedman

This comment has been minimized.

Copy link
Contributor Author

eefriedman commented Jun 28, 2015

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.

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Jun 28, 2015

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.

@nrc

This comment has been minimized.

Copy link
Member

nrc commented Jun 29, 2015

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

@P1start

This comment has been minimized.

Copy link
Contributor

P1start commented Jun 30, 2015

Are nonsensical cycles like static FOO: T = FOO; and static FOO: T = BAR; static BAR: T = FOO; still disallowed by this PR?

Also, perhaps the tests that are deleted in this PR should instead just be moved to run-pass.

@eefriedman

This comment has been minimized.

Copy link
Contributor Author

eefriedman commented Jun 30, 2015

@P1start The initializer for a static item can't read the contents of any static item, so static FOO: T = FOO; is still rejected.

Not sure the tests are particularly useful, but I guess I could move them.

@eefriedman eefriedman force-pushed the eefriedman:recursive-static branch from 6280c36 to a0055ef Jul 2, 2015

@eefriedman

This comment has been minimized.

Copy link
Contributor Author

eefriedman commented Jul 2, 2015

Tests re-added.

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Jul 2, 2015

Surely this should at least be feature gated?

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Jul 2, 2015

(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 eefriedman force-pushed the eefriedman:recursive-static branch from a0055ef to 3d8cae2 Jul 3, 2015

@eefriedman

This comment has been minimized.

Copy link
Contributor Author

eefriedman commented Jul 3, 2015

static_recursion feature gate added. I strongly doubt there will be any issues in practice, but better to be on the safe side, I guess.

@eddyb

This comment has been minimized.

Copy link
Member

eddyb commented Jul 3, 2015

AFAICT you had to revert the removal of is_instantiable. I guess it will go away once the feature gate is lifted.

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jul 7, 2015

☔️ The latest upstream changes (presumably #26747) made this pull request unmergeable. Please resolve the merge conflicts.

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Jul 8, 2015

@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.

@eefriedman

This comment has been minimized.

Copy link
Contributor Author

eefriedman commented Jul 24, 2015

@pnkfelix Ping.

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Jul 24, 2015

@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

This comment has been minimized.

@pnkfelix

pnkfelix Jul 24, 2015

Member

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"

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Jul 24, 2015

okay looks good as far as my knowledge of LLVM goes.

r=me after next rebase (and hopefully the noted nit is addressed).

eefriedman added some commits Jun 28, 2015

Allow recursive static variables.
There isn't any particularly good reason for this restriction, so just
get rid of it, and fix trans to handle this case.
Allow writing types which "can't" be instantiated.
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 eefriedman force-pushed the eefriedman:recursive-static branch from 3d8cae2 to 0eea0f6 Jul 25, 2015

@eefriedman

This comment has been minimized.

Copy link
Contributor Author

eefriedman commented Jul 25, 2015

@pnkfelix Rebased.

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Jul 25, 2015

@bors r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jul 25, 2015

📌 Commit 0eea0f6 has been approved by pnkfelix

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Jul 25, 2015

⌛️ Testing commit 0eea0f6 with merge e333e6a...

bors added a commit that referenced this pull request Jul 25, 2015

Auto merge of #26630 - eefriedman:recursive-static, r=pnkfelix
***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?

@bors bors merged commit 0eea0f6 into rust-lang:master Jul 25, 2015

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@brson brson added the relnotes label Jul 27, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.