Tracking issue for `static_recursion`

[aturon]

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

[eefriedman]

See https://github.com/eefriedman/rust/blob/0eea0f6e907ff8c8a25a10004bede7b4621b50aa/src/test/run-pass/static-recursive.rs for an example of what this allows.

[nikomatsakis]

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]

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]

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.

[vberger]

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]

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 notifications@github.com
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).

[vberger]

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]

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

[vberger]

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 ?

[vberger]

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]

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

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

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

• @aturon
• @eddyb
• @nikomatsakis
• @nrc
• @pnkfelix
• @withoutboats

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]

@rfcbot reviewed

[rfcbot]

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

[rfcbot]

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

[rfcbot]

The final comment period is now complete.