-
Notifications
You must be signed in to change notification settings - Fork 12.3k
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
safe
keyword is allowed in all function contexts
#126749
Comments
Yes, I don't think we need to be doing any context-specific parsing of macro item fragments. Validation that
We already allow item macro fragment specifiers start with the |
But to repeat myself just for clarity, I think we just need to do post-expansion validation of function signatures to guarantee that |
Another issue appears that safe fn foo() {} |
Thanks. I'll fix the feature gating at least, since it's regressed to beta. Let me break that out into another issue. |
Thanks @compiler-errors your fix at least make this thing not compile. I'm going to fix the underlying issue that I think started to happen as I ended going to a scheme where we have hir::Safety (safe|unsafe) and we do not have a default variant. I'm pretty sure that this thing originally wasn't happening but I've failed to add tests for this. |
…fe-blocks, r=compiler-errors Do not allow safe/unsafe on static and fn items Fixes rust-lang#126749 r? `@compiler-errors` Tracking: - rust-lang#123743
…-blocks, r=compiler-errors Do not allow safe/unsafe on static and fn items Fixes rust-lang#126749 r? `@compiler-errors` Tracking: - rust-lang#123743
…-blocks, r=compiler-errors Do not allow safe/unsafe on static and fn items Fixes rust-lang#126749 r? `@compiler-errors` Tracking: - rust-lang#123743
The
safe
keyword appears to be allowed in all function contexts. However, the RFC explicitly says it should only be allowed inextern
blocks:I expected to see this happen: Compile error
Instead, this happened: Compile success
cc @spastorino FYI
macro fragment
Additionally, it looks likesafe fn foo();
is accepted in$item
macro fragment specifier. I think there are different decisions to make here:Should$item
allowsafe
functions at all? (I think "yes", since it already accepts extern-block items.)Should that be split out into a separate fragment, such as$item_2021
does not allowsafe
, and$item
does in 2024? See Tracking Issue for updatingexpr
macro fragment specifier for Rust 2024 #123742.EDIT: Concluded below this should not be an issue.
Meta
Tracking:
The text was updated successfully, but these errors were encountered: