Fix duplicated attributes on nonterminal expressions #126678
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
Something that was non-obvious to me.
The call in `parse_expr_prefix` for the `++` case passes an empty `attrs`, but it doesn' need to. This commit changes it to pass the parsed `attrs`, which doesn't change any behaviour. As a result, `parse_expr_dot_or_call` no longer needs an `Option` argument, and no longer needs to call `parse_or_use_outer_attributes`.
The `Option<AttrWrapper>` one maps to the first two variants, and the `P<Expr>` one maps to the third. Weird. The code is shorter and clearer without them.
Combine `NotYetParsed` and `AttributesParsed` into a single variant, because (a) that reflects the structure of the code that consumes `LhsExpr`, and (b) because that variant will have the `Option` removed in a later commit.
It has a single call site.
This eliminates one `Option<AttrWrapper>` argument.
This eliminates another `Option<AttrWrapper>` argument and changes one obscure error message.
By making the `AttrWrapper` non-optional.
This removes the final `Option<AttrWrapper>` argument.
It now parses outer attributes before collecting tokens. This avoids the problem where the outer attribute tokens were being stored twice -- for the attribute tokesn, and also for the expression tokens. Fixes rust-lang#86055.
rustbot
added
S-waiting-on-review
|
@bors r+ |
bors
added
S-waiting-on-bors
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 19, 2024
…nt-expr, r=petrochenkov Fix duplicated attributes on nonterminal expressions This PR fixes a long-standing bug (rust-lang#86055) whereby expression attributes can be duplicated when expanded through declarative macros. First, consider how items are parsed in declarative macros: ``` Items: - parse_nonterminal - parse_item(ForceCollect::Yes) - parse_item_ - attrs = parse_outer_attributes - parse_item_common(attrs) - maybe_whole! - collect_tokens_trailing_token ``` The important thing is that the parsing of outer attributes is outside token collection, so the item's tokens don't include the attributes. This is how it's supposed to be. Now consider how expression are parsed in declarative macros: ``` Exprs: - parse_nonterminal - parse_expr_force_collect - collect_tokens_no_attrs - collect_tokens_trailing_token - parse_expr - parse_expr_res(None) - parse_expr_assoc_with - parse_expr_prefix - parse_or_use_outer_attributes - parse_expr_dot_or_call ``` The important thing is that the parsing of outer attributes is inside token collection, so the the expr's tokens do include the attributes, i.e. in `AttributesData::tokens`. This PR fixes the bug by rearranging expression parsing to that outer attribute parsing happens outside of token collection. This requires a number of small refactorings because expression parsing is somewhat complicated. While doing so the PR makes the code a bit cleaner and simpler, by eliminating `parse_or_use_outer_attributes` and `Option<AttrWrapper>` arguments (in favour of the simpler `parse_outer_attributes` and `AttrWrapper` arguments), and simplifying `LhsExpr`. r? `@petrochenkov`
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (894f7a4): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResults (secondary 2.1%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 690.996s -> 690.539s (-0.07%) |
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.
This PR fixes a long-standing bug (#86055) whereby expression attributes can be duplicated when expanded through declarative macros.
First, consider how items are parsed in declarative macros:
The important thing is that the parsing of outer attributes is outside token collection, so the item's tokens don't include the attributes. This is how it's supposed to be.
Now consider how expression are parsed in declarative macros:
The important thing is that the parsing of outer attributes is inside token collection, so the the expr's tokens do include the attributes, i.e. in
AttributesData::tokens.This PR fixes the bug by rearranging expression parsing to that outer attribute parsing happens outside of token collection. This requires a number of small refactorings because expression parsing is somewhat complicated. While doing so the PR makes the code a bit cleaner and simpler, by eliminating
parse_or_use_outer_attributesandOption<AttrWrapper>arguments (in favour of the simplerparse_outer_attributesandAttrWrapperarguments), and simplifyingLhsExpr.r? @petrochenkov