`safe` keyword is allowed in all function contexts about rust HOT 5 CLOSED

Should $item allow safe functions at all? (I think "yes", since it already accepts extern-block items.)

Yes, I don't think we need to be doing any context-specific parsing of macro item fragments. Validation that safe is only placed on items in an extern block should be done post-expansion IMO. That lets us write:

macro_rules! wrap_in_extern { ($i:item) => { unsafe extern { $i } } }

wrap_in_extern! { safe fn foo(); }

Should that be split out into a separate fragment, such as $item_2021 does not allow safe, and $item does in 2024?

We already allow item macro fragment specifiers start with the safe identifier, since safe might begin a macro item e.g. safe::hello_world! {}, so I don't think this is necessary.

from rust.

Another issue appears that safe is not feature-gated. The following seems to build without a feature gate:

safe fn foo() {}

from rust.

Thanks. I'll fix the feature gating at least, since it's regressed to beta. Let me break that out into another issue.

from rust.

But to repeat myself just for clarity, I think we just need to do post-expansion validation of function signatures to guarantee that safe is only written on items in extern blocks.

from rust.

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.
Anyway, going to fix this.

from rust.