-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Resolve attributes in several places #63468
Conversation
Meta: "draft" PRs don't interact well with our tooling, so it's better to avoid them. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@c410-f3r |
(We'll need to feature gate using proc macro attrs on the new forms as well and set up a tracking issue unless there already is one.) |
@Centril |
@petrochenkov I see; I was confused by the added |
Indeed |
syntax: Remove `DummyResult::expr_only` The effect is that if a built-in macro both returns an erroneous AST fragment and is used in unexpected position, then the incorrect position error won't be reported. This combination of two errors should be rare and isn't worth an extra field that makes people ask questions in comments. (There wasn't even a test making sure it worked.) Addresses rust-lang#63468 (comment) r? @estebank
Add NodeId for Arm, Field and FieldPat Extracted from rust-lang#63468
syntax: Remove `DummyResult::expr_only` The effect is that if a built-in macro both returns an erroneous AST fragment and is used in unexpected position, then the incorrect position error won't be reported. This combination of two errors should be rare and isn't worth an extra field that makes people ask questions in comments. (There wasn't even a test making sure it worked.) Addresses rust-lang#63468 (comment) r? @estebank
expand: Unimplement `MutVisitor` on `MacroExpander` Each call to `fully_expand_fragment` is something unique, interesting, and requiring attention. It represents a "root" of expansion and its use means that something unusual is happening, like eager expansion or expansion performed outside of the primary expansion pass. So, it shouldn't hide under a generic visitor call. Also, from all the implemented visitor methods only two were actually used. cc rust-lang#63468 (comment)
Add NodeId for Arm, Field and FieldPat Extracted from rust-lang#63468
syntax: Remove `DummyResult::expr_only` The effect is that if a built-in macro both returns an erroneous AST fragment and is used in unexpected position, then the incorrect position error won't be reported. This combination of two errors should be rare and isn't worth an extra field that makes people ask questions in comments. (There wasn't even a test making sure it worked.) Addresses rust-lang#63468 (comment) r? @estebank
@rustbot modify labels to +S-waiting-on-review , -S-waiting-on-author |
Great! |
Arm, Field, FieldPat, GenericParam, Param, StructField and Variant
@petrochenkov Thanks for your patience |
@bors r=petrochenkov |
📌 Commit 63a5f39 has been approved by |
Resolve attributes in several places Resolve attributes for Arm, Field, FieldPat, GenericParam, Param, StructField and Variant. This PR is based on @petrochenkov work located at petrochenkov@83fdb8d.
@c410-f3r |
feature_gate: Remove dead code from attribute checking rust-lang#63468 is merged, so all attributes go through name resolution now, so we can remove code that previously performed some checks for attributes not going through resolution.
Fully integrate derive helpers into name resolution ```rust #[derive(Foo)] #[foo_helper] // already goes through name resolution struct S { #[foo_helper] // goes through name resolution after this PR field: u8 } ``` How name resolution normally works: - We have an identifier we need to resolve, take its location (in some sense) and look what names are in scope in that location. How derive helper attributes are "resolved" (before this PR): - After resolving the derive `Foo` we visit the derive's input (`struct S { ... } `) as a piece of AST and mark attributes textually matching one of the derive's helper attributes (`foo_helper`) as "known", so they never go through name resolution. This PR changes the rules for derive helpers, so they are not proactively marked as known (which is a big hack ignoring any ambiguities or hygiene), but go through regular name resolution instead. This change was previously blocked by attributes not being resolved in some positions at all (fixed in #63468). "Where exactly are derive helpers in scope?" is an interesting question, and I need some feedback from proc macro authors to answer it, see the post below (#64694 (comment)).
Starting from rust-lang#63468 cfg attributes on variants, fields, fn params etc. are processed together with other attributes (via `configure!`).
Resolve attributes for Arm, Field, FieldPat, GenericParam, Param, StructField and Variant.
This PR is based on @petrochenkov work located at petrochenkov@83fdb8d.