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
..
check_consts	terminology: #[feature] *enables* a feature (instead of "declaring" or "activating" it)	2024-10-22 07:37:54 +01:00
const_eval	Auto merge of #130950 - compiler-errors:yeet-eval, r=BoxyUwU	2024-10-21 03:46:28 +00:00
interpret	Auto merge of #130950 - compiler-errors:yeet-eval, r=BoxyUwU	2024-10-21 03:46:28 +00:00
util	make InterpResult a dedicated type to avoid accidentally discarding the error	2024-10-01 21:45:35 +02:00
errors.rs	interpret errors: add map_err_kind, rename InterpError -> InterpErrorKind	2024-10-19 09:22:38 +02:00
lib.rs	move strict provenance lints to new feature gate, remove old feature gates	2024-10-21 15:22:17 +01:00