rustc-dev-guide subtree update

src/doc/rustc-dev-guide/src/ambig-unambig-ty-and-consts.md

@@ -1,18 +1,18 @@
 # Ambig/Unambig Types and Consts
 
-Types and Consts args in the AST/HIR can be in two kinds of positions ambiguous (ambig) or unambiguous (unambig). Ambig positions are where
-it would be valid to parse either a type or a const, unambig positions are where only one kind would be valid to
-parse.
+Types and Consts args in the AST/HIR can be in two kinds of positions ambiguous (ambig) or unambiguous (unambig).
+Ambig positions are where it would be valid to parse either a type or a const.
+Unambig positions are where only one kind would be valid to parse.
 
 ```rust
 fn func<T, const N: usize>(arg: T) {
     //                          ^ Unambig type position
-    let a: _ = arg; 
+    let a: _ = arg;
     //     ^ Unambig type position
 
     func::<T, N>(arg);
     //     ^  ^
-    //     ^^^^ Ambig position 
+    //     ^^^^ Ambig position
 
     let _: [u8; 10];
     //      ^^  ^^ Unambig const position
@@ -21,7 +21,8 @@ fn func<T, const N: usize>(arg: T) {
 
 ```
 
-Most types/consts in ambig positions are able to be disambiguated as either a type or const during parsing. The only exceptions to this are paths and inferred generic arguments.
+Most types/consts in ambig positions are able to be disambiguated as either a type or const during parsing.
+The only exceptions to this are paths and inferred generic arguments.
 
 ## Paths
 
@@ -31,15 +32,17 @@ struct Foo<const N: usize>;
 fn foo<const N: usize>(_: Foo<N>) {}
 ```
 
-At parse time we parse all unbraced generic arguments as *types* (ie they wind up as [`ast::GenericArg::Ty`]). In the above example this means we would parse the generic argument to `Foo` as an `ast::GenericArg::Ty` wrapping a [`ast::Ty::Path(N)`].
+At parse time we parse all unbraced generic arguments as *types* (ie they wind up as [`ast::GenericArg::Ty`]).
+In the above example this means we would parse the generic argument to `Foo` as an `ast::GenericArg::Ty` wrapping a [`ast::Ty::Path(N)`].
 
 Then during name resolution:
 - When encountering a single segment path with no generic arguments in generic argument position, we will first try to resolve it in the type namespace and if that fails we then attempt to resolve in the value namespace.
 - All other kinds of paths we only try to resolve in the type namespace
 
 See [`LateResolutionVisitor::visit_generic_arg`] for where this is implemented.
 
-Finally during AST lowering when we attempt to lower a type argument, we first check if it is a `Ty::Path` and if it resolved to something in the value namespace. If it did then we create an *anon const* and lower to a const argument instead of a type argument.
+Finally during AST lowering when we attempt to lower a type argument, we first check if it is a `Ty::Path` and if it resolved to something in the value namespace.
+If it did, then we create an *anon const* and lower to a const argument instead of a type argument.
 
 See [`LoweringContext::lower_generic_arg`] for where this is implemented.
 
@@ -55,16 +58,26 @@ fn foo() {
 }
 ```
 
-The only generic arguments which remain ambiguous after lowering are inferred generic arguments (`_`) in path segments. In the above example it is not clear at parse time whether the `_` argument to `Foo` is an inferred type argument, or an inferred const argument.
+The only generic arguments which remain ambiguous after lowering are inferred generic arguments (`_`) in path segments.
+In the above example,
+it is not clear at parse time whether the `_` argument to `Foo` is an inferred type argument,
+or an inferred const argument.
 
-In ambig AST positions, inferred argumentsd are parsed as an [`ast::GenericArg::Ty`] wrapping a [`ast::Ty::Infer`]. Then during AST lowering when lowering an `ast::GenericArg::Ty` we check if it is an inferred type and if so lower to a [`hir::GenericArg::Infer`].
+In ambig AST positions, inferred arguments are parsed as an [`ast::GenericArg::Ty`] wrapping a [`ast::Ty::Infer`].
+Then, during AST lowering, when lowering an `ast::GenericArg::Ty`,
+we check if it is an inferred type, and if so, lower to a [`hir::GenericArg::Infer`].
 
-In unambig AST positions, inferred arguments are parsed as either `ast::Ty::Infer` or [`ast::AnonConst`]. The `AnonConst` case is quite strange, we use [`ast::ExprKind::Underscore`] to represent the "body" of the "anon const" although in reality we do not actually lower this to an anon const in the HIR.
+In unambig AST positions, inferred arguments are parsed as either `ast::Ty::Infer` or [`ast::AnonConst`].
+The `AnonConst` case is quite strange;
+we use [`ast::ExprKind::Underscore`] to represent the "body" of the "anon const",
+although in reality we do not actually lower this to an anon const in the HIR.
 
-It may be worth seeing if we can refactor the AST to have `ast::GenericArg::Infer` and then get rid of this overloaded meaning of `AnonConst`, as well as the reuse of `ast::Ty::Infer` in ambig positions.
+It may be worth seeing if we can refactor the AST to have `ast::GenericArg::Infer` and then get rid of this overloaded meaning of `AnonConst`,
+as well as the reuse of `ast::Ty::Infer` in ambig positions.
 
 In unambig AST positions, during AST lowering we lower inferred arguments to [`hir::TyKind::Infer`][ty_infer] or [`hir::ConstArgKind::Infer`][const_infer] depending on whether it is a type or const position respectively.
-In ambig AST positions, during AST lowering we lower inferred arguments to [`hir::GenericArg::Infer`][generic_arg_infer]. See [`LoweringContext::lower_generic_arg`] for where this is implemented.
+In ambig AST positions, during AST lowering we lower inferred arguments to [`hir::GenericArg::Infer`][generic_arg_infer].
+See [`LoweringContext::lower_generic_arg`] for where this is implemented.
 
 A naive implementation of this would result in there being potentially 5 places where you might think an inferred type/const could be found in the HIR from looking at the structure of the HIR:
 1. In unambig type position as a `TyKind::Infer`
@@ -73,7 +86,7 @@ A naive implementation of this would result in there being potentially 5 places
 4. In an ambig position as a [`GenericArg::Const(ConstArgKind::Infer)`][generic_arg_const]
 5. In an ambig position as a `GenericArg::Infer`
 
-Note that places 3 and 4 would never actually be possible to encounter as we always lower to `GenericArg::Infer` in generic arg position. 
+Note that places 3 and 4 would never actually be possible to encounter as we always lower to `GenericArg::Infer` in generic arg position.
 
 This has a few failure modes:
 - People may write visitors which check for `GenericArg::Infer` but forget to check for `hir::TyKind/ConstArgKind::Infer`, only handling infers in ambig positions by accident.
@@ -83,13 +96,15 @@ This has a few failure modes:
 
 To make writing HIR visitors less error prone when caring about inferred types/consts we have a relatively complex system:
 
-1. We have different types in the compiler for when a type or const is in an unambig or ambig position, `Ty<AmbigArg>` and `Ty<()>`. [`AmbigArg`][ambig_arg] is an uninhabited type which we use in the `Infer` variant of `TyKind` and `ConstArgKind` to selectively "disable" it if we are in an ambig position.
+1. We have different types in the compiler for when a type or const is in an unambig or ambig position, `Ty<AmbigArg>` and `Ty<()>`.
+   [`AmbigArg`][ambig_arg] is an uninhabited type which we use in the `Infer` variant of `TyKind` and `ConstArgKind` to selectively "disable" it if we are in an ambig position.
 
-2. The [`visit_ty`][visit_ty] and [`visit_const_arg`][visit_const_arg] methods on HIR visitors only accept the ambig position versions of types/consts. Unambig types/consts are implicitly converted to ambig types/consts during the visiting process, with the `Infer` variant handled by a dedicated [`visit_infer`][visit_infer] method.
+2. The [`visit_ty`][visit_ty] and [`visit_const_arg`][visit_const_arg] methods on HIR visitors only accept the ambig position versions of types/consts.
+   Unambig types/consts are implicitly converted to ambig types/consts during the visiting process, with the `Infer` variant handled by a dedicated [`visit_infer`][visit_infer] method.
 
 This has a number of benefits:
 - It's clear that `GenericArg::Type/Const` cannot represent inferred type/const arguments
-- Implementors of `visit_ty` and `visit_const_arg` will never encounter inferred types/consts making it impossible to write a visitor that seems to work right but handles edge cases wrong 
+- Implementors of `visit_ty` and `visit_const_arg` will never encounter inferred types/consts making it impossible to write a visitor that seems to work right but handles edge cases wrong
 - The `visit_infer` method handles *all* cases of inferred type/consts in the HIR making it easy for visitors to handle inferred type/consts in one dedicated place and not forget cases
 
 [ty_infer]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.TyKind.html#variant.Infer

src/doc/rustc-dev-guide/src/autodiff/installation.md

@@ -3,7 +3,7 @@
 Most users can enable `std::autodiff` on their latest nightly toolchain by installing the `enzyme` component with rustup, if they are using one of these platforms:
 
 - **Linux**: with `x86_64-unknown-linux-gnu` or `aarch64-unknown-linux-gnu`
-- **macOS**: with `aarch64-apple-darwin`
+- **macOS**: with `aarch64-apple-darwin` or `x86_64-apple-darwin`
 - **Windows**: with `x86_64-llvm-mingw` or `aarch64-llvm-mingw`
 
 As a rustc/enzyme/autodiff contributor, or if you need any other platform, you can build rustc including autodiff from source.
@@ -18,6 +18,12 @@ Please run:
 rustup +nightly component add enzyme
 ```
 
+Older rustup versions are not aware of this component, so if you run into issues try updating rustup itself:
+```console
+rustup update
+rustup +nightly component add enzyme
+```
+
 ## Installation guide for Nix
 
 On [Nix], you can declare a nightly Rust toolchain with the Enzyme component using the [oxalica rust-overlay].