nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-25 08:13:41 +00:00
Code Issues Packages Projects Releases Wiki Activity
bca5fdebe0
rust/compiler/rustc_middle
History
bors bca5fdebe0 Auto merge of #131321 - RalfJung:feature-activation, r=nnethercote 
terminology: #[feature] *enables* a feature (instead of "declaring" or "activating" it)

Mostly, we currently call a feature that has a corresponding `#[feature(name)]` attribute in the current crate a "declared" feature. I think that is confusing as it does not align with what "declaring" usually means. Furthermore, we *also* refer to `#[stable]`/`#[unstable]` as *declaring* a feature (e.g. in [these diagnostics](f25e5abea2/compiler/rustc_passes/messages.ftl (L297-L301))), which aligns better with what "declaring" usually means. To make things worse, the functions  `tcx.features().active(...)` and  `tcx.features().declared(...)` both exist and they are doing almost the same thing (testing whether a corresponding `#[feature(name)]`  exists) except that `active` would ICE if the feature is not an unstable lang feature. On top of this, the callback when a feature is activated/declared is called `set_enabled`, and many comments also talk about "enabling" a feature.

So really, our terminology is just a mess.

I would suggest we use "declaring a feature" for saying that something is/was guarded by a feature (e.g. `#[stable]`/`#[unstable]`), and "enabling a feature" for  `#[feature(name)]`. This PR implements that.
2024-10-22 11:02:35 +00:00
..
src Auto merge of #131321 - RalfJung:feature-activation, r=nnethercote 2024-10-22 11:02:35 +00:00
Cargo.toml compiler: Factor rustc_target::abi::* out of middle::ty::layout 2024-10-08 18:14:48 -07:00
messages.ftl TL note: current means target 2024-09-20 10:02:14 -07:00
README.md

README.md

For more information about how rustc works, see the rustc dev guide.