-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
Consider deferring parse error on sensibly placed unsafe keyword #68048
Copy link
Copy link
Closed
Labels
A-parserArea: The lexing & parsing of Rust source code to an ASTArea: The lexing & parsing of Rust source code to an ASTC-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.T-langRelevant to the language teamRelevant to the language team
Metadata
Metadata
Assignees
Labels
A-parserArea: The lexing & parsing of Rust source code to an ASTArea: The lexing & parsing of Rust source code to an ASTC-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.T-langRelevant to the language teamRelevant to the language team
Type
Fields
Give feedbackNo fields configured for issues without a type.
In DSLs based on an attribute proc macro, it comes up that we want to require a syntactic safety claim on some item which would not normally allow an
unsafekeyword in Rust syntax.Currently these fail early with a parse error; you can reproduce by replacing
my_macrowithcfg(any()).I would like to suggest allowing these to parse and deferring the error until after macro expansion, giving attribute macros a chance to strip
unsafefrom a mod or foreign mod and assign their own semantics for what it means. Ifunsaferemains on a mod or foreign mod after macro expansion we can keep that an error; I am not proposing attaching any new semantics to that.We already do similar deferral of errors on "sensibly placed" keywords such as
asyncon a trait method orpubinside an enum or on an impl:Mentioning @Centril who requested an issue to discuss this further.