rustc-dev-guide subtree update

src/doc/rustc-dev-guide/.github/workflows/ci.yml

@@ -7,7 +7,7 @@ on:
   pull_request:
   schedule:
     # Run multiple times a day as the successfull cached links are not checked every time.
-    - cron: '0 */8 * * *'
+    - cron: "0 */8 * * *"
 
 jobs:
   ci:
@@ -83,16 +83,6 @@ jobs:
           git commit -m "Deploy ${GITHUB_SHA} to gh-pages"
           git push --quiet -f "https://x-token:${{ secrets.GITHUB_TOKEN }}@github.com/${GITHUB_REPOSITORY}" HEAD:gh-pages
 
-      - name: Cache sembr build
-        uses: actions/cache@v4
-        with:
-          path: |
-            ~/.cargo/registry/index/
-            ~/.cargo/registry/cache/
-            ~/.cargo/git/db/
-            ci/sembr/target/
-          key: sembr-${{ hashFiles('ci/sembr/Cargo.lock') }}
-
       - name: Check if files comply with semantic line breaks
         continue-on-error: true
         run: |

src/doc/rustc-dev-guide/README.md

@@ -1,42 +1,42 @@
 [![CI](https://github.com/rust-lang/rustc-dev-guide/actions/workflows/ci.yml/badge.svg)](https://github.com/rust-lang/rustc-dev-guide/actions/workflows/ci.yml)
 
-
-This is a collaborative effort to build a guide that explains how rustc
-works. The aim of the guide is to help new contributors get oriented
-to rustc, as well as to help more experienced folks in figuring out
+This is a collaborative effort to build a guide that explains how rustc works.
+The aim of the guide is to help new contributors get oriented to rustc,
+as well as to help more experienced folks in figuring out
 some new part of the compiler that they haven't worked on before.
 
-[You can read the latest version of the guide here.](https://rustc-dev-guide.rust-lang.org/)
+You may also find the [rustc API docs] useful.
 
-You may also find the rustdocs [for the compiler itself][rustdocs] useful.
 Note that these are not intended as a guide; it's recommended that you search
 for the docs you're looking for instead of reading them top to bottom.
 
-[rustdocs]: https://doc.rust-lang.org/nightly/nightly-rustc
-
 For documentation on developing the standard library, see
 [`std-dev-guide`](https://std-dev-guide.rust-lang.org/).
 
 ### Contributing to the guide
 
 The guide is useful today, but it has a lot of work still to go.
 
-If you'd like to help improve the guide, we'd love to have you! You can find
-plenty of issues on the [issue
-tracker](https://github.com/rust-lang/rustc-dev-guide/issues). Just post a
-comment on the issue you would like to work on to make sure that we don't
-accidentally duplicate work. If you think something is missing, please open an
-issue about it!
+If you'd like to help improve the guide, we'd love to have you!
+You can find plenty of issues on the [issue
+tracker](https://github.com/rust-lang/rustc-dev-guide/issues).
+Just post a comment on the issue you would like to work on to make sure that we don't
+accidentally duplicate work.
+If you think something is missing, please open an issue about it!
 
 **In general, if you don't know how the compiler works, that is not a
 problem!** In that case, what we will do is to schedule a bit of time
 for you to talk with someone who **does** know the code, or who wants
-to pair with you and figure it out.  Then you can work on writing up
-what you learned.
+to pair with you and figure it out.
+Then you can work on writing up what you learned.
 
 In general, when writing about a particular part of the compiler's code, we
-recommend that you link to the relevant parts of the [rustc
-rustdocs][rustdocs].
+recommend that you link to the relevant parts of the [rustc API docs].
+
+The guide has a much lower bar for what it takes for a PR to be merged.
+Check out the forge documentation for [our policy][forge_policy].
+
+[forge_policy]: https://forge.rust-lang.org/rustc-dev-guide/index.html#review-policy
 
 ### Build Instructions
 
@@ -56,9 +56,9 @@ The build files are found in the `book/html` directory.
 
 ### Link Validations
 
-We use `mdbook-linkcheck2` to validate URLs included in our documentation. Link
-checking is **not** run by default locally, though it is in CI. To enable it
-locally, set the environment variable `ENABLE_LINKCHECK=1` like in the
+We use `mdbook-linkcheck2` to validate URLs included in our documentation.
+Link checking is **not** run by default locally, though it is in CI.
+To enable it locally, set the environment variable `ENABLE_LINKCHECK=1` like in the
 following example.
 
 ```
@@ -67,6 +67,9 @@ ENABLE_LINKCHECK=1 mdbook serve
 
 ## Synchronizing josh subtree with rustc
 
-This repository is linked to `rust-lang/rust` as a [josh](https://josh-project.github.io/josh/intro.html) subtree. You can use the [rustc-josh-sync](https://github.com/rust-lang/josh-sync) tool to perform synchronization.
+This repository is linked to `rust-lang/rust` as a [josh](https://josh-project.github.io/josh/intro.html) subtree.
+You can use the [rustc-josh-sync](https://github.com/rust-lang/josh-sync) tool to perform synchronization.
 
 You can find a guide on how to perform the synchronization [here](./src/external-repos.md#synchronizing-a-josh-subtree).
+
+[rustc API docs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle

src/doc/rustc-dev-guide/ci/sembr/src/main.rs

@@ -177,6 +177,9 @@ fn lengthen_lines(content: &str, limit: usize) -> String {
         let Some(next_line) = content.get(n + 1) else {
             continue;
         };
+        if next_line.trim_start().starts_with("```") {
+            continue;
+        }
         if ignore(next_line, in_code_block)
             || REGEX_LIST_ENTRY.is_match(next_line)
             || REGEX_IGNORE_END.is_match(line)
@@ -255,6 +258,12 @@ preserve next line
 
 preserve next line
 * three
+
+do not mess with code block chars
+```
+leave the
+text alone
+```
 ";
     let expected = "\
 do not split short sentences
@@ -269,6 +278,12 @@ preserve next line
 
 preserve next line
 * three
+
+do not mess with code block chars
+```
+leave the
+text alone
+```
 ";
     assert_eq!(expected, lengthen_lines(original, 50));
 }
@@ -294,40 +309,6 @@ fn test_prettify_ignore_link_targets() {
     assert_eq!(original, lengthen_lines(original, 100));
 }
 
-#[test]
-fn test_sembr_then_prettify() {
-    let original = "
-hi there. do
-not split
-short sentences.
-hi again.
-";
-    let expected = "
-hi there.
-do
-not split
-short sentences.
-hi again.
-";
-    let processed = comply(original);
-    assert_eq!(expected, processed);
-    let expected = "
-hi there.
-do not split
-short sentences.
-hi again.
-";
-    let processed = lengthen_lines(&processed, 50);
-    assert_eq!(expected, processed);
-    let expected = "
-hi there.
-do not split short sentences.
-hi again.
-";
-    let processed = lengthen_lines(&processed, 50);
-    assert_eq!(expected, processed);
-}
-
 #[test]
 fn test_sembr_question_mark() {
     let original = "

src/doc/rustc-dev-guide/rust-version

@@ -1 +1 @@
-dfe1b8c97bcde283102f706d5dcdc3649e5e12e3
+cec70080fd441d16e9fb08a0d1d1a04c72d1ed25

src/doc/rustc-dev-guide/src/SUMMARY.md

@@ -66,6 +66,7 @@
     - [ARM](notification-groups/arm.md)
     - [Emscripten](notification-groups/emscripten.md)
     - [Fuchsia](notification-groups/fuchsia.md)
+    - [LoongArch](notification-groups/loongarch.md)
     - [RISC-V](notification-groups/risc-v.md)
     - [Rust for Linux](notification-groups/rust-for-linux.md)
     - [WASI](notification-groups/wasi.md)
@@ -126,8 +127,8 @@
     - [Lang Items](./lang-items.md)
 - [The HIR (High-level IR)](./hir.md)
     - [Lowering AST to HIR](./hir/lowering.md)
-    - [Ambig/Unambig Types and Consts](./hir/ambig-unambig-ty-and-consts.md)
     - [Debugging](./hir/debugging.md)
+- [Ambig/Unambig Types and Consts](./ambig-unambig-ty-and-consts.md)
 - [The THIR (Typed High-level IR)](./thir.md)
 - [The MIR (Mid-level IR)](./mir/index.md)
     - [MIR construction](./mir/construction.md)
@@ -185,12 +186,14 @@
         - [Proof trees](./solve/proof-trees.md)
         - [Opaque types](./solve/opaque-types.md)
         - [Significant changes and quirks](./solve/significant-changes.md)
+        - [Sharing the trait solver with rust-analyzer](./solve/sharing-crates-with-rust-analyzer.md)
     - [`Unsize` and `CoerceUnsized` traits](./traits/unsize.md)
 - [Variance](./variance.md)
 - [Coherence checking](./coherence.md)
 - [HIR Type checking](./hir-typeck/summary.md)
     - [Coercions](./hir-typeck/coercions.md)
     - [Method lookup](./hir-typeck/method-lookup.md)
+- [Const Generics](./const-generics.md)
 - [Opaque types](./opaque-types-type-alias-impl-trait.md)
     - [Inference details](./opaque-types-impl-trait-inference.md)
     - [Return Position Impl Trait In Trait](./return-position-impl-trait-in-trait.md)
@@ -230,11 +233,22 @@
     - [Debugging LLVM](./backend/debugging.md)
     - [Backend Agnostic Codegen](./backend/backend-agnostic.md)
     - [Implicit caller location](./backend/implicit-caller-location.md)
+- [Debug Info](./debuginfo/intro.md)
+    - [Rust Codegen](./debuginfo/rust-codegen.md)
+    - [LLVM Codegen](./debuginfo/llvm-codegen.md)
+    - [Debugger Internals](./debuginfo/debugger-internals.md)
+        - [LLDB Internals](./debuginfo/lldb-internals.md)
+        - [GDB Internals](./debuginfo/gdb-internals.md)
+    - [Debugger Visualizers](./debuginfo/debugger-visualizers.md)
+        - [LLDB - Python Providers](./debuginfo/lldb-visualizers.md)
+        - [GDB - Python Providers](./debuginfo/gdb-visualizers.md)
+        - [CDB - Natvis](./debuginfo/natvis-visualizers.md)
+    - [Testing](./debuginfo/testing.md)
+    - [(Lecture Notes) Debugging support in the Rust compiler](./debugging-support-in-rustc.md)
 - [Libraries and metadata](./backend/libs-and-metadata.md)
 - [Profile-guided optimization](./profile-guided-optimization.md)
 - [LLVM source-based code coverage](./llvm-coverage-instrumentation.md)
 - [Sanitizers support](./sanitizers.md)
-- [Debugging support in the Rust compiler](./debugging-support-in-rustc.md)
 
 ---
 

src/doc/rustc-dev-guide/src/about-this-guide.md

@@ -58,21 +58,24 @@ please see the corresponding [subsection on writing documentation in this guide]
 
 [subsection on writing documentation in this guide]: contributing.md#contributing-to-rustc-dev-guide
 
-> “‘All conditioned things are impermanent’ — 
+> “‘All conditioned things are impermanent’ —
 > when one sees this with wisdom, one turns away from suffering.”
 > _The Dhammapada, verse 277_
 
 ## Other places to find information
 
+This guide, the one you are currently reading,
+contains information about how various parts of the compiler work,
+and how to contribute to the compiler.
+
 You might also find the following sites useful:
 
-- This guide contains information about how various parts of the
-  compiler work and how to contribute to the compiler.
 - [rustc API docs] -- rustdoc documentation for the compiler, devtools, and internal tools
 - [Forge] -- contains documentation about Rust infrastructure, team procedures, and more
 - [compiler-team] -- the home-base for the Rust compiler team, with description
   of the team procedures, active working groups, and the team calendar.
 - [std-dev-guide] -- a similar guide for developing the standard library.
+- [rust-analyzer book] -- documentation for the rust-analyzer.
 - [The t-compiler Zulip][z]
 - The [Rust Internals forum][rif], a place to ask questions and
   discuss Rust's internals
@@ -110,4 +113,5 @@ You might also find the following sites useful:
 [Forge]: https://forge.rust-lang.org/
 [compiler-team]: https://github.com/rust-lang/compiler-team/
 [std-dev-guide]: https://std-dev-guide.rust-lang.org/
+[rust-analyzer book]: https://rust-analyzer.github.io/book/
 [z]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler

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

@@ -0,0 +1,111 @@
+# 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.
+
+```rust
+fn func<T, const N: usize>(arg: T) {
+    //                           ^ Unambig type position
+    let a: _ = arg; 
+    //     ^ Unambig type position
+
+    func::<T, N>(arg);
+    //     ^  ^
+    //     ^^^^ Ambig position 
+
+    let _: [u8; 10];
+    //      ^^  ^^ Unambig const position
+    //      ^^ Unambig type position
+}
+
+```
+
+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
+
+```rust
+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)`].
+
+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.
+
+See [`LoweringContext::lower_generic_arg`] for where this is implemented.
+
+Note that the ambiguity for paths is not propgated into the HIR; there's no `hir::GenericArg::Path` which is turned into either a `Ty` or `Const` during HIR ty lowering (though we could do such a thing).
+
+## Inferred arguments (`_`)
+
+```rust
+struct Foo<const N: usize>;
+
+fn foo() {
+    let _unused: 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.
+
+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 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.
+
+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.
+
+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`
+2. In unambig const arg position as a `ConstArgKind::Infer`
+3. In an ambig position as a [`GenericArg::Type(TyKind::Infer)`][generic_arg_ty]
+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. 
+
+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.
+- People may write visitors which check for `TyKind/ConstArgKind::Infer` but forget to check for `GenericArg::Infer`, only handling infers in unambig positions by accident.
+- People may write visitors which check for `GenericArg::Type/Const(TyKind/ConstArgKind::Infer)` and `GenericArg::Infer`, not realising that we never represent inferred types/consts in ambig positions as a `GenericArg::Type/Const`.
+- People may write visitors which check for *only* `TyKind::Infer` and not `ConstArgKind::Infer` forgetting that there are also inferred const arguments (and vice versa).
+
+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.
+
+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 
+- 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
+[const_infer]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.ConstArgKind.html#variant.Infer
+[generic_arg_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.GenericArg.html#variant.Type
+[generic_arg_const]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.GenericArg.html#variant.Const
+[generic_arg_infer]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.GenericArg.html#variant.Infer
+[ambig_arg]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.AmbigArg.html
+[visit_ty]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/intravisit/trait.Visitor.html#method.visit_ty
+[visit_const_arg]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/intravisit/trait.Visitor.html#method.visit_const_arg
+[visit_infer]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/intravisit/trait.Visitor.html#method.visit_infer
+[`LateResolutionVisitor::visit_generic_arg`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.LateResolutionVisitor.html#method.visit_generic_arg
+[`LoweringContext::lower_generic_arg`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast_lowering/struct.LoweringContext.html#method.lower_generic_arg
+[`ast::GenericArg::Ty`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/enum.GenericArg.html#variant.Type
+[`ast::Ty::Infer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/enum.TyKind.html#variant.Infer
+[`ast::AnonConst`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/struct.AnonConst.html
+[`hir::GenericArg::Infer`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.GenericArg.html#variant.Infer
+[`ast::ExprKind::Underscore`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/enum.ExprKind.html#variant.Underscore
+[`ast::Ty::Path(N)`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ast/ast/enum.TyKind.html#variant.Path