-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
support pub(restricted) in thread_local! #40984
Conversation
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
src/libstd/thread/local.rs
Outdated
// rule 4: handle multiple restricted public declarations | ||
($(#[$attr:meta])* pub $vis:tt static $name:ident: $t:ty = $init:expr) => ( | ||
__thread_local_inner!($(#[$attr])* [pub $vis] $name, $t, $init); | ||
thread_local!($($rest)*); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please note these six rules can be reduced to two if we revive the $x:vis
RFC.
6622a28
to
20a8799
Compare
Github ate my comment, so just to reiterate: this PR is real, but also meant to demonstrate why we need a |
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. |
Labeling waiting on review since rereview might be needed once #41012 is in. |
#41012 has landed. @alexcrichton can you look at this? |
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>
.
|
Ok thanks @durka! |
Actually we can't use |
Seems like you can do it before then with |
20a8799
to
8fffee0
Compare
8fffee0
to
62e69cd
Compare
Hmm, this is odd:
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 |
As the author of #41012, you're probably in the best position to answer that question :) |
Good call :) Can a commit fixing that go in this PR or should I separate it? |
068b960
to
6174d01
Compare
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). |
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 |
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. |
@durka to clarify, did you intend on landing that instantiation in this PR? Or waiting for a fix to the macros from @jseyfried? |
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>
.
|
I'd ideally prefer to wait for |
Are there issues/PRs for the |
I think it is just #26444 (closed WONTFIX) unfortunately. But I could be wrong. |
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 :( |
@durka Could you give an update here? Looks like Travis is still failing -- @jseyfried, did you have a chance to take a look? |
Status quo. |
☔ The latest upstream changes (presumably #42038) made this pull request unmergeable. Please resolve the merge conflicts. |
I'm going to close this for now and post in the |
Fixes rust-lang#24189. Fixes rust-lang#26444. Fixes rust-lang#27832. Fixes rust-lang#34030. Fixes rust-lang#35650. Fixes rust-lang#39964. Fixes the 4th comment in rust-lang#40569. Fixes the issue blocking rust-lang#40984.
…seyfried Only match a fragment specifier the if it starts with certain tokens. When trying to match a fragment specifier, we first predict whether the current token can be matched at all. If it cannot be matched, don't bother to push the Earley item to `bb_eis`. This can fix a lot of issues which otherwise requires full backtracking (#42838). In this PR the prediction treatment is not done for `:item`, `:stmt` and `:tt`, but it could be expanded in the future. Fixes #24189. Fixes #26444. Fixes #27832. Fixes #34030. Fixes #35650. Fixes #39964. Fixes the 4th comment in #40569. Fixes the issue blocking #40984.
Rebased and reopened now that #42913 got merged. |
Looks like you'll need to open a new pull request -- GH is being annoying and not letting this one be reopened. |
Resubmitted as #43185. |
support pub(restricted) in thread_local! (round 2) Resurrected #40984 now that the issue blocking it was fixed. Original description: `pub(restricted)` was stabilized in #40556 so let's go! Here is a [playground](https://play.rust-lang.org/?gist=f55f32f164a6ed18c219fec8f8293b98&version=nightly&backtrace=1). 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.
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.