support pub(restricted) in thread_local!

[durka]

pub(restricted) was stabilized in #40556 so let's go!

Here is a playground.

I changed the interface of __thread_local_inner!, which is supposedly unstable but this is not checked for macros (#34097 cc @petrochenkov @jseyfried), so this may be an issue.

[rust-highfive]

r? @brson

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

[durka]

Please note these six rules can be reduced to two if we revive the $x:vis RFC.

[durka]

Github ate my comment, so just to reiterate: this PR is real, but also meant to demonstrate why we need a :vis macro matcher.

[alexcrichton]

Discussed at the libs triage meeting the other day, our conclusion was that we should probably wait for #41012 to get merged, which looks like it's going to get merged.

[carols10cents]

Labeling waiting on review since rereview might be needed once #41012 is in.

[arielb1]

#41012 has landed. @alexcrichton can you look at this?

[durka]

I was planning to update or resubmit after updating the macro to use :vis.

…

On Apr 18, 2017 4:42 AM, "Ariel Ben-Yehuda" ***@***.***> wrote: #41012 <#41012> has landed. @alexcrichton <https://github.com/alexcrichton> can you look at this? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#40984 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n4YJClLg37qyNqr0KCeBy6RaDEk0ks5rxHdZgaJpZM4MwWIZ> .

[alexcrichton]

Ok thanks @durka!

[durka]

Actually we can't use :vis until #41012 hits beta, right?

[sfackler]

Seems like you can do it before then with #[cfg(stage0)] and #[cfg(not(stage0))] versions of the macro, right?

[durka]

Hmm, this is odd:

[00:17:04] Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
... snip ...
[00:17:20]    Compiling syntax_pos v0.0.0 (file:///checkout/src/libsyntax_pos)
[00:17:20] error: :vis fragment specifier is experimental and subject to change (see issue #41022)
[00:17:20]  --> <thread_local macros>:2:29
[00:17:20]   |
[00:17:20] 2 | $ ( # [ $ attr : meta ] ) * $ vis : vis static $ name : ident : $ t : ty = $
[00:17:20]   |                             ^^^^^^^^^^^
[00:17:20]   |
[00:17:20]   = help: add #![feature(macro_vis_matcher)] to the crate attributes to enable
[00:17:20] 
[00:17:20] error: :vis fragment specifier is experimental and subject to change (see issue #41022)
[00:17:20]  --> <thread_local macros>:6:29
[00:17:20]   |
[00:17:20] 6 | $ ( # [ $ attr : meta ] ) * $ vis : vis static $ name : ident : $ t : ty = $
[00:17:20]   |                             ^^^^^^^^^^^
[00:17:20]   |
[00:17:20]   = help: add #![feature(macro_vis_matcher)] to the crate attributes to enable

But I did add that attribute. Does it have to be added to crates that invoke the macro as well? That would be a problem. And it should be fine because thread_local! and __thread_local_inner! are marked #[allow_internal_unstable]. Perhaps fragment specifiers are not covered by that?

[alexcrichton]

As the author of #41012, you're probably in the best position to answer that question :)

[durka]

Good call :)

Can a commit fixing that go in this PR or should I separate it?

[jseyfried]

I've reached out to @jseyfried to see if this is fixable or not

I believe this is fixable, but I'm not sure exactly how -- I'll look into it when I get the time (probably a week or two).

[durka]

OK, I did come up with a way to make it shorter, by having the macro munch attributes one at a time until it gets to the visibility specifier:

macro_rules! thread_local {
    // terminate recursion
    (@ [] -> $_x:tt) => {};
    
    // munch one attribute
    (@ [#[$attr:meta] $($rest:tt)*] -> [$(#[$attrs:meta])*]) => {
        thread_local!(@ [$($rest)*] -> [$(#[$attrs])* #[$attr]]);
    };
    
    // finish a static with no trailing semicolon (therefore there are no more)
    (@ [$vis:vis static $name:ident: $typ:ty = $init:expr] -> [$(#[$attrs:meta])*]) => {
        __thread_local_inner!(($(#[$attrs])*) $vis, $name, $typ, $init);
    };
    
    // finish a static with trailing semicolon and continue to parse more
    (@ [$vis:vis static $name:ident: $typ:ty = $init:expr; $($rest:tt)*] -> [$(#[$attrs:meta])*]) => {
        __thread_local_inner!(($(#[$attrs])*) $vis, $name, $typ, $init);
        thread_local!(@ [$($rest)*] -> []);
    };
    
    // public entry point
    ($($t:tt)*) => {
        thread_local!(@ [$($t)*] -> []);
    }
}

This business with the @ "private" rules could be pulled into a separate macro as well (e.g. __thread_local_collector!). If only that trailing semicolon was required, we could remove one more rule, oh well.

[alexcrichton]

Yeah if we do add a macro implementation like that we'd want it to be an internal macro hidden away, but it seems reasonableto have such an implementation.

[alexcrichton]

@durka to clarify, did you intend on landing that instantiation in this PR? Or waiting for a fix to the macros from @jseyfried?

[durka]

Ah sorry this dropped off my radar. I'm happy to land either the version with extra arms (so not actually using :vis in thread_local!, though it would be used in thread_local_inner!) or the muncher version in this PR. The muncher version wouldn't look great in rustdoc (since it would just be $($t:tt)*) but we can solve that with docs. Do you care which way we go?

…

On Thu, May 4, 2017 at 2:25 PM, Alex Crichton ***@***.***> wrote: @durka <https://github.com/durka> to clarify, did you intend on landing that instantiation in this PR? Or waiting for a fix to the macros from @jseyfried <https://github.com/jseyfried>? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40984 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC3n9sPs29up4xTFcSk_a0qxNDldhYLks5r2hgUgaJpZM4MwWIZ> .

[alexcrichton]

I'd ideally prefer to wait for :vis bugs to get fixed (or at least see if they're not fixable) but I also don't have a burning need for this change just yet. If there's some strong motivation I could see us landing this sooner rather than later.

[carols10cents]

I'd ideally prefer to wait for :vis bugs to get fixed (or at least see if they're not fixable)

Are there issues/PRs for the :vis bugs that are blocking this PR that we could link to for status tracking purposes?

[durka]

I think it is just #26444 (closed WONTFIX) unfortunately. But I could be wrong.

[alexcrichton]

This was to a large degree the motivation for #41012, right? If so, it seems a shame if it's actually still difficult to leverage :(

[Mark-Simulacrum]

@durka Could you give an update here? Looks like Travis is still failing -- @jseyfried, did you have a chance to take a look?

[durka]

Status quo.

[bors]

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

[durka]

I'm going to close this for now and post in the :vis tracking issue. I'll resubmit once we decide on an approach, or if someone complains about thread_local! specifically.

[durka]

Rebased and reopened now that #42913 got merged.

[Mark-Simulacrum]

Looks like you'll need to open a new pull request -- GH is being annoying and not letting this one be reopened.

[durka]

Resubmitted as #43185.