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

Tracking issue for static_recursion #29719

Closed
aturon opened this issue Nov 9, 2015 · 17 comments
Closed

Tracking issue for static_recursion #29719

aturon opened this issue Nov 9, 2015 · 17 comments
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@aturon
Copy link
Member

aturon commented Nov 9, 2015

Added in #26630, allows recursive static variables. This issue tracks stabilization.

@aturon aturon added T-lang Relevant to the language team, which will review and decide on the PR/issue. B-unstable Blocker: Implemented in the nightly compiler and unstable. labels Nov 9, 2015
@eefriedman
Copy link
Contributor

@nikomatsakis
Copy link
Contributor

The current implementation seems to be causing a crash in the compiler #29884. It's also (somewhat incidentally) blocking my current PR, since I change the order in which we visit static variables, triggering #29884. :)

@nikomatsakis
Copy link
Contributor

Specifically, when we try to deref a pointer to a static, we must have its initializer available. So we cannot allow arbitrary recursive statics, or at least we need some rather more sophisticated technique to handle this on the LLVM side (like creating intermediate statics).

@eefriedman
Copy link
Contributor

We aren't supposed to allow dereferencing a static inside of another static... it's nonsensical at best. (Our current implementation even allows static mut X: i32 = 1; static C: i32 = unsafe {*&X};.)

Once we correctly honor that restriction, we don't need the initializer.

@elinorbgr
Copy link
Contributor

If I understand correctly, the only blocking point for this feature is dereferencing a pointer to a static in a static, which should actually completely be forbidden? So... no big problem?

If so I'd love to see this feature advancing, I need it for my wayland crates, and there is no workaround, as I must match the rules of the C API I'm binding to.

@nikomatsakis
Copy link
Contributor

I think that is correct, but we do need to fix that bug first or else we
introduce a backwards compat hazard.

On Tue, Feb 16, 2016 at 9:15 AM, Victor Berger [email protected]
wrote:

If I understand correctly, the only blocking point for this feature is
dereferencing a pointer to a static in a static, which should actually
completely be forbidden? So... no big problem?

If so I'd love to see this feature advancing, I need it for my wayland
crates, and there is no workaround, as I must match the rules of the C API
I'm binding to.


Reply to this email directly or view it on GitHub
#29719 (comment).

@elinorbgr
Copy link
Contributor

Coming back at this, as it's been brought up again in my crates.

So, is the fix you are talking about @nikomatsakis just "we should forbid dereferencing/indexing a static in an other static" ?

If so, I might try to work on it, if I find the time to.

@bstrie
Copy link
Contributor

bstrie commented Sep 28, 2016

It looks like the progress on stabilizing this has stalled, so I'll link a recent blog post that mentions this feature in the hopes that it will trigger another round of re-prioritization: http://blog.levans.fr/wayland_rust_v3-en.html

@elinorbgr
Copy link
Contributor

From what I see in #33130 and on the playpen nightly, dereferencing a reference to a static in an other static is now disallowed (and has been for a few months). So... Is there still anything blocking the stabilization of static_recursion ?

@elinorbgr
Copy link
Contributor

I'd really like this to not remain completely stalled, this is absolutely crucial for a proper use of wayland with Rust.

This is all the more frustrating that it appears to not be blocked on anything.

@nikomatsakis
Copy link
Contributor

@vberger re-reading the thread, it appears to be blocked on a bug (#29884). However, that bug claims to be fixed. Let me read a bit more into this.

@nikomatsakis
Copy link
Contributor

@rfcbot fcp merge

This feature (no RFC was ever required) permits statics to refer to other statics. Because statics are not supposed to refer to one another by value, this simply allows one to create interlinked structures. (Is this correct, @eefriedman?) There was at one time a bug in that we failed to prohibit statics from referring to one another by value, but that has since been fixed. This seems like a reasonable feature to stabilize, so I propose we do so.

@rfcbot
Copy link

rfcbot commented Jan 17, 2017

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@withoutboats
Copy link
Contributor

@rfcbot reviewed

jan-hudec added a commit to rust-locale/rust-locale that referenced this issue Jan 30, 2017
Nightly-only until rust-lang/rust#29719 gets
fixed.

TODO: Actually extract the data.
@rfcbot
Copy link

rfcbot commented Feb 1, 2017

🔔 This is now entering its final comment period, as per the review above. 🔔

1 similar comment
@rfcbot
Copy link

rfcbot commented Feb 1, 2017

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Feb 1, 2017
@rfcbot
Copy link

rfcbot commented Feb 11, 2017

The final comment period is now complete.

frewsxcv added a commit to frewsxcv/rust that referenced this issue Feb 23, 2017
eddyb added a commit to eddyb/rust that referenced this issue Feb 25, 2017
eddyb added a commit to eddyb/rust that referenced this issue Feb 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants