[REBASEME] rustc_target: move comment to macro

Author: tamird

compiler/rustc_target/src/lib.rs

@@ -135,6 +135,14 @@ macro_rules! target_spec_enum {
                 $( #[$variant_attr:meta] )*
                 $Variant,
             )*
+            /// The vast majority of the time, the compiler deals with a fixed
+            /// set of values, so it is convenient for them to be represented in
+            /// an enum. However, it is possible to have arbitrary values in a
+            /// target JSON file (which can be parsed when `--target` is
+            /// specified). This might occur, for example, for an out-of-tree
+            /// codegen backend that supports a value that rustc currently
+            /// doesn't know about. This variant exists as an escape hatch for
+            /// such cases.
             $( #[$other_variant_attr] )*
             $OtherVariant(crate::spec::StaticCow<str>),
         }

compiler/rustc_target/src/spec/mod.rs

@@ -1881,13 +1881,6 @@ crate::target_spec_enum! {
         X86_64 = "x86_64",
         Xtensa = "xtensa",
     }
-    /// The vast majority of the time, the compiler deals with a fixed set of
-    /// target architectures, so it is convenient for them to be represented in
-    /// an enum. However, it is possible to have arbitrary values for the "arch"
-    /// field in a target JSON file (which can be parsed when `--target` is
-    /// specified). This might occur, for example, for an out-of-tree codegen
-    /// backend that supports an architecture that rustc currently doesn't know
-    /// about. This variant exists as an escape hatch for such cases.
     other_variant = Unknown;
 }
 
@@ -1981,14 +1974,6 @@ crate::target_spec_enum! {
         Zkvm = "zkvm",
         Unknown = "unknown",
     }
-    /// The vast majority of the time, the compiler deals with a fixed set of
-    /// target operating systems, so it is convenient for them to be represented
-    /// in an enum. However, it is possible to have arbitrary values for the
-    /// "os" field in a target JSON file (which can be parsed when `--target` is
-    /// specified). This might occur, for example, for an out-of-tree codegen
-    /// backend that supports an operating system that rustc currently doesn't
-    /// know about. This variant exists as an escape hatch for such cases.
-    ///
     /// Unlike [`Arch::Unknown`], [`Env::Unknown`], and [`Vendor::Unknown`],
     /// [`Os::Other`] is not named "unknown" because "unknown" is a an actual
     /// value that the compiler is aware of.
@@ -2062,13 +2047,6 @@ crate::target_spec_enum! {
         Win7 = "win7",
         Wrs = "wrs",
     }
-    /// The vast majority of the time, the compiler deals with a fixed set of
-    /// target vendors, so it is convenient for them to be represented in an
-    /// enum. However, it is possible to have arbitrary values for the "vendor"
-    /// field in a target JSON file (which can be parsed when `--target` is
-    /// specified). This might occur, for example, for an out-of-tree codegen
-    /// backend that supports a vendor that rustc currently doesn't know about.
-    /// This variant exists as an escape hatch for such cases.
     other_variant = Unknown;
 }
 
@@ -2101,13 +2079,6 @@ crate::target_spec_enum! {
         X32 = "x32",
         Unspecified = "",
     }
-    /// The vast majority of the time, the compiler deals with a fixed set of
-    /// target ABIs, so it is convenient for them to be represented in an enum.
-    /// However, it is possible to have arbitrary values for the "abi" field in
-    /// a target JSON file (which can be parsed when `--target` is specified).
-    /// This might occur, for example, for an out-of-tree codegen backend that
-    /// supports an ABI that rustc currently doesn't know about. This variant
-    /// exists as an escape hatch for such cases.
     other_variant = Unknown;
 }