Auto merge of #156078 - JonathanBrouwer:rollup-WF8BsN3, r=JonathanBrouwer

Rollup of 9 pull requests

Successful merges:

 - rust-lang/rust#156030 (Make stable hashing names consistent (part 1))
 - rust-lang/rust#156020 (Improve source code for `librustdoc/visit_ast.rs`)
 - rust-lang/rust#156021 (Clean up some traits)
 - rust-lang/rust#156028 (Add a `Local::arg(i)` helper constructor)
 - rust-lang/rust#156037 (Add AcceptContext::expect_no_args)
 - rust-lang/rust#156040 (Add missing alias to mailmap)
 - rust-lang/rust#156048 (Make `diverging_type_vars` a vec of `TyVid`)
 - rust-lang/rust#156053 (Reuse CTFE MIR for constructors.)
 - rust-lang/rust#156059 (compiler: Print valid `-Zmir-enable-passes` names if invalid name is used)

Failed merges:

 - rust-lang/rust#155940 (refactor rustc_on_unimplemented's filtering)
 - rust-lang/rust#156065 (Remove unused spans from AttributeKind)

Author: bors

src/queries/incremental-compilation-in-detail.md

@@ -264,7 +264,7 @@ the `LocalId`s within it are still the same.
 
 
 
-### Checking query results for changes: `HashStable` and `Fingerprint`s
+### Checking query results for changes: `StableHash` and `Fingerprint`s
 
 In order to do red-green-marking we often need to check if the result of a
 query has changed compared to the result it had during the previous compilation session.
@@ -285,7 +285,7 @@ We call this hash value "the `Fingerprint` of the query result".
 The hashing is (and has to be) done "in a stable way".
 This means that whenever something is hashed that might change in between compilation
 sessions (e.g. a `DefId`), we instead hash its stable equivalent
-(e.g. the corresponding `DefPath`). That's what the whole `HashStable`
+(e.g. the corresponding `DefPath`). That's what the whole `StableHash`
 infrastructure is for.
 This way `Fingerprint`s computed in two different compilation sessions are still comparable.