Skip to content

Introduce rustc_const_stable and explain rustc_const_unstable #542

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Dec 24, 2019
Merged

Introduce rustc_const_stable and explain rustc_const_unstable #542

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions src/stability.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,6 +49,28 @@ marks an item as stabilized. To do this, follow the instructions in

Note that stable functions may use unstable things in their body.

## rustc_const_unstable

The `#[rustc_const_unstable(feature = "foo", issue = "1234", reason = "lorem ipsum")]`
has the same interface as the `unstable` attribute. It is used to mark
`const fn` as having their constness be unstable. This allows you to make a
function stable without stabilizing its constness or even just marking an existing
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

argh... this is a syntactic problem? (I should fix this as part of my item-parsing unification work...)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found it, rust-lang/rust#63585.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not about denying, it's that extern functions are unsafe by default, so the normal parser will mark them safe

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's something easily fixed in lowering which is the right place to draw such semantic distinctions.


## rustc_const_stable

The `#[stable(feature = "foo", "since = "1.420.69")]` attribute explicitly marks
a `const fn` as having its constness be `stable`. This attribute can make sense
even on an `unstable` function, if that function is called from another
`rustc_const_stable` function.

Furthermore this attribute is needed to mark an intrinsic as callable from
`rustc_const_stable` functions.


## allow_internal_unstable

Macros, compiler desugarings and `const fn`s expose their bodies to the call
Expand Down