remove support for extern-block const intrinsics #132492
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
const-intrinsics
branch
from
760e111 to
7ca60f4
Compare
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
const-intrinsics
branch
2 times, most recently
from
223e7bb to
57ed415
Compare
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
const-intrinsics
branch
2 times, most recently
from
4565d04 to
7231200
Compare
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
const-intrinsics
branch
from
7231200 to
d60ea80
Compare
| }); | ||
| } | ||
| Some(ConstStability { level: StabilityLevel::Stable { .. }, .. }) => { | ||
| // All good. | ||
| // All good. Note that a `#[rustc_const_stable]` intrinsic (meaning it |
There was a problem hiding this comment.
When would an intrinsic be marked as rustc_const_stable but not rustc_const_stable_intrinsic? I cannot seem to find any example in this PR.
There was a problem hiding this comment.
transmute is such an intrinsic. It seems silly to require both attributes.
RalfJung
force-pushed
the
const-intrinsics
branch
from
d60ea80 to
f0efcbf
Compare
|
☔ The latest upstream changes (presumably #132586) made this pull request unmergeable. Please resolve the merge conflicts. |
RalfJung
force-pushed
the
const-intrinsics
branch
from
f0efcbf to
a6601ae
Compare
|
☔ The latest upstream changes (presumably #132603) made this pull request unmergeable. Please resolve the merge conflicts. |
compiler-errors
approved these changes
Nov 4, 2024
|
r=me after rebase, sorry for taking a bit to review this lol @rustbot author |
rustbot
added
S-waiting-on-author
RalfJung
force-pushed
the
const-intrinsics
branch
from
a6601ae to
a741b33
Compare
|
Review within 2.5 days, that's pretty fast I would say. :) Thanks! @bors r=compiler-errors |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 5, 2024
…kingjubilee Rollup of 11 pull requests Successful merges: - rust-lang#131153 (Improve duplicate derive Copy/Clone diagnostics) - rust-lang#132025 (fix suggestion for diagnostic error E0027) - rust-lang#132303 (More tests for non-exhaustive C-like enums in FFI) - rust-lang#132492 (remove support for extern-block const intrinsics) - rust-lang#132587 (Revert "Avoid nested replacement ranges" from rust-lang#129346.) - rust-lang#132596 ([rustdoc] Fix `--show-coverage` when JSON output format is used) - rust-lang#132598 (Clippy: Move some attribute lints to be early pass (post expansion)) - rust-lang#132601 (Update books) - rust-lang#132606 (Improve example of `impl Pattern for &[char]`) - rust-lang#132608 (document `type_implements_trait`) - rust-lang#132609 (docs: fix grammar in doc comment at unix/process.rs) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 5, 2024
Rollup merge of rust-lang#132492 - RalfJung:const-intrinsics, r=compiler-errors remove support for extern-block const intrinsics This converts all const-callable intrinsics into the "new" form of a regular `fn` with `#[rustc_intrinsic]` attribute. That simplifies some of the logic since those functions can be marked `const fn` like regular functions, so intrinsics no longer need a special case to be considered const-callable at all. I also added a new attribute `#[rustc_const_stable_intrinsic]` to mark an intrinsic as being ready to be exposed on stable. Previously we used the `#[rustc_const_stable_indirect]` attribute for that, but that attribute had a dual role -- when used on a regular function, it is an entirely safe marker to make this function part of recursive const stability, but on an intrinsic it is a trusted marker requiring special care. It's not great for the same attribute to be sometimes fully checked and safe, and sometimes trusted and requiring special care, so I split this into two attributes. This also fixes rust-lang#122652 by accepting intrinsics as const-stable if they have a fallback body that is recursively const-stable. The library changes are best reviewed with whitespace hidden. r? `@compiler-errors`
|
Very nice! Thanks, Ralf. This'll make refactor-to-intrinsic so much nicer, not needing to add a scary "looks like it's making a stability promise" attribute to stuff that used to just be normal code. |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Nov 12, 2024
…, r=compiler-errors Proper support for cross-crate recursive const stability checks ~~Stacked on top of rust-lang#132492; only the last three commits are new.~~ In a crate without `staged_api` but with `-Zforce-unstable-if-unmarked`, we now subject all functions marked with `#[rustc_const_stable_indirect]` to recursive const stability checks. We require an opt-in so that by default, a crate can be built with `-Zforce-unstable-if-unmarked` and use nightly features as usual. This property is recorded in the crate metadata so when a `staged_api` crate calls such a function, it sees the `#[rustc_const_stable_indirect]` and allows it to be exposed on stable. This, finally, will let us expose `const fn` from hashbrown on stable. The second commit makes const stability more like regular stability: via `check_missing_const_stability`, we ensure that all publicly reachable functions have a const stability attribute -- both in `staged_api` crates and `-Zforce-unstable-if-unmarked` crates. To achieve this, we move around the stability computation so that const stability is computed after regular stability is done. This lets us access the final result of the regular stability computation, which we use so that `const fn` can inherit the regular stability (but only if that is "unstable"). Fortunately, this lets us get rid of an `Option` in `ConstStability`. This is the last PR that I have planned in this series. r? `@compiler-errors`
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 12, 2024
Rollup merge of rust-lang#132541 - RalfJung:const-stable-extern-crate, r=compiler-errors Proper support for cross-crate recursive const stability checks ~~Stacked on top of rust-lang#132492; only the last three commits are new.~~ In a crate without `staged_api` but with `-Zforce-unstable-if-unmarked`, we now subject all functions marked with `#[rustc_const_stable_indirect]` to recursive const stability checks. We require an opt-in so that by default, a crate can be built with `-Zforce-unstable-if-unmarked` and use nightly features as usual. This property is recorded in the crate metadata so when a `staged_api` crate calls such a function, it sees the `#[rustc_const_stable_indirect]` and allows it to be exposed on stable. This, finally, will let us expose `const fn` from hashbrown on stable. The second commit makes const stability more like regular stability: via `check_missing_const_stability`, we ensure that all publicly reachable functions have a const stability attribute -- both in `staged_api` crates and `-Zforce-unstable-if-unmarked` crates. To achieve this, we move around the stability computation so that const stability is computed after regular stability is done. This lets us access the final result of the regular stability computation, which we use so that `const fn` can inherit the regular stability (but only if that is "unstable"). Fortunately, this lets us get rid of an `Option` in `ConstStability`. This is the last PR that I have planned in this series. r? `@compiler-errors`
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this pull request
Nov 14, 2024
…ler-errors Proper support for cross-crate recursive const stability checks ~~Stacked on top of rust-lang/rust#132492; only the last three commits are new.~~ In a crate without `staged_api` but with `-Zforce-unstable-if-unmarked`, we now subject all functions marked with `#[rustc_const_stable_indirect]` to recursive const stability checks. We require an opt-in so that by default, a crate can be built with `-Zforce-unstable-if-unmarked` and use nightly features as usual. This property is recorded in the crate metadata so when a `staged_api` crate calls such a function, it sees the `#[rustc_const_stable_indirect]` and allows it to be exposed on stable. This, finally, will let us expose `const fn` from hashbrown on stable. The second commit makes const stability more like regular stability: via `check_missing_const_stability`, we ensure that all publicly reachable functions have a const stability attribute -- both in `staged_api` crates and `-Zforce-unstable-if-unmarked` crates. To achieve this, we move around the stability computation so that const stability is computed after regular stability is done. This lets us access the final result of the regular stability computation, which we use so that `const fn` can inherit the regular stability (but only if that is "unstable"). Fortunately, this lets us get rid of an `Option` in `ConstStability`. This is the last PR that I have planned in this series. r? `@compiler-errors`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This converts all const-callable intrinsics into the "new" form of a regular
fnwith#[rustc_intrinsic]attribute. That simplifies some of the logic since those functions can be markedconst fnlike regular functions, so intrinsics no longer need a special case to be considered const-callable at all.I also added a new attribute
#[rustc_const_stable_intrinsic]to mark an intrinsic as being ready to be exposed on stable. Previously we used the#[rustc_const_stable_indirect]attribute for that, but that attribute had a dual role -- when used on a regular function, it is an entirely safe marker to make this function part of recursive const stability, but on an intrinsic it is a trusted marker requiring special care. It's not great for the same attribute to be sometimes fully checked and safe, and sometimes trusted and requiring special care, so I split this into two attributes.This also fixes #122652 by accepting intrinsics as const-stable if they have a fallback body that is recursively const-stable.
The library changes are best reviewed with whitespace hidden.
r? @compiler-errors