Auto merge of #158184 - JonathanBrouwer:rollup-ABE3nZj, r=JonathanBrouwer

Rollup of 3 pull requests

Successful merges:

 - #158137 (Only copy visible content in clipboard in source code pages)
 - #158141 ([AArch64] FEAT_SVE implies FEAT_FP16)
 - #158177 (rustc-dev-guide subtree update)

Author: bors

compiler/rustc_target/src/target_features.rs

@@ -354,7 +354,7 @@ static AARCH64_FEATURES: &[(&str, Stability, ImpliedFeatures)] = &[
     // exist together: https://developer.arm.com/documentation/102340/0100/New-features-in-SVE2
     //
     // "For backwards compatibility, Neon and VFP are required in the latest architectures."
-    ("sve", Stable, &["neon"]),
+    ("sve", Stable, &["neon", "fp16"]),
     // FEAT_SVE_B16B16 (SVE or SME Z-targeting instructions)
     ("sve-b16b16", Unstable(sym::aarch64_unstable_target_feature), &["bf16"]),
     // FEAT_SVE2

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

@@ -315,3 +315,10 @@ html comment closing
 ";
     assert_eq!(expected, lengthen_lines(original, 50));
 }
+
+#[test]
+#[ignore]
+fn should_pass() {
+    let original = "if you see `input isn't interesting! verify interesting-ness test`.";
+    assert_eq!(original, comply(original));
+}

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

@@ -1 +1 @@
-49b19d32b9f01a5aa606f3bf2e90e6e0aa462c03
+8c75e93c5c7671c29f3e8c096b7acf56822ed23a

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

@@ -35,6 +35,7 @@
         - [Cranelift codegen backend](./tests/codegen-backend-tests/cg_clif.md)
         - [GCC codegen backend](./tests/codegen-backend-tests/cg_gcc.md)
     - [Performance testing](./tests/perf.md)
+    - [Pre-stabilization CI job for the next solver and polonius alpha](./tests/x86_64-gnu-next-trait-solver-polonius-ci-job.md)
     - [Misc info](./tests/misc.md)
 - [Debugging the compiler](./compiler-debugging.md)
     - [Using the tracing/logging instrumentation](./tracing.md)
@@ -129,6 +130,7 @@
     - [Lang Items](./lang-items.md)
 - [The HIR (High-level IR)](./hir.md)
     - [Lowering AST to HIR](./hir/lowering.md)
+    - [Attribute Parsing](./hir/attribute-parsing.md)
     - [Debugging](./hir/debugging.md)
 - [Ambig/Unambig Types and Consts](./ambig-unambig-ty-and-consts.md)
 - [The THIR (Typed High-level IR)](./thir.md)

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

@@ -5,46 +5,55 @@ Attributes come in two types: *inert* (or *built-in*) and *active* (*non-builtin
 ## Builtin/inert attributes
 
 These attributes are defined in the compiler itself, in
-[`compiler/rustc_feature/src/builtin_attrs.rs`][builtin_attrs].
+[`compiler/rustc_feature/src/builtin_attrs.rs`][builtin_attrs] and in the [attribute parsers][attr_parsing].
 
 Examples include `#[allow]` and `#[macro_use]`.
 
 [builtin_attrs]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_feature/builtin_attrs/index.html
+[attr_parsing]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_attr_parsing/index.html
 
 These attributes have several important characteristics:
 * They are always in scope, and do not participate in typical path-based resolution.
-* They cannot be renamed. For example, `use allow as foo` will compile, but writing `#[foo]` will
-  produce an error.
+* They cannot be renamed.
+  For example, `use allow as foo` will compile, but writing `#[foo]` will produce an error.
 * They are 'inert', meaning they are left as-is by the macro expansion code.
   As a result, any behavior comes as a result of the compiler explicitly checking for their presence.
   For example, lint-related code explicitly checks for `#[allow]`, `#[warn]`, `#[deny]`, and
   `#[forbid]`, rather than the behavior coming from the expansion of the attributes themselves.
 
+For more information on these attributes, see the chapter about [attribute parsing][attr-parsing-chapter].
+
+[attr-parsing-chapter]: ./hir/attribute-parsing.md
+
 ## 'Non-builtin'/'active' attributes
 
 These attributes are defined by a crate - either the standard library, or a proc-macro crate.
 
 **Important**: Many non-builtin attributes, such as `#[derive]`, are still considered part of the
-core Rust language. However, they are **not** called 'builtin attributes', since they have a
+core Rust language.
+However, they are **not** called 'builtin attributes', since they have a
 corresponding definition in the standard library.
 
 Definitions of non-builtin attributes take two forms:
 
 1. Proc-macro attributes, defined via a function annotated with `#[proc_macro_attribute]` in a
    proc-macro crate.
-2. AST-based attributes, defined in the standard library. These attributes have special 'stub'
+2. AST-based attributes, defined in the standard library.
+   These attributes have special 'stub'
    macros defined in places like [`library/core/src/macros/mod.rs`][core_macros].
 
 [core_macros]:  https://github.com/rust-lang/rust/blob/HEAD/library/core/src/macros/mod.rs
 
 These definitions exist to allow the macros to participate in typical path-based resolution - they
-can be imported, re-exported, and renamed just like any other item definition. However, the body of
-the definition is empty. Instead, the macro is annotated with the `#[rustc_builtin_macro]`
+can be imported, re-exported, and renamed just like any other item definition.
+However, the body of the definition is empty.
+Instead, the macro is annotated with the `#[rustc_builtin_macro]`
 attribute, which tells the compiler to run a corresponding function in `rustc_builtin_macros`.
 
 All non-builtin attributes have the following characteristics:
 * Like all other definitions (e.g. structs), they must be brought into scope via an import.
   Many standard library attributes are included in the prelude - this is why writing `#[derive]`
   works without an import.
-* They participate in macro expansion. The implementation of the macro may leave the attribute
+* They participate in macro expansion.
+  The implementation of the macro may leave the attribute
   target unchanged, modify the target, produce new AST nodes, or remove the target entirely.