Introduce rustc_const_stable and explain rustc_const_unstable
#542
Conversation
| stable function as `const fn` without instantly stabilizing the `const fn`ness. | ||
|
|
||
| Furthermore this attribute is needed to mark an intrinsic as `const fn`, because | ||
| there's no way to add `const` to functions in `extern` blocks for now. |
There was a problem hiding this comment.
argh... this is a syntactic problem? (I should fix this as part of my item-parsing unification work...)
There was a problem hiding this comment.
well... it's more of a const is not a part of https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.FnDecl.html
But since we have safe intrinsics nowadays, and const intrinsics, maybe we really should move to using a FnHeader. Though we don't want this as a general thing for extern items. The rust-intrinsic ABI really should go away and we should have a better scheme for declaring intrinsics. I think @eddyb had some thoughts on this, not sure if those were ever written down, but maybe we have an issue about it?
There was a problem hiding this comment.
well... it's more of a
constis not a part of https://doc.rust-lang.org/nightly/nightly-rustc/syntax/ast/struct.FnDecl.html
It should be an FnSig syntactically in ForeignItemKind. There should just be one function item grammar (aside from the snafu of requiring parameter names sometimes and sometimes not but that's a minor issue controlled by a flag basically).
Though I think you're about the semantic issue... we wanted #[rustc_intrinsic] iirc and there's an issue somewhere about that.
There was a problem hiding this comment.
Found it, rust-lang/rust#63585.
There was a problem hiding this comment.
It should be an FnSig syntactically in ForeignItemKind.
That won't work out of the box because the default for extern functions is unsafe, so you'd still need parser hacks.
There was a problem hiding this comment.
You don't need parser hacks. If we want to prevent anything, e.g. async fn in extern, then we can do it in ast_validation.
There was a problem hiding this comment.
It's not about denying, it's that extern functions are unsafe by default, so the normal parser will mark them safe
There was a problem hiding this comment.
That's something easily fixed in lowering which is the right place to draw such semantic distinctions.
r? @Centril