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

rustc: Stabilize the proc_macro feature #52081

Merged
merged 1 commit into from
Jul 16, 2018

Conversation

alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Jul 5, 2018

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. 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.

@rust-highfive
Copy link
Collaborator

r? @aturon

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

@rust-highfive
Copy link
Collaborator

warning Warning warning

  • These commits modify submodules.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 5, 2018
@alexcrichton
Copy link
Member Author

r? @nikomatsakis

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")]
Copy link
Contributor

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.

Copy link
Member Author

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")]
Copy link
Contributor

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.)

Copy link
Member Author

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.

@petrochenkov
Copy link
Contributor

The custom_attribute feature no longer works as unknown attibutes are looked up as macros.

Oh man, this is going to be painful.

@petrochenkov
Copy link
Contributor

petrochenkov commented Jul 5, 2018

I don't see much use in landing this PR before stabilizing use_extern_macros and completing #51952, but it's good to have a PR open for some publicity.

I plan to fix tool attributes in the next few weeks, so poor users of #[rustfmt_skip] could migrate to #[rustfmt::skip] if custom attributes are not fixed either.

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.

@alexcrichton
Copy link
Member Author

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.

@SimonSapin
Copy link
Contributor

The custom_attribute feature no longer works as unknown attibutes are looked up as macros.

Oh man, this is going to be painful.

Does this also break rustc_plugin::Registry::register_attribute in #[plugin_registrar]? Servo still has a lint plugin with (unfortunately) no clear upgrade path.

@eddyb
Copy link
Member

eddyb commented Jul 6, 2018

FWIW, I have mentioned before that if the unrooted_must_root_lint analysis is "close enough" to being sound, it should naturally be replaceable with a trait-based system that's partially implemented inside the compiler itself, with most of the logic being in impls/derives in Servo crates.

@SimonSapin
Copy link
Contributor

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

@alexcrichton
Copy link
Member Author

@SimonSapin yes it'd break that because those attributes aren't hooked into the normal resolver. You can rename them with a rustc_ prefix, though, and it should continue working. All attributes with a rustc_ prefix are gated and skip the resolver.

@alexcrichton
Copy link
Member Author

I think @nikomatsakis is out this week, so...

r? @nrc

@rust-highfive rust-highfive assigned nrc and unassigned nikomatsakis and petrochenkov Jul 9, 2018
@alercah
Copy link
Contributor

alercah commented Jul 10, 2018

I have a major reservation about stabilizing that I brought up in the tracking issue.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 16, 2018
@bors
Copy link
Contributor

bors commented Jul 16, 2018

⌛ Testing commit 65f3007 with merge 2750fc6...

@bors bors mentioned this pull request Jul 16, 2018
@kennytm
Copy link
Member

kennytm commented Jul 16, 2018

@bors retry

GitHub outage causing the CIs not seeing the auto branch got updated.

@bors
Copy link
Contributor

bors commented Jul 16, 2018

⌛ Testing commit 65f3007 with merge 1ecf692...

bors added a commit that referenced this pull request Jul 16, 2018
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
@bors
Copy link
Contributor

bors commented Jul 16, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: petrochenkov
Pushing 1ecf692 to master...

@bors bors merged commit 65f3007 into rust-lang:master Jul 16, 2018
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #52081!

Tested on commit 1ecf692.
Direct link to PR: #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-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Jul 16, 2018
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).
Manishearth added a commit to rust-lang/rust-clippy that referenced this pull request Jul 16, 2018
rust-lang/rust#52081 stabilized proc macros, but
quote is still unstable, so you need to explicitly enable that feature.
Manishearth added a commit to Manishearth/rust that referenced this pull request Jul 16, 2018
Fixes test failures caused by rust-lang#52081
@Manishearth Manishearth mentioned this pull request Jul 16, 2018
bors added a commit that referenced this pull request Jul 17, 2018
Update clippy

Fixes test failures caused by #52081
@alexcrichton alexcrichton added this to the Rust 2018 Preview 2 milestone Jul 17, 2018
Arnavion pushed a commit to Arnavion/fac-rs that referenced this pull request Jul 17, 2018
rust-lang/rust#52081 updated the name of the main
feature required for proc-macro-related sub features.
@alexcrichton alexcrichton deleted the proc-macro-stable branch July 18, 2018 14:50
flip1995 pushed a commit to flip1995/rust-clippy that referenced this pull request May 5, 2020
Fixes test failures caused by rust-lang/rust#52081
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.