proc_macro: Stop flattening groups with dummy spans #73102
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@bors try |
|
⌛ Trying commit d754b6fccd23147e425772d925152c7ef19850be with merge 71b81291baafb8a58836272757b28817fe1d8190... |
|
☀️ Try build successful - checks-azure |
|
@craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
the
S-waiting-on-crater
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
petrochenkov
added
S-waiting-on-author
|
Interesting and surprising. |
|
Closing in favor of #73345 which is simpler and more principled. |
petrochenkov
changed the title
|
Rebased and added some comments. |
Aaron1011
reviewed
Jun 25, 2020
Aaron1011
reviewed
Jun 25, 2020
|
r=me with the nits fixed |
|
@bors r=Aaron1011 |
|
📌 Commit 77b0ed7 has been approved by |
bors
added
S-waiting-on-bors
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Jun 26, 2020
proc_macro: Stop flattening groups with dummy spans Reduce the scope of the hack described in rust-lang#72545 (comment). We still pass AST fragments to attribute and derive macros as single nonterminal tokens rather than as tokens streams, but now use a precise flag instead of the span-based heuristic that could do lead to incorrect behavior in unrelated cases. rust-lang#73345 attempts to fully resolve this issue, but there are some compatibility issues to be addressed.
This was referenced Jun 26, 2020
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 26, 2020
…arth Rollup of 13 pull requests Successful merges: - rust-lang#72620 (Omit DW_AT_linkage_name when it is the same as DW_AT_name) - rust-lang#72967 (Don't move cursor in search box when using arrows to navigate results) - rust-lang#73102 (proc_macro: Stop flattening groups with dummy spans) - rust-lang#73297 (Support configurable deny-warnings for all in-tree crates.) - rust-lang#73507 (Cleanup MinGW LLVM linkage workaround) - rust-lang#73588 (Fix handling of reserved registers for ARM inline asm) - rust-lang#73597 (Record span of `const` kw in GenericParamKind) - rust-lang#73629 (Make AssocOp Copy) - rust-lang#73681 (Update Chalk to 0.14) - rust-lang#73707 (Fix links in `SliceIndex` documentation) - rust-lang#73719 (emitter: column width defaults to 140) - rust-lang#73729 (disable collectionbenches for android) - rust-lang#73748 (Add code block to code in documentation of `List::rebase_onto`) Failed merges: r? @ghost
|
I suspect this may have caused a perf regression. I'm going to try to do a perf CI run after the landing. Not sure if it will work... @bors try @rust-timer queue |
|
Awaiting bors try build completion |
|
Bors doesn't listen on closed issues/PRs. |
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Jul 1, 2020
expand: Stop using nonterminals for passing tokens to attribute and derive macros Make one more step towards fully token-based expansion and fix issues described in rust-lang#72545 (comment). Now `struct S;` is passed to `foo!(struct S;)` and `#[foo] struct S;` in the same way - as a token stream `struct S ;`, rather than a single non-terminal token `NtItem` which is then broken into parts later. The cost is making pretty-printing of token streams less pretty. Some of the pretty-printing regressions will be recovered by keeping jointness with each token, which we will need to do anyway. Unfortunately, this is not exactly the same thing as rust-lang#73102. One more observable effect is how `$crate` is printed in the attribute input. Inside `NtItem` was printed as `crate` or `that_crate`, now as a part of a token stream it's printed as `$crate` (there are good reasons for these differences, see rust-lang#62393 and related PRs). This may break old proc macros (custom derives) written before the main portion of the proc macro API (macros 1.2) was stabilized, those macros did `input.to_string()` and reparsed the result, now that result can contain `$crate` which cannot be reparsed. So, I think we should do this regardless, but we need to run crater first. r? @Aaron1011
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Jul 2, 2020
expand: Stop using nonterminals for passing tokens to attribute and derive macros Make one more step towards fully token-based expansion and fix issues described in rust-lang#72545 (comment). Now `struct S;` is passed to `foo!(struct S;)` and `#[foo] struct S;` in the same way - as a token stream `struct S ;`, rather than a single non-terminal token `NtItem` which is then broken into parts later. The cost is making pretty-printing of token streams less pretty. Some of the pretty-printing regressions will be recovered by keeping jointness with each token, which we will need to do anyway. Unfortunately, this is not exactly the same thing as rust-lang#73102. One more observable effect is how `$crate` is printed in the attribute input. Inside `NtItem` was printed as `crate` or `that_crate`, now as a part of a token stream it's printed as `$crate` (there are good reasons for these differences, see rust-lang#62393 and related PRs). This may break old proc macros (custom derives) written before the main portion of the proc macro API (macros 1.2) was stabilized, those macros did `input.to_string()` and reparsed the result, now that result can contain `$crate` which cannot be reparsed. So, I think we should do this regardless, but we need to run crater first. r? @Aaron1011
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Jul 2, 2020
expand: Stop using nonterminals for passing tokens to attribute and derive macros Make one more step towards fully token-based expansion and fix issues described in rust-lang#72545 (comment). Now `struct S;` is passed to `foo!(struct S;)` and `#[foo] struct S;` in the same way - as a token stream `struct S ;`, rather than a single non-terminal token `NtItem` which is then broken into parts later. The cost is making pretty-printing of token streams less pretty. Some of the pretty-printing regressions will be recovered by keeping jointness with each token, which we will need to do anyway. Unfortunately, this is not exactly the same thing as rust-lang#73102. One more observable effect is how `$crate` is printed in the attribute input. Inside `NtItem` was printed as `crate` or `that_crate`, now as a part of a token stream it's printed as `$crate` (there are good reasons for these differences, see rust-lang#62393 and related PRs). This may break old proc macros (custom derives) written before the main portion of the proc macro API (macros 1.2) was stabilized, those macros did `input.to_string()` and reparsed the result, now that result can contain `$crate` which cannot be reparsed. So, I think we should do this regardless, but we need to run crater first. r? @Aaron1011
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Jul 2, 2020
expand: Stop using nonterminals for passing tokens to attribute and derive macros Make one more step towards fully token-based expansion and fix issues described in rust-lang#72545 (comment). Now `struct S;` is passed to `foo!(struct S;)` and `#[foo] struct S;` in the same way - as a token stream `struct S ;`, rather than a single non-terminal token `NtItem` which is then broken into parts later. The cost is making pretty-printing of token streams less pretty. Some of the pretty-printing regressions will be recovered by keeping jointness with each token, which we will need to do anyway. Unfortunately, this is not exactly the same thing as rust-lang#73102. One more observable effect is how `$crate` is printed in the attribute input. Inside `NtItem` was printed as `crate` or `that_crate`, now as a part of a token stream it's printed as `$crate` (there are good reasons for these differences, see rust-lang#62393 and related PRs). This may break old proc macros (custom derives) written before the main portion of the proc macro API (macros 1.2) was stabilized, those macros did `input.to_string()` and reparsed the result, now that result can contain `$crate` which cannot be reparsed. So, I think we should do this regardless, but we need to run crater first. r? @Aaron1011
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Jul 2, 2020
expand: Stop using nonterminals for passing tokens to attribute and derive macros Make one more step towards fully token-based expansion and fix issues described in rust-lang#72545 (comment). Now `struct S;` is passed to `foo!(struct S;)` and `#[foo] struct S;` in the same way - as a token stream `struct S ;`, rather than a single non-terminal token `NtItem` which is then broken into parts later. The cost is making pretty-printing of token streams less pretty. Some of the pretty-printing regressions will be recovered by keeping jointness with each token, which we will need to do anyway. Unfortunately, this is not exactly the same thing as rust-lang#73102. One more observable effect is how `$crate` is printed in the attribute input. Inside `NtItem` was printed as `crate` or `that_crate`, now as a part of a token stream it's printed as `$crate` (there are good reasons for these differences, see rust-lang#62393 and related PRs). This may break old proc macros (custom derives) written before the main portion of the proc macro API (macros 1.2) was stabilized, those macros did `input.to_string()` and reparsed the result, now that result can contain `$crate` which cannot be reparsed. So, I think we should do this regardless, but we need to run crater first. r? @Aaron1011
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Jul 14, 2020
…arth Rollup of 13 pull requests Successful merges: - rust-lang#72620 (Omit DW_AT_linkage_name when it is the same as DW_AT_name) - rust-lang#72967 (Don't move cursor in search box when using arrows to navigate results) - rust-lang#73102 (proc_macro: Stop flattening groups with dummy spans) - rust-lang#73297 (Support configurable deny-warnings for all in-tree crates.) - rust-lang#73507 (Cleanup MinGW LLVM linkage workaround) - rust-lang#73588 (Fix handling of reserved registers for ARM inline asm) - rust-lang#73597 (Record span of `const` kw in GenericParamKind) - rust-lang#73629 (Make AssocOp Copy) - rust-lang#73681 (Update Chalk to 0.14) - rust-lang#73707 (Fix links in `SliceIndex` documentation) - rust-lang#73719 (emitter: column width defaults to 140) - rust-lang#73729 (disable collectionbenches for android) - rust-lang#73748 (Add code block to code in documentation of `List::rebase_onto`) Failed merges: r? @ghost
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reduce the scope of the hack described in #72545 (comment).
We still pass AST fragments to attribute and derive macros as single nonterminal tokens rather than as tokens streams, but now use a precise flag instead of the span-based heuristic that could do lead to incorrect behavior in unrelated cases.
#73345 attempts to fully resolve this issue, but there are some compatibility issues to be addressed.