Remove some legacy proc macro flavors #61606
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
petrochenkov
added
the
S-waiting-on-review
|
@bors r+ rollup |
|
📌 Commit 48d2c0b has been approved by |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jun 10, 2019
Remove some legacy proc macro flavors
Namely
- `IdentTT` (`foo! ident { ... }`). Can be replaced with `foo! { ident ... }` or something similar.
- `MultiDecorator`. Can be replaced by `MultiModifier` (aka `LegacyAttr` after renaming).
- `DeclMacro`. It was a less powerful duplicate of `NormalTT` (aka `LegacyBang` after renaming) and can be replaced by it.
Stuff like this slows down any attempts to refactor the expansion infra, so it's desirable to retire it already.
I'm not sure whether a lang team decision is necessary, but would be nice to land this sooner because I have some further work in this area scheduled.
The documentation commit (rust-lang@a9397fd) describes how the remaining variants are different from each other and shows that there's actually some system behind them.
The last commit renames variants of `SyntaxExtension` in more systematic way.
- `ProcMacro` -> `Bang`
- `NormalTT` -> `LegacyBang`
- `AttrProcMacro` -> `Attr`
- `MultiModifier` -> `LegacyAttr`
- `ProcMacroDerive` -> `Derive`
- `BuiltinDerive` -> `LegacyDerive`
All the `Legacy*` variants are AST-based, as opposed to "modern" token-based variants.
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jun 10, 2019
Remove some legacy proc macro flavors
Namely
- `IdentTT` (`foo! ident { ... }`). Can be replaced with `foo! { ident ... }` or something similar.
- `MultiDecorator`. Can be replaced by `MultiModifier` (aka `LegacyAttr` after renaming).
- `DeclMacro`. It was a less powerful duplicate of `NormalTT` (aka `LegacyBang` after renaming) and can be replaced by it.
Stuff like this slows down any attempts to refactor the expansion infra, so it's desirable to retire it already.
I'm not sure whether a lang team decision is necessary, but would be nice to land this sooner because I have some further work in this area scheduled.
The documentation commit (rust-lang@a9397fd) describes how the remaining variants are different from each other and shows that there's actually some system behind them.
The last commit renames variants of `SyntaxExtension` in more systematic way.
- `ProcMacro` -> `Bang`
- `NormalTT` -> `LegacyBang`
- `AttrProcMacro` -> `Attr`
- `MultiModifier` -> `LegacyAttr`
- `ProcMacroDerive` -> `Derive`
- `BuiltinDerive` -> `LegacyDerive`
All the `Legacy*` variants are AST-based, as opposed to "modern" token-based variants.
bors
added
S-waiting-on-author
|
Also cc @rust-lang/compiler @rust-lang/lang for more visibility. |
It's a less powerful duplicate of `SyntaxExtension::NormalTT`
|
@bors r=pnkfelix |
|
📌 Commit 93eb63c has been approved by |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jun 11, 2019
Remove some legacy proc macro flavors
Namely
- `IdentTT` (`foo! ident { ... }`). Can be replaced with `foo! { ident ... }` or something similar.
- `MultiDecorator`. Can be replaced by `MultiModifier` (aka `LegacyAttr` after renaming).
- `DeclMacro`. It was a less powerful duplicate of `NormalTT` (aka `LegacyBang` after renaming) and can be replaced by it.
Stuff like this slows down any attempts to refactor the expansion infra, so it's desirable to retire it already.
I'm not sure whether a lang team decision is necessary, but would be nice to land this sooner because I have some further work in this area scheduled.
The documentation commit (rust-lang@a9397fd) describes how the remaining variants are different from each other and shows that there's actually some system behind them.
The last commit renames variants of `SyntaxExtension` in more systematic way.
- `ProcMacro` -> `Bang`
- `NormalTT` -> `LegacyBang`
- `AttrProcMacro` -> `Attr`
- `MultiModifier` -> `LegacyAttr`
- `ProcMacroDerive` -> `Derive`
- `BuiltinDerive` -> `LegacyDerive`
All the `Legacy*` variants are AST-based, as opposed to "modern" token-based variants.
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jun 11, 2019
Remove some legacy proc macro flavors
Namely
- `IdentTT` (`foo! ident { ... }`). Can be replaced with `foo! { ident ... }` or something similar.
- `MultiDecorator`. Can be replaced by `MultiModifier` (aka `LegacyAttr` after renaming).
- `DeclMacro`. It was a less powerful duplicate of `NormalTT` (aka `LegacyBang` after renaming) and can be replaced by it.
Stuff like this slows down any attempts to refactor the expansion infra, so it's desirable to retire it already.
I'm not sure whether a lang team decision is necessary, but would be nice to land this sooner because I have some further work in this area scheduled.
The documentation commit (rust-lang@a9397fd) describes how the remaining variants are different from each other and shows that there's actually some system behind them.
The last commit renames variants of `SyntaxExtension` in more systematic way.
- `ProcMacro` -> `Bang`
- `NormalTT` -> `LegacyBang`
- `AttrProcMacro` -> `Attr`
- `MultiModifier` -> `LegacyAttr`
- `ProcMacroDerive` -> `Derive`
- `BuiltinDerive` -> `LegacyDerive`
All the `Legacy*` variants are AST-based, as opposed to "modern" token-based variants.
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jun 11, 2019
Remove some legacy proc macro flavors
Namely
- `IdentTT` (`foo! ident { ... }`). Can be replaced with `foo! { ident ... }` or something similar.
- `MultiDecorator`. Can be replaced by `MultiModifier` (aka `LegacyAttr` after renaming).
- `DeclMacro`. It was a less powerful duplicate of `NormalTT` (aka `LegacyBang` after renaming) and can be replaced by it.
Stuff like this slows down any attempts to refactor the expansion infra, so it's desirable to retire it already.
I'm not sure whether a lang team decision is necessary, but would be nice to land this sooner because I have some further work in this area scheduled.
The documentation commit (rust-lang@a9397fd) describes how the remaining variants are different from each other and shows that there's actually some system behind them.
The last commit renames variants of `SyntaxExtension` in more systematic way.
- `ProcMacro` -> `Bang`
- `NormalTT` -> `LegacyBang`
- `AttrProcMacro` -> `Attr`
- `MultiModifier` -> `LegacyAttr`
- `ProcMacroDerive` -> `Derive`
- `BuiltinDerive` -> `LegacyDerive`
All the `Legacy*` variants are AST-based, as opposed to "modern" token-based variants.
bors
added a commit
that referenced
this pull request
Jun 11, 2019
Rollup of 11 pull requests Successful merges: - #61518 (Add loops to doc list of things not stable in const fn) - #61526 (move some tests into subfolders) - #61550 (Windows 10 SDK is also required now.) - #61606 (Remove some legacy proc macro flavors) - #61652 (Mention slice patterns in array) - #61686 (librustc_errors: Add some more documentation) - #61698 (typeck: Fix const generic in repeat param ICE.) - #61707 (Azure: retry failed awscli installs) - #61715 (make sure make_ascii_lowercase actually leaves upper-case non-ASCII characters alone) - #61724 (core: use memcmp optimization for 128 bit integer slices) - #61726 (Use `for_each` in `Iterator::partition`) Failed merges: r? @ghost
bors
added a commit
that referenced
this pull request
Jun 11, 2019
Rollup of 11 pull requests Successful merges: - #61518 (Add loops to doc list of things not stable in const fn) - #61526 (move some tests into subfolders) - #61550 (Windows 10 SDK is also required now.) - #61606 (Remove some legacy proc macro flavors) - #61652 (Mention slice patterns in array) - #61686 (librustc_errors: Add some more documentation) - #61698 (typeck: Fix const generic in repeat param ICE.) - #61707 (Azure: retry failed awscli installs) - #61715 (make sure make_ascii_lowercase actually leaves upper-case non-ASCII characters alone) - #61724 (core: use memcmp optimization for 128 bit integer slices) - #61726 (Use `for_each` in `Iterator::partition`) Failed merges: r? @ghost
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jun 18, 2019
syntax: Factor out common fields from `SyntaxExtension` variants And some other related cleanups. Continuation of rust-lang#61606. This will also help to unblock rust-lang#61877.
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jun 18, 2019
syntax: Factor out common fields from `SyntaxExtension` variants And some other related cleanups. Continuation of rust-lang#61606. This will also help to unblock rust-lang#61877.
This was referenced Jun 28, 2019
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jul 1, 2019
syntax: Unsupport `foo! bar { ... }` macros in the parser
Their support in expansion was removed in rust-lang#61606.
Also un-reserve `macro_rules` as a macro name, there's no ambiguity between `macro_rules` definitions and macro calls (it also wasn't reserved correctly).
cc rust-lang/wg-grammar#51
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jul 3, 2019
syntax: Unsupport `foo! bar { ... }` macros in the parser
Their support in expansion was removed in rust-lang#61606.
Also un-reserve `macro_rules` as a macro name, there's no ambiguity between `macro_rules` definitions and macro calls (it also wasn't reserved correctly).
cc rust-lang/wg-grammar#51
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jul 3, 2019
syntax: Unsupport `foo! bar { ... }` macros in the parser
Their support in expansion was removed in rust-lang#61606.
Also un-reserve `macro_rules` as a macro name, there's no ambiguity between `macro_rules` definitions and macro calls (it also wasn't reserved correctly).
cc rust-lang/wg-grammar#51
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jul 3, 2019
syntax: Unsupport `foo! bar { ... }` macros in the parser
Their support in expansion was removed in rust-lang#61606.
Also un-reserve `macro_rules` as a macro name, there's no ambiguity between `macro_rules` definitions and macro calls (it also wasn't reserved correctly).
cc rust-lang/wg-grammar#51
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jul 3, 2019
syntax: Unsupport `foo! bar { ... }` macros in the parser
Their support in expansion was removed in rust-lang#61606.
Also un-reserve `macro_rules` as a macro name, there's no ambiguity between `macro_rules` definitions and macro calls (it also wasn't reserved correctly).
cc rust-lang/wg-grammar#51
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.
Namely
IdentTT(foo! ident { ... }). Can be replaced withfoo! { ident ... }or something similar.MultiDecorator. Can be replaced byMultiModifier(akaLegacyAttrafter renaming).DeclMacro. It was a less powerful duplicate ofNormalTT(akaLegacyBangafter renaming) and can be replaced by it.Stuff like this slows down any attempts to refactor the expansion infra, so it's desirable to retire it already.
I'm not sure whether a lang team decision is necessary, but would be nice to land this sooner because I have some further work in this area scheduled.
The documentation commit (a9397fd) describes how the remaining variants are different from each other and shows that there's actually some system behind them.
The last commit renames variants of
SyntaxExtensionin more systematic way.ProcMacro->BangNormalTT->LegacyBangAttrProcMacro->AttrMultiModifier->LegacyAttrProcMacroDerive->DeriveBuiltinDerive->LegacyDeriveAll the
Legacy*variants are AST-based, as opposed to "modern" token-based variants.