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

proc_macro API: Expose `macro_rules` hygiene #64690

Merged
merged 1 commit into from Oct 4, 2019

Conversation

@petrochenkov
Copy link
Contributor

commented Sep 22, 2019

Proc macros do not have direct access to our oldest and most stable hygiene kind - macro_rules hygiene.

To emulate it macro authors have to go through two steps - first generate a temporary macro_rules item (using a derive, at least until #64035 is merged), then generate a macro call to that item. Popular crates like proc_macro_hack use this trick to generate hygienic identifiers from proc macros.

I'd say that these workarounds with nested macro definitions have more chances to hit some corner cases in our hygiene system, in which we don't have full confidence.
So, let's provide a direct access to macro_rules hygiene instead.

This PR does that by adding a new method Span::mixed_site (bikeshedding is welcome) in addition to existing Span::call_site (stable) and Span::def_site (unstable).
Identifiers with this span resolve at def-site in for local variables, labels and $crate, and resolve at call-site for everything else, i.e. exactly like identifiers produced by macro_rules.

This API addition opens the way to stabilizing proc macros in expression positions (#54727), for which use of call-site hygiene or workarounds with temporary items would be quite unfortunate.
(macro_rules expanded in expression position, on the other hand, are stable since 1.0 and widely used.)

r? @dtolnay @alexcrichton

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Sep 23, 2019

Seems plausible to me! @dtolnay would know much more about the need for this than I though

src/libproc_macro/lib.rs Outdated Show resolved Hide resolved
@SergioBenitez

This comment has been minimized.

Copy link
Contributor

commented Sep 24, 2019

This API addition opens the way to stabilizing proc macros in expression positions (#54727), for which use of call-site hygiene or workarounds with temporary items would be quite unfortunate.

How does this PR do that? Is the plan to enjoin mixed-site hygiene on proc-macros that expand to expressions?

@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

commented Sep 24, 2019

Is the plan to enjoin mixed-site hygiene on proc-macros that expand to expressions?

Exactly.

@Alexendoo

This comment has been minimized.

Copy link
Member

commented Oct 2, 2019

Ping from triage, any updates? @dtolnay

Copy link
Member

left a comment

I like this.

What would be your recommendation to macro authors on when this is the right span to use? Just everywhere as a default span in any expression-position macro?

@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

commented Oct 2, 2019

I'd say everywhere until Span::def_site() arrives (unless you specifically need an unhygienic local or something, but that's an exceptional case).
Partial hygiene is still a better default than no hygiene at all, there's a reason why macro_rules use it.

@dtolnay

This comment has been minimized.

Copy link
Member

commented Oct 2, 2019

I will try to test whether changing the default span of quote! from call_site to mixed_site on sufficiently new compilers can possibly break anything that's currently stable. The alternative would be adding a macro like quote_expr! that is shorthand for quote_spanned!(Span::mixed_site()=>...).

LGTM after the documentation that Sergio pointed out is fixed.

@dtolnay
dtolnay approved these changes Oct 2, 2019
@Centril

This comment has been minimized.

Copy link
Member

commented Oct 3, 2019

@petrochenkov petrochenkov force-pushed the petrochenkov:mixed branch from 02c0ec1 to d1310dc Oct 3, 2019
@petrochenkov

This comment has been minimized.

Copy link
Contributor Author

commented Oct 3, 2019

@bors r=dtolnay

@bors

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2019

📌 Commit d1310dc has been approved by dtolnay

Centril added a commit to Centril/rust that referenced this pull request Oct 3, 2019
proc_macro API: Expose `macro_rules` hygiene

Proc macros do not have direct access to our oldest and most stable hygiene kind - `macro_rules` hygiene.

To emulate it macro authors have to go through two steps - first generate a temporary `macro_rules` item (using a derive, at least until rust-lang#64035 is merged), then generate a macro call to that item. Popular crates like [proc_macro_hack](https://crates.io/crates/proc-macro-hack) use this trick to generate hygienic identifiers from proc macros.

I'd say that these workarounds with nested macro definitions have more chances to hit some corner cases in our hygiene system, in which we don't have full confidence.
So, let's provide a direct access to `macro_rules` hygiene instead.

This PR does that by adding a new method `Span::mixed_site` (bikeshedding is welcome) in addition to existing `Span::call_site` (stable) and `Span::def_site` (unstable).
Identifiers with this span resolve at def-site in for local variables, labels and `$crate`, and resolve at call-site for everything else, i.e. exactly like identifiers produced by `macro_rules`.

This API addition opens the way to stabilizing proc macros in expression positions (rust-lang#54727), for which use of call-site hygiene or workarounds with temporary items would be quite unfortunate.
(`macro_rules` expanded in expression position, on the other hand, are stable since 1.0 and widely used.)

r? @dtolnay @alexcrichton
@Centril Centril referenced this pull request Oct 3, 2019
bors added a commit that referenced this pull request Oct 3, 2019
Rollup of 5 pull requests

Successful merges:

 - #64690 (proc_macro API: Expose `macro_rules` hygiene)
 - #64749 (Fix most remaining Polonius test differences)
 - #64938 (Avoid ICE on ReFree region on where clause)
 - #64999 (extract expected return type for async fn generators)
 - #65037 (`#[track_caller]` feature gate (RFC 2091))

Failed merges:

r? @ghost
@bors

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2019

⌛️ Testing commit d1310dc with merge 8d7c6e3...

bors added a commit that referenced this pull request Oct 3, 2019
proc_macro API: Expose `macro_rules` hygiene

Proc macros do not have direct access to our oldest and most stable hygiene kind - `macro_rules` hygiene.

To emulate it macro authors have to go through two steps - first generate a temporary `macro_rules` item (using a derive, at least until #64035 is merged), then generate a macro call to that item. Popular crates like [proc_macro_hack](https://crates.io/crates/proc-macro-hack) use this trick to generate hygienic identifiers from proc macros.

I'd say that these workarounds with nested macro definitions have more chances to hit some corner cases in our hygiene system, in which we don't have full confidence.
So, let's provide a direct access to `macro_rules` hygiene instead.

This PR does that by adding a new method `Span::mixed_site` (bikeshedding is welcome) in addition to existing `Span::call_site` (stable) and `Span::def_site` (unstable).
Identifiers with this span resolve at def-site in for local variables, labels and `$crate`, and resolve at call-site for everything else, i.e. exactly like identifiers produced by `macro_rules`.

This API addition opens the way to stabilizing proc macros in expression positions (#54727), for which use of call-site hygiene or workarounds with temporary items would be quite unfortunate.
(`macro_rules` expanded in expression position, on the other hand, are stable since 1.0 and widely used.)

r? @dtolnay @alexcrichton
@Centril

This comment has been minimized.

Copy link
Member

commented Oct 3, 2019

@bors retry -- prioritizing other PRs to see which one caused failure in #65053 (comment) :(

Centril added a commit to Centril/rust that referenced this pull request Oct 3, 2019
proc_macro API: Expose `macro_rules` hygiene

Proc macros do not have direct access to our oldest and most stable hygiene kind - `macro_rules` hygiene.

To emulate it macro authors have to go through two steps - first generate a temporary `macro_rules` item (using a derive, at least until rust-lang#64035 is merged), then generate a macro call to that item. Popular crates like [proc_macro_hack](https://crates.io/crates/proc-macro-hack) use this trick to generate hygienic identifiers from proc macros.

I'd say that these workarounds with nested macro definitions have more chances to hit some corner cases in our hygiene system, in which we don't have full confidence.
So, let's provide a direct access to `macro_rules` hygiene instead.

This PR does that by adding a new method `Span::mixed_site` (bikeshedding is welcome) in addition to existing `Span::call_site` (stable) and `Span::def_site` (unstable).
Identifiers with this span resolve at def-site in for local variables, labels and `$crate`, and resolve at call-site for everything else, i.e. exactly like identifiers produced by `macro_rules`.

This API addition opens the way to stabilizing proc macros in expression positions (rust-lang#54727), for which use of call-site hygiene or workarounds with temporary items would be quite unfortunate.
(`macro_rules` expanded in expression position, on the other hand, are stable since 1.0 and widely used.)

r? @dtolnay @alexcrichton
bors added a commit that referenced this pull request Oct 3, 2019
Rollup of 11 pull requests

Successful merges:

 - #61879 (Stabilize todo macro)
 - #64675 (Deprecate `#![plugin]` & `#[plugin_registrar]`)
 - #64690 (proc_macro API: Expose `macro_rules` hygiene)
 - #64706 (add regression test for #60218)
 - #64741 (Prevent rustdoc feature doctests)
 - #64842 (Disallow Self in type param defaults of ADTs)
 - #65004 (Replace mentions of IRC with Discord)
 - #65020 (Always mark rust and rust-call abi's as unwind)
 - #65055 (Add long error explanation for E0556)
 - #65056 (Make visit projection iterative)
 - #65057 (typo: fix typo in E0392)

Failed merges:

r? @ghost
tmandry added a commit to tmandry/rust that referenced this pull request Oct 3, 2019
proc_macro API: Expose `macro_rules` hygiene

Proc macros do not have direct access to our oldest and most stable hygiene kind - `macro_rules` hygiene.

To emulate it macro authors have to go through two steps - first generate a temporary `macro_rules` item (using a derive, at least until rust-lang#64035 is merged), then generate a macro call to that item. Popular crates like [proc_macro_hack](https://crates.io/crates/proc-macro-hack) use this trick to generate hygienic identifiers from proc macros.

I'd say that these workarounds with nested macro definitions have more chances to hit some corner cases in our hygiene system, in which we don't have full confidence.
So, let's provide a direct access to `macro_rules` hygiene instead.

This PR does that by adding a new method `Span::mixed_site` (bikeshedding is welcome) in addition to existing `Span::call_site` (stable) and `Span::def_site` (unstable).
Identifiers with this span resolve at def-site in for local variables, labels and `$crate`, and resolve at call-site for everything else, i.e. exactly like identifiers produced by `macro_rules`.

This API addition opens the way to stabilizing proc macros in expression positions (rust-lang#54727), for which use of call-site hygiene or workarounds with temporary items would be quite unfortunate.
(`macro_rules` expanded in expression position, on the other hand, are stable since 1.0 and widely used.)

r? @dtolnay @alexcrichton
bors added a commit that referenced this pull request Oct 3, 2019
Rollup of 12 pull requests

Successful merges:

 - #61879 (Stabilize todo macro)
 - #64675 (Deprecate `#![plugin]` & `#[plugin_registrar]`)
 - #64690 (proc_macro API: Expose `macro_rules` hygiene)
 - #64706 (add regression test for #60218)
 - #64741 (Prevent rustdoc feature doctests)
 - #64842 (Disallow Self in type param defaults of ADTs)
 - #65004 (Replace mentions of IRC with Discord)
 - #65018 (Set RUST_BACKTRACE=0 in tests that include a backtrace in stderr)
 - #65037 (`#[track_caller]` feature gate (RFC 2091))
 - #65055 (Add long error explanation for E0556)
 - #65056 (Make visit projection iterative)
 - #65057 (typo: fix typo in E0392)

Failed merges:

r? @ghost
tmandry added a commit to tmandry/rust that referenced this pull request Oct 3, 2019
proc_macro API: Expose `macro_rules` hygiene

Proc macros do not have direct access to our oldest and most stable hygiene kind - `macro_rules` hygiene.

To emulate it macro authors have to go through two steps - first generate a temporary `macro_rules` item (using a derive, at least until rust-lang#64035 is merged), then generate a macro call to that item. Popular crates like [proc_macro_hack](https://crates.io/crates/proc-macro-hack) use this trick to generate hygienic identifiers from proc macros.

I'd say that these workarounds with nested macro definitions have more chances to hit some corner cases in our hygiene system, in which we don't have full confidence.
So, let's provide a direct access to `macro_rules` hygiene instead.

This PR does that by adding a new method `Span::mixed_site` (bikeshedding is welcome) in addition to existing `Span::call_site` (stable) and `Span::def_site` (unstable).
Identifiers with this span resolve at def-site in for local variables, labels and `$crate`, and resolve at call-site for everything else, i.e. exactly like identifiers produced by `macro_rules`.

This API addition opens the way to stabilizing proc macros in expression positions (rust-lang#54727), for which use of call-site hygiene or workarounds with temporary items would be quite unfortunate.
(`macro_rules` expanded in expression position, on the other hand, are stable since 1.0 and widely used.)

r? @dtolnay @alexcrichton
bors added a commit that referenced this pull request Oct 3, 2019
Rollup of 11 pull requests

Successful merges:

 - #61879 (Stabilize todo macro)
 - #64675 (Deprecate `#![plugin]` & `#[plugin_registrar]`)
 - #64690 (proc_macro API: Expose `macro_rules` hygiene)
 - #64706 (add regression test for #60218)
 - #64741 (Prevent rustdoc feature doctests)
 - #64842 (Disallow Self in type param defaults of ADTs)
 - #65004 (Replace mentions of IRC with Discord)
 - #65018 (Set RUST_BACKTRACE=0 in tests that include a backtrace in stderr)
 - #65055 (Add long error explanation for E0556)
 - #65056 (Make visit projection iterative)
 - #65057 (typo: fix typo in E0392)

Failed merges:

r? @ghost
@bors bors merged commit d1310dc into rust-lang:master Oct 4, 2019
4 of 5 checks passed
4 of 5 checks passed
homu Testing commit d1310dc6c989e191d85c73c943d4175fbf1dccb8 with merge 8d7c6e33e4bd8f6ed8953991f3992af618cbdbd1...
Details
pr Build #20191003.37 succeeded
Details
pr (Linux mingw-check) Linux mingw-check succeeded
Details
pr (Linux x86_64-gnu-llvm-6.0) Linux x86_64-gnu-llvm-6.0 succeeded
Details
pr (LinuxTools) LinuxTools succeeded
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.