proc_macro API: Expose `macro_rules` hygiene #64690

petrochenkov · 2019-09-22T16:58:59Z

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

src/test/ui/proc-macro/dollar-crate-issue-62325.stdout

alexcrichton · 2019-09-23T14:45:32Z

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

src/libproc_macro/lib.rs

SergioBenitez · 2019-09-24T01:17:01Z

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 · 2019-09-24T18:55:23Z

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

Exactly.

Alexendoo · 2019-10-02T14:00:13Z

Ping from triage, any updates? @dtolnay

dtolnay

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 · 2019-10-02T21:48:56Z

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 · 2019-10-02T21:54:46Z

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.

Centril · 2019-10-03T08:37:49Z

cc @pnkfelix

petrochenkov · 2019-10-03T08:42:50Z

@bors r=dtolnay

bors · 2019-10-03T08:42:51Z

📌 Commit d1310dc has been approved by dtolnay

@dtolnay

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

@ghost

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 · 2019-10-03T12:05:16Z

⌛ Testing commit d1310dc with merge 8d7c6e33e4bd8f6ed8953991f3992af618cbdbd1...

Centril · 2019-10-03T12:19:17Z

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

@dtolnay

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

@dtolnay

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

@dtolnay

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

@ghost

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

rust-highfive assigned dtolnay Sep 22, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 22, 2019

petrochenkov added T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Sep 22, 2019

bjorn3 reviewed Sep 22, 2019

View reviewed changes

src/test/ui/proc-macro/dollar-crate-issue-62325.stdout Show resolved Hide resolved

SergioBenitez reviewed Sep 24, 2019

View reviewed changes

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

dtolnay reviewed Oct 2, 2019

View reviewed changes

dtolnay approved these changes Oct 2, 2019

View reviewed changes

petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 2, 2019

petrochenkov mentioned this pull request Oct 3, 2019

Tracking issue for Span::mixed_site #65049

Closed

proc_macro: Add Span::mixed_site exposing macro_rules hygiene

d1310dc

petrochenkov force-pushed the mixed branch from 02c0ec1 to d1310dc Compare October 3, 2019 08:42

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 Oct 3, 2019

Centril mentioned this pull request Oct 3, 2019

Rollup of 5 pull requests #65053

Closed

Centril mentioned this pull request Oct 3, 2019

Rollup of 11 pull requests #65072

Closed

tmandry mentioned this pull request Oct 3, 2019

Rollup of 12 pull requests #65075

Closed

tmandry mentioned this pull request Oct 3, 2019

Rollup of 11 pull requests #65076

Merged

bors merged commit d1310dc into rust-lang:master Oct 4, 2019

tesuji mentioned this pull request Oct 4, 2019

rustfmt no longer builds after rust-lang/rust#65076 #65085

Closed

tmandry mentioned this pull request Oct 5, 2019

rls no longer builds after rust-lang/rust#65076 #65084

Closed

CAD97 mentioned this pull request Jan 5, 2020

expose mixed_site macro_rules hygeine dtolnay/proc-macro2#210

Closed

This comment has been minimized.

Sign in to view

petrochenkov mentioned this pull request Feb 1, 2020

Stabilize Span::mixed_site #68716

Merged

andrewhickman mentioned this pull request Jul 4, 2021

Fix borrowing issues andrewhickman/fn-error-context#5

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

proc_macro API: Expose `macro_rules` hygiene #64690

proc_macro API: Expose `macro_rules` hygiene #64690

petrochenkov commented Sep 22, 2019 •

edited

Loading

alexcrichton commented Sep 23, 2019

SergioBenitez commented Sep 24, 2019

petrochenkov commented Sep 24, 2019

Alexendoo commented Oct 2, 2019

dtolnay left a comment

petrochenkov commented Oct 2, 2019

dtolnay commented Oct 2, 2019

Centril commented Oct 3, 2019

petrochenkov commented Oct 3, 2019

bors commented Oct 3, 2019

bors commented Oct 3, 2019

Centril commented Oct 3, 2019

This comment has been minimized.

proc_macro API: Expose macro_rules hygiene #64690

proc_macro API: Expose macro_rules hygiene #64690

Conversation

petrochenkov commented Sep 22, 2019 • edited Loading

alexcrichton commented Sep 23, 2019

SergioBenitez commented Sep 24, 2019

petrochenkov commented Sep 24, 2019

Alexendoo commented Oct 2, 2019

dtolnay left a comment

Choose a reason for hiding this comment

petrochenkov commented Oct 2, 2019

dtolnay commented Oct 2, 2019

Centril commented Oct 3, 2019

petrochenkov commented Oct 3, 2019

bors commented Oct 3, 2019

bors commented Oct 3, 2019

Centril commented Oct 3, 2019

This comment has been minimized.

proc_macro API: Expose `macro_rules` hygiene #64690

proc_macro API: Expose `macro_rules` hygiene #64690

petrochenkov commented Sep 22, 2019 •

edited

Loading