Rustc pull update

rust-version

@@ -1 +1 @@
-56fad885ebfb0447660870715da4dfa75deae93d
+7d2cd0fbc092625ea371da704f15f80216d2220e

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::Alias` 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::Alias` 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
 

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
 

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.