Skip to content

Consider deferring parse error on sensibly placed unsafe keyword #68048

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
dtolnay opened this issue Jan 9, 2020 · 1 comment · Fixed by #75857
Closed

Consider deferring parse error on sensibly placed unsafe keyword #68048

dtolnay opened this issue Jan 9, 2020 · 1 comment · Fixed by #75857
Labels
A-parser Area: The lexing & parsing of Rust source code to an AST C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team

Comments

@dtolnay
Copy link
Member

dtolnay commented Jan 9, 2020

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 unsafe keyword in Rust syntax.

#[my_macro]
unsafe mod m {
    ...
}

#[my_macro]
unsafe extern "C" {
    ...
}

Currently these fail early with a parse error; you can reproduce by replacing my_macro with cfg(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 unsafe from a mod or foreign mod and assign their own semantics for what it means. If unsafe remains 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 async on a trait method or pub inside an enum or on an impl:

#[cfg(any())]
trait Trait {
    async fn f();
}

#[cfg(any())]
enum E {
    pub X,
}

#[cfg(any())]
pub impl T {}

Mentioning @Centril who requested an issue to discuss this further.

@dtolnay dtolnay added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jan 9, 2020
@Centril Centril added T-lang Relevant to the language team C-feature-request Category: A feature request, i.e: not implemented / a PR. A-parser Area: The lexing & parsing of Rust source code to an AST labels Jan 9, 2020
@dtolnay
Copy link
Member Author

dtolnay commented Sep 2, 2020

Opened a PR with an implementation of this: #75857.

@bors bors closed this as completed in 5aed495 Sep 10, 2020
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-parser Area: The lexing & parsing of Rust source code to an AST C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants