Skip to content
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

Consider deferring parse error on sensibly placed unsafe keyword #68048

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 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, which will review and decide on the PR/issue.

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, which will review and decide on the PR/issue. C-feature-request Category: A feature request, i.e: not implemented / a PR. A-parser Area: The 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parser Area: The 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, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants