mirror
/
rustc-dev-guide
mirror of https://github.com/rust-lang/rustc-dev-guide.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

We stopped using allow_internal_unstable a while ago (#1142) 

Co-authored-by: Ralf Jung <post@ralfj.de>
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
Co-authored-by: Noah Lev <camelidcamel@gmail.com>
This commit is contained in:
Oli Scherer 2021-06-15 10:04:54 +02:00 committed by GitHub
parent 3559fa7fef
commit ae62be50bd
1 changed files with 20 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
src/stability.md
View File

@ -92,24 +92,32 @@ and the associated
## allow_internal_unstable ## allow_internal_unstable
Macros, compiler desugarings and `const fn`s expose their bodies to the call Macros and compiler desugarings expose their bodies to the call
site. To work around not being able to use unstable things in the standard site. To work around not being able to use unstable things in the standard
library's macros, there's the `#[allow_internal_unstable(feature1, feature2)]` library's macros, there's the `#[allow_internal_unstable(feature1, feature2)]`
attribute that allows the given features to be used in stable macros or attribute that allows the given features to be used in stable macros.
`const fn`s.
Note that `const fn`s are even more special in this regard. You can't just ## rustc_allow_const_fn_unstable
allow any feature, the features need an implementation in
`qualify_min_const_fn.rs`. For example the `const_fn_union` feature gate allows `const fn`, while not directly exposing their body to the world, are going to get
accessing fields of unions inside stable `const fn`s. The rules for when it's evaluated at compile time in stable crates. If their body does something const-unstable,
ok to use such a feature gate are that behavior matches the runtime behavior of that could lock us into certain features indefinitely by accident. Thus no unstable const
the same code (see also [this blog post][blog]). This means that you may not features are allowed inside stable `const fn`.
create a `const fn` that e.g. transmutes a memory address to an integer,
However, sometimes we do know that a feature will get
stabilized, just not when, or there is a stable (but e.g. runtime-slow) workaround, so we
could always fall back to some stable version if we scrapped the unstable feature.
In those cases, the rustc_allow_const_fn_unstable attribute can be used to allow some
unstable features in the body of a stable `const fn`.
You also need to take care to uphold the `const fn` invariant that calling it at runtime and
compile-time needs to behave the same (see also [this blog post][blog]). This means that you
may not create a `const fn` that e.g. transmutes a memory address to an integer,
because the addresses of things are nondeterministic and often unknown at because the addresses of things are nondeterministic and often unknown at
compile-time. compile-time.
Always ping @oli-obk, @RalfJung, and @Centril if you are adding more Always ping @rust-lang/wg-const-eval if you are adding more
`allow_internal_unstable` attributes to any `const fn` `rustc_allow_const_fn_unstable` attributes to any `const fn`.
## staged_api ## staged_api