Proper support for cross-crate recursive const stability checks#132541
Conversation
rustbot
added
S-waiting-on-review
| // `#[rustc_const_stable_indirect]` also requires a const fn | ||
| #[rustc_const_stable_indirect] | ||
| #[unstable(feature = "unstable", issue = "none")] | ||
| pub fn not_a_const_fn() {} |
There was a problem hiding this comment.
This regresses complaining about rustc_const_stable_indirect on non-const-fn... but keeping that error would make the code even more messy, and we also don't error for rustc_promotable on non-const-fn, so 🤷
There's an ongoing effort to redo the way we do attributes, that should hopefully make this easier in the future.
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
const-stable-extern-crate
branch
from
51004b7 to
8a6fd66
Compare
|
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
This comment has been minimized.
This comment has been minimized.
|
That's a tricky one... when one force-unstable-if-unmarked crate calls things from another one, how does that work? The callee crate has everything under the |
RalfJung
force-pushed
the
const-stable-extern-crate
branch
from
8a6fd66 to
96f9ada
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
const-stable-extern-crate
branch
from
8bf4b22 to
dbf3fba
Compare
|
☔ The latest upstream changes (presumably #132479) made this pull request unmergeable. Please resolve the merge conflicts. |
RalfJung
force-pushed
the
const-stable-extern-crate
branch
from
dbf3fba to
a307b47
Compare
|
☔ The latest upstream changes (presumably #132586) made this pull request unmergeable. Please resolve the merge conflicts. |
RalfJung
force-pushed
the
const-stable-extern-crate
branch
from
a307b47 to
28e920a
Compare
|
☔ The latest upstream changes (presumably #132603) made this pull request unmergeable. Please resolve the merge conflicts. |
RalfJung
force-pushed
the
const-stable-extern-crate
branch
from
28e920a to
c98d23d
Compare
|
The base PR landed, so this is ready to go now. :) |
RalfJung
force-pushed
the
const-stable-extern-crate
branch
from
c98d23d to
6632ba1
Compare
|
Some changes occurred to the CTFE machinery cc @rust-lang/wg-const-eval |
…e-unstable-if-unmarked
|
☔ The latest upstream changes (presumably #132831) made this pull request unmergeable. Please resolve the merge conflicts. |
RalfJung
force-pushed
the
const-stable-extern-crate
branch
from
6632ba1 to
430a398
Compare
| pub fn enforce_recursive_const_stability(&self) -> bool { | ||
| // We can skip this if `staged_api` is not enabled, since in such crates | ||
| // `lookup_const_stability` will always be `None`. | ||
| // We can skip this if neither `staged_api` nor `-Zforrce-unstable-if-unmarked` are enabled, |
|
r=me after really tiny nit |
RalfJung
force-pushed
the
const-stable-extern-crate
branch
from
430a398 to
3780496
Compare
|
@bors r=compiler-errors |
bors
added
S-waiting-on-bors
5 participants
Stacked on top of #132492; only the last three commits are new.In a crate without
staged_apibut 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-unmarkedand use nightly features as usual. This property is recorded in the crate metadata so when astaged_apicrate calls such a function, it sees the#[rustc_const_stable_indirect]and allows it to be exposed on stable. This, finally, will let us exposeconst fnfrom 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 instaged_apicrates and-Zforce-unstable-if-unmarkedcrates. 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 thatconst fncan inherit the regular stability (but only if that is "unstable"). Fortunately, this lets us get rid of anOptioninConstStability.This is the last PR that I have planned in this series.
r? @compiler-errors