-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
rustc: Stabilize the proc_macro
feature
#52081
Conversation
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
cc @petrochenkov, @dtolnay, @nrc |
@@ -13,7 +13,7 @@ use Span; | |||
use rustc_errors as rustc; | |||
|
|||
/// An enum representing a diagnostic level. | |||
#[unstable(feature = "proc_macro", issue = "38356")] | |||
#[unstable(feature = "proc_macro_diagnostic", issue = "38356")] |
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.
What's the point in renaming unstable library features?
This is only breaking all the code using them.
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.
The proc_macro
feature at this point has been used-and-abused I think a bit too much. This PR is, afaik, the main thrust of proc_macro
for stabilization. The renamings here aren't intended to purely break everyone else's code, but rather clearly singify different groupings of features instead of leaving them all in a perpetual singular proc_macro
bucket
@@ -93,13 +93,13 @@ impl !Sync for LexError {} | |||
|
|||
impl TokenStream { | |||
/// Returns an empty `TokenStream` containing no token trees. | |||
#[unstable(feature = "proc_macro", issue = "38356")] | |||
#[stable(feature = "proc_macro_lib2", since = "1.29.0")] |
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.
Are you going to use proc_macro_lib3/4/5/...
for the next portions of stabilized APIs? :)
I used proc_macro_12
in my PR (#50473 (comment)), because it's Macros 1.2.
(OK, it doesn't matter anyway.)
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.
As I'm sure you know, the stable feature name doesn't actually matter. I initially changed these while the other unstable features were still proc_macro
and then ended up later changing the other proc_macro
features to different names. As a result this stuck. It's an arbitrary name.
Oh man, this is going to be painful. |
I don't see much use in landing this PR before stabilizing I plan to fix tool attributes in the next few weeks, so poor users of I think custom attributes could be restored in some form as well, e.g. if some attribute is "definitely unresolved" as a macro, then it can be kept in the source as a custom attribute (still under a feature gate) instead of producing a dummy expansion, like it's done now. |
While true that this PR isn't too useful landing by itself it does need to land eventually for proc-macro stabilization, and this was larger and more thorny than I thought it would be so I wanted to put it up for review and get it in soon to iron out all the CI issues. |
Does this also break |
FWIW, I have mentioned before that if the |
@eddyb Yes, it might be "just" a matter of someone familiar enough with what the lint does and the soundness of GC rooting to come up with a new design and implementing it. In the meantime, a lint is what we have. |
@SimonSapin yes it'd break that because those attributes aren't hooked into the normal resolver. You can rename them with a |
I think @nikomatsakis is out this week, so... r? @nrc |
I have a major reservation about stabilizing that I brought up in the tracking issue. |
@bors retry GitHub outage causing the CIs not seeing the |
rustc: Stabilize the `proc_macro` feature This commit stabilizes some of the `proc_macro` language feature as well as a number of APIs in the `proc_macro` crate as [previously discussed][1]. This means that on stable Rust you can now define custom procedural macros which operate as attributes attached to items or `macro_rules!`-like bang-style invocations. This extends the suite of currently stable procedural macros, custom derives, with custom attributes and custom bang macros. Note though that despite the stabilization in this commit procedural macros are still not usable on stable Rust. To stabilize that we'll need to stabilize at least part of the `use_extern_macros` feature. Currently you can define a procedural macro attribute but you can't import it to call it! A summary of the changes made in this PR (as well as the various consequences) is: * The `proc_macro` language and library features are now stable. * Other APIs not stabilized in the `proc_macro` crate are now named under a different feature, such as `proc_macro_diagnostic` or `proc_macro_span`. * A few checks in resolution for `proc_macro` being enabled have switched over to `use_extern_macros` being enabled. This means that code using `#![feature(proc_macro)]` today will likely need to move to `#![feature(use_extern_macros)]`. It's intended that this PR, once landed, will be followed up with an attempt to stabilize a small slice of `use_extern_macros` just for procedural macros to make this feature 100% usable on stable. [1]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252
☀️ Test successful - status-appveyor, status-travis |
📣 Toolstate changed by #52081! Tested on commit 1ecf692. 💔 clippy-driver on windows: test-pass → test-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra). |
Tested on commit rust-lang/rust@1ecf692. Direct link to PR: <rust-lang/rust#52081> 💔 clippy-driver on windows: test-pass → test-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra). 💔 clippy-driver on linux: test-pass → test-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
rust-lang/rust#52081 stabilized proc macros, but quote is still unstable, so you need to explicitly enable that feature.
Fixes test failures caused by rust-lang#52081
Update clippy Fixes test failures caused by #52081
rust-lang/rust#52081 updated the name of the main feature required for proc-macro-related sub features.
Fixes test failures caused by rust-lang/rust#52081
This commit stabilizes some of the
proc_macro
language feature as well as anumber of APIs in the
proc_macro
crate as previously discussed. Thismeans that on stable Rust you can now define custom procedural macros which
operate as attributes attached to items or
macro_rules!
-like bang-styleinvocations. This extends the suite of currently stable procedural macros,
custom derives, with custom attributes and custom bang macros.
Note though that despite the stabilization in this commit procedural macros are
still not usable on stable Rust. To stabilize that we'll need to stabilize at
least part of the
use_extern_macros
feature. Currently you can define aprocedural macro attribute but you can't import it to call it!
A summary of the changes made in this PR (as well as the various consequences)
is:
proc_macro
language and library features are now stable.proc_macro
crate are now named under adifferent feature, such as
proc_macro_diagnostic
orproc_macro_span
.proc_macro
being enabled have switched overto
use_extern_macros
being enabled. This means that code using#![feature(proc_macro)]
today will likely need to move to#![feature(use_extern_macros)]
.It's intended that this PR, once landed, will be followed up with an attempt to
stabilize a small slice of
use_extern_macros
just for procedural macros tomake this feature 100% usable on stable.