From f41144c647f4fdeb3cc64bda53f34d50beb34960 Mon Sep 17 00:00:00 2001 From: khyperia <953151+khyperia@users.noreply.github.com> Date: Fri, 25 Sep 2026 13:04:03 +0200 Subject: [PATCH 1/3] rename GCA features --- src/const-generics.md | 6 +++--- src/normalization.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/const-generics.md b/src/const-generics.md index 9e26a174d8..74e78aab14 100644 --- a/src/const-generics.md +++ b/src/const-generics.md @@ -81,7 +81,7 @@ type Alias = [u8; ANON]; When we go through HIR ty lowering for the array type in `Alias`, we will lower the array length too, and feed `type_of(ANON) -> usize`. This will effectively set the type of the `ANON` const item during some later part of the compiler rather than when constructing the HIR. -After all of this desugaring has taken place the final representation in the type system (ie as a `ty::Const`) is a `ConstKind::Unevaluated` with the `DefId` of the `AnonConst`. This is equivalent to how we would representa a usage of an actual const item if we were to represent them without going through an anon const (e.g. when `min_generic_const_args` is enabled). +After all of this desugaring has taken place the final representation in the type system (ie as a `ty::Const`) is a `ConstKind::Unevaluated` with the `DefId` of the `AnonConst`. This is equivalent to how we would representa a usage of an actual const item if we were to represent them without going through an anon const (e.g. when `gca_min_const_items` is enabled). This allows the representation for const "aliases" to be the same as the representation of `TyKind::Alias`. Having a proper HIR body also allows for a *lot* of code re-use, e.g. we can reuse HIR typechecking and all of the lowering steps to MIR where we can then reuse const eval. @@ -141,7 +141,7 @@ In some sense we only allow generic parameters here when they are semantically u In the previous example the anon const can be evaluated for any type parameter `T` because raw pointers to sized types always have the same size (e.g. `8` on 64bit platforms). When detecting that we evaluated an anon const that syntactically contained generic parameters, but did not actually depend on them for evaluation to succeed, we emit the [`const_evaluatable_unchecked` FCW][cec_fcw]. -This is intended to become a hard error once we stabilize more ways of using generic parameters in const arguments, for example `min_generic_const_args` or (the now dead) `generic_const_exprs`. +This is intended to become a hard error once we stabilize more ways of using generic parameters in const arguments, for example `gca_min_const_items` or (the now dead) `generic_const_exprs`. The implementation for this FCW can be found here: [`const_eval_resolve_for_typeck`] @@ -182,7 +182,7 @@ It is currently unclear what the right way to make `generic_const_parameter_type `generic_const_exprs` would have allowed for anon consts with types referencing generic parameters, but that design wound up unworkable. -`min_generic_const_args` will allow for some expressions (for example array construction) to be representable without an anon const and therefore without running into these issues, though whether this is *enough* has yet to be determined. +`gca_min_const_items` will allow for some expressions (for example array construction) to be representable without an anon const and therefore without running into these issues, though whether this is *enough* has yet to be determined. ## Checking types of const arguments diff --git a/src/normalization.md b/src/normalization.md index 05484a672a..cefd92999d 100644 --- a/src/normalization.md +++ b/src/normalization.md @@ -155,7 +155,7 @@ fn bar() { ``` This is likely to change as const generics functionality is improved. -For example, `feature(associated_const_equality)` and `feature(min_generic_const_args)` both require handling const aliases similarly to types (without an anonymous constant wrapping all const args). +For example, `feature(associated_const_equality)` and `feature(gca_min_const_items)` both require handling const aliases similarly to types (without an anonymous constant wrapping all const args). ## What is normalization From b09a3e2cf7215a4204032f81bcf44219e4e6498e Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Mon, 28 Sep 2026 10:31:49 +0200 Subject: [PATCH 2/3] do not complain about unstable target features on nightly --- src/tests/misc.md | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/src/tests/misc.md b/src/tests/misc.md index 34f9faa9cc..8fe49c82e9 100644 --- a/src/tests/misc.md +++ b/src/tests/misc.md @@ -12,15 +12,10 @@ This is a bootstrap/compiler implementation detail, but it can also be useful fo This is useful because some behaviors of the compiler (e.g. diagnostics) can differ depending on whether the compiler is nightly or not. -In `ui` tests and other test suites that support `//@ rustc-env`, you can specify - -```rust,ignore -// Force unstable features to be usable on stable rustc -//@ rustc-env:RUSTC_BOOTSTRAP=1 - -// Or force nightly rustc to pretend it is a stable rustc -//@ rustc-env:RUSTC_BOOTSTRAP=-1 -``` +Note that setting `RUSTC_BOOTSTRAP` in ui tests (e.g. via `//@ rustc-env`) is pointless since ui +tests inherit the bootstrap env var from bootstrap (so it's set to `1` by default), and since +compiletest itself passes `-Z` flags (so `-1` breaks the test). To test stable-only behavior, you +need to write a `run-make` test instead. For `run-make`/`run-make-cargo` tests, `//@ rustc-env` is not supported. You can do something like the following for individual `rustc` invocations. From a9048bb0ad36a3ab457f89163630d5c152c9f937 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Wed, 30 Sep 2026 11:10:08 +0200 Subject: [PATCH 3/3] Prepare for merging from rust-lang/rust This updates the rust-version file to 7d2cd0fbc092625ea371da704f15f80216d2220e. --- rust-version | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rust-version b/rust-version index 6b9ce9470f..af092f4d34 100644 --- a/rust-version +++ b/rust-version @@ -1 +1 @@ -56fad885ebfb0447660870715da4dfa75deae93d +7d2cd0fbc092625ea371da704f15f80216d2220e