remove freeform component from LinkerFlavorCli

Author: lqd

compiler/rustc_codegen_ssa/src/back/link.rs

@@ -2696,28 +2696,28 @@ fn get_apple_sdk_root(sdk_name: &str) -> Result<String, String> {
 
 /// This takes care of the various possible enrichments to the linking that can be requested on the
 /// CLI (and emitting errors and warnings when applicable):
-/// - shortcuts to `-fuse-ld` with the `gcc` flavor
-/// - the unstable `-Zgcc-ld=lld` flag to use `rust-lld`, stabilized as the following item
+/// - the unstable `-Zgcc-ld=lld` flag to use `rust-lld`
+/// - the shortcut to `-fuse-ld=lld` with the `gcc` flavor, to eventually use `rust-lld` when
+///   `-Clink-self-contained=linker` is introduced.
 fn handle_cli_linker_flavors(
     cmd: &mut dyn Linker,
     sess: &Session,
     flavor: LinkerFlavor,
     crt_objects_fallback: bool,
 ) {
     let unstable_gcc_lld = sess.opts.unstable_opts.gcc_ld == Some(LdImpl::Lld);
-    if unstable_gcc_lld {
-        // Sanity check: ensure `gcc` is the currently selected flavor.
-        if LinkerFlavor::Gcc != flavor {
-            sess.fatal("`-Zgcc-ld` is used even though the linker flavor is not `gcc`");
-        }
+
+    // Sanity check: ensure `gcc` is the currently selected flavor.
+    if unstable_gcc_lld && LinkerFlavor::Gcc != flavor {
+        sess.fatal("`-Zgcc-ld` is used even though the linker flavor is not `gcc`");
     }
 
     let cg = &sess.opts.cg;
 
     // The `-C linker-flavor` CLI flag can optionally enrich linker-flavors. Check whether that's
     // applicable, and emit errors if sanity checks fail. There's currently only one enrichment:
-    // adding an argument to the `cc` invocation to use the `use_ld` given linker.
-    let use_ld = match &cg.linker_flavor {
+    // adding an argument to the `cc` invocation to use `lld`.
+    match &cg.linker_flavor {
         Some(LinkerFlavorCli::Gcc { use_ld }) => {
             // Ensure `gcc` is the currently selected flavor.
             //
@@ -2733,79 +2733,71 @@ fn handle_cli_linker_flavors(
                 );
             }
 
-            use_ld
+            if *use_ld != LdImpl::Lld {
+                // We're not in a situation needing enrichments.
+                return;
+            }
         }
 
-        // Note: exhaustive match arm here, to avoid fallthroughs if new linker-flavor enrichments
-        // are added in the future.
         Some(LinkerFlavorCli::WellKnown(_)) | None => {
-            if unstable_gcc_lld {
-                "lld"
-            } else {
+            if !unstable_gcc_lld {
                 // We're not in a situation needing enrichments.
                 return;
             }
         }
-    };
+    }
 
-    // From now on in this function, we handle the `gcc` linker-flavor enrichment.
+    // From now on in this function, we handle the `gcc` linker-flavor enrichment to use `lld`.
 
-    // Except for `lld`, the given linker executable will be passed straight to `-fuse-ld`.
-    if use_ld == "lld" {
-        // Start by checking if we're in the context of a known issue that users might hit when
-        // using `lld`:
-        //
-        // 1. when requesting self-contained CRT linking (or on a target that does it
-        // automatically), and coverage/profile generation: point at #79555 "Coverage is not
-        // generated when using rust-lld as linker"
-        let instrument_coverage = cg.instrument_coverage.is_some()
-            && cg.instrument_coverage != Some(InstrumentCoverage::Off);
-        let generate_profile = cg.profile_generate.enabled();
-        if crt_objects_fallback && (instrument_coverage || generate_profile) {
-            sess.warn(
-                "Using `lld`, self-contained linking, and coverage or profile generation has known \
-                issues. See issue #79555 for more details, at \
-                https://github.com/rust-lang/rust/issues/79555",
-            );
-        }
+    // Start by checking if we're in the context of a known issue that users might hit when
+    // using `lld`:
+    //
+    // 1. when requesting self-contained CRT linking (or on a target that does it
+    // automatically), and coverage/profile generation: point at #79555 "Coverage is not
+    // generated when using rust-lld as linker"
+    let instrument_coverage =
+        cg.instrument_coverage.is_some() && cg.instrument_coverage != Some(InstrumentCoverage::Off);
+    let generate_profile = cg.profile_generate.enabled();
+    if crt_objects_fallback && (instrument_coverage || generate_profile) {
+        sess.warn(
+            "Using `lld`, self-contained linking, and coverage or profile generation has known \
+            issues. See issue #79555 for more details, at \
+            https://github.com/rust-lang/rust/issues/79555",
+        );
+    }
 
-        // 2. Maybe point at https://github.com/flamegraph-rs/flamegraph/pull/157 or the
-        // corresponding rust/LLVM issue when/if it's tracked, depending on whether we use the
-        // workaround argument `--no-rosegment` by default when invoking `lld`.
-        //
-        // 3. If in the future, other linker flavors and targets are eligible to a `rust-lld`
-        // enrichment, maybe also point at target-specific issues like:
-        // - MSVC + ThinLTO blocker https://github.com/rust-lang/rust/issues/81408
-        // - the "lld on MSVC" tracking issue https://github.com/rust-lang/rust/issues/71520
-        //   containing a list of blocking issues
-
-        // Now, handle `rust-lld`. If the `-Zgcc-ld=lld` flag was provided, we use `rust-lld`, the
-        // rustup-distributed version of `lld` (when applicable, i.e. not in distro-builds) by:
-        // - checking the `lld-wrapper`s exist in the sysroot
-        // - adding their folder as a search path, or requesting to use a wrapper directly
-        if unstable_gcc_lld {
-            // A `gcc-ld` folder (containing the `lld-wrapper`s that will run `rust-lld`) is present in
-            // the sysroot's target-specific tool binaries folder.
-            let tools_path = sess.get_tools_search_paths(false);
-            let gcc_ld_dir = tools_path
-                .into_iter()
-                .map(|p| p.join("gcc-ld"))
-                .find(|p| p.join(if sess.host.is_like_windows { "ld.exe" } else { "ld" }).exists())
-                .unwrap_or_else(|| sess.fatal("rust-lld (as ld) not found"));
-
-            cmd.arg({
-                let mut arg = OsString::from("-B");
-                arg.push(gcc_ld_dir);
-                arg
-            });
-            cmd.arg(format!("-Wl,-rustc-lld-flavor={}", sess.target.lld_flavor.as_str()));
-        } else {
-            // We were asked to use `lld` but not `rust-lld`.
-            cmd.arg("-fuse-ld=lld");
-        }
+    // 2. Maybe point at https://github.com/flamegraph-rs/flamegraph/pull/157 or the
+    // corresponding rust/LLVM issue when/if it's tracked, depending on whether we use the
+    // workaround argument `--no-rosegment` by default when invoking `lld`.
+    //
+    // 3. If in the future, other linker flavors and targets are eligible to a `rust-lld`
+    // enrichment, maybe also point at target-specific issues like:
+    // - MSVC + ThinLTO blocker https://github.com/rust-lang/rust/issues/81408
+    // - the "lld on MSVC" tracking issue https://github.com/rust-lang/rust/issues/71520
+    //   containing a list of blocking issues
+
+    // Now, handle `rust-lld`. If the `-Zgcc-ld=lld` flag was provided, we use `rust-lld`, the
+    // rustup-distributed version of `lld` (when applicable, i.e. not in distro-builds) by:
+    // - checking the `lld-wrapper`s exist in the sysroot
+    // - adding their folder as a search path, or requesting to use a wrapper directly
+    if unstable_gcc_lld {
+        // A `gcc-ld` folder (containing the `lld-wrapper`s that will run `rust-lld`) is present in
+        // the sysroot's target-specific tool binaries folder.
+        let tools_path = sess.get_tools_search_paths(false);
+        let gcc_ld_dir = tools_path
+            .into_iter()
+            .map(|p| p.join("gcc-ld"))
+            .find(|p| p.join(if sess.host.is_like_windows { "ld.exe" } else { "ld" }).exists())
+            .unwrap_or_else(|| sess.fatal("rust-lld (as ld) not found"));
+
+        cmd.arg({
+            let mut arg = OsString::from("-B");
+            arg.push(gcc_ld_dir);
+            arg
+        });
+        cmd.arg(format!("-Wl,-rustc-lld-flavor={}", sess.target.lld_flavor.as_str()));
     } else {
-        // Otherwise, we were just asked to use a linker executable, and it's expected that `cc`
-        // will find it on the $PATH.
-        cmd.arg(format!("-fuse-ld={}", use_ld));
+        // Otherwise, we were asked to use `lld` but not `rust-lld`.
+        cmd.arg("-fuse-ld=lld");
     }
 }

compiler/rustc_session/src/config.rs

@@ -208,15 +208,15 @@ impl LinkerPluginLto {
 /// `to_flavor` method, and never the enrichment variants.
 ///
 /// Currently used to represent finer-grained uses of `gcc`, to improve ease-of-use for wrapping a
-/// given linker like `lld`, `gold` or `mold`.
-#[derive(Clone, Debug, Eq, Ord, PartialEq, PartialOrd)]
+/// given linker (currently: only `lld`).
+#[derive(Clone, Debug, PartialEq)]
 pub enum LinkerFlavorCli {
     /// When the CLI option is one of the well-known linker-flavors that don't need special
     /// handling.
     WellKnown(LinkerFlavor),
 
-    /// Enrichments to the `LinkerFlavor::Gcc` flavor, to specify the linker via `-fuse-ld`
-    Gcc { use_ld: String },
+    /// Enrichments to the `LinkerFlavor::Gcc` flavor, to specify the linker via `-fuse-ld`.
+    Gcc { use_ld: LdImpl },
 }
 
 impl LinkerFlavorCli {
@@ -241,17 +241,11 @@ impl FromStr for LinkerFlavorCli {
 
         // Otherwise, it should be the enrichments to the gcc/cc flavor: wrapping a given linker
         // separated by a colon like `gcc:lld`.
-        let parts: Vec<_> = s.split("gcc:").collect();
-        if parts.len() != 2 {
+        if s != "gcc:lld" {
             return Err(());
         }
 
-        let wrapped_linker = parts[1];
-        if !wrapped_linker.is_empty() {
-            Ok(LinkerFlavorCli::Gcc { use_ld: wrapped_linker.to_string() })
-        } else {
-            Err(())
-        }
+        Ok(LinkerFlavorCli::Gcc { use_ld: LdImpl::Lld })
     }
 }
 
@@ -2442,26 +2436,16 @@ pub fn build_session_options(matches: &getopts::Matches) -> Options {
         );
     }
 
-    if let Some(LinkerFlavorCli::Gcc { use_ld }) = &cg.linker_flavor {
+    if let Some(LinkerFlavorCli::Gcc { .. }) = &cg.linker_flavor {
         // For testing purposes, until we have more feedback about these options: ensure `-Z
         // unstable-options` is enabled when using the `gcc` linker flavor enrichments.
         if !unstable_opts.unstable_options {
             early_error(
                 error_format,
-                "the `gcc:*` linker flavor is unstable, the `-Z unstable-options` \
+                "the `gcc:lld` linker flavor is unstable, the `-Z unstable-options` \
                  flag must also be passed to use it",
             );
         }
-
-        // Until the unstable flag is removed, ensure `-Zgcc-ld=lld` and `-Clinker-flavor=gcc:lld`
-        // have a matching linker choice.
-        if use_ld != "lld" && unstable_opts.gcc_ld == Some(LdImpl::Lld) {
-            early_error(
-                error_format,
-                "`-Zgcc-ld=lld` and `-Clinker-flavor` differ in their \
-                    linker choice. The latter should be `-Clinker-flavor=gcc:lld`",
-            );
-        }
     }
 
     let prints = collect_print_requests(&mut cg, &mut unstable_opts, matches, error_format);

compiler/rustc_session/src/options.rs

@@ -384,8 +384,7 @@ mod desc {
     pub const parse_cfprotection: &str = "`none`|`no`|`n` (default), `branch`, `return`, or `full`|`yes`|`y` (equivalent to `branch` and `return`)";
     pub const parse_strip: &str = "either `none`, `debuginfo`, or `symbols`";
     pub const parse_linker_flavor: &str = "one of: `em`, `gcc`, `l4-bender`, `ld`, `msvc`, \
-        `ptx-linker`, `bpf-linker`, `wasm-ld`, `ld64.lld`, `ld.lld`, `lld-link`, \
-        or a `gcc:`-prefixed linker to use with the gcc flavor, like `gcc:lld` or `gcc:gold,`";
+        `ptx-linker`, `bpf-linker`, `wasm-ld`, `ld64.lld`, `ld.lld`, `lld-link`, or `gcc:lld`";
     pub const parse_optimization_fuel: &str = "crate=integer";
     pub const parse_mir_spanview: &str = "`statement` (default), `terminator`, or `block`";
     pub const parse_instrument_coverage: &str =
@@ -1618,7 +1617,7 @@ pub enum WasiExecModel {
     Reactor,
 }
 
-#[derive(Clone, Copy, Hash, PartialEq)]
+#[derive(Clone, Copy, Hash, PartialEq, Debug)]
 pub enum LdImpl {
     Lld,
 }

compiler/rustc_session/src/tests.rs

@@ -32,20 +32,18 @@ pub fn parse_well_known_linker_flavor() {
     assert_eq!(LinkerFlavorCli::from_str("unknown_linker"), Err(()));
 }
 
-/// Enrichments can currently allow for the `gcc` flavor to specify for a given linker to be
-/// used, much like you'd use `-fuse-ld` as a link arg. When using `-C
-/// linker-flavor=gcc:$linker`, the `$linker` will be passed directly to `cc`.
+/// Enrichments can currently allow the `gcc` flavor to use `lld`, much like you'd use `-fuse-ld` as
+/// a link arg.
 #[test]
 pub fn parse_gcc_enrichment_linker_flavor() {
     assert_eq!(
         LinkerFlavorCli::from_str("gcc:lld"),
-        Ok(LinkerFlavorCli::Gcc { use_ld: "lld".to_string() })
-    );
-    assert_eq!(
-        LinkerFlavorCli::from_str("gcc:gold"),
-        Ok(LinkerFlavorCli::Gcc { use_ld: "gold".to_string() })
+        Ok(LinkerFlavorCli::Gcc { use_ld: LdImpl::Lld })
     );
 
+    // Only `gcc:lld` is supported for now
+    assert_eq!(LinkerFlavorCli::from_str("gcc:gold"), Err(()));
+
     // No linker actually mentioned
     assert_eq!(LinkerFlavorCli::from_str("gcc:"), Err(()));
 

src/test/run-make/gcc-linker-flavor/Makefile

@@ -3,7 +3,7 @@
 # Ensure that the enriched `gcc` linker-flavor passes the requested linker to `cc`
 
 -include ../../run-make-fulldeps/tools.mk
-RUSTC_FLAGS = -C linker-flavor=gcc:my_wrapped_linker -Z unstable-options --print link-args
+RUSTC_FLAGS = -C linker-flavor=gcc:lld -Z unstable-options --print link-args
 
 all:
-	$(RUSTC) $(RUSTC_FLAGS) empty.rs | $(CGREP) "fuse-ld=my_wrapped_linker"
+	$(RUSTC) $(RUSTC_FLAGS) empty.rs | $(CGREP) "fuse-ld=lld"

src/test/run-make/gcc-linker-flavor/empty.rs

@@ -1,4 +1,4 @@
-// Test ensuring that the enriched `gcc` linker flavor requesting an arbitrary linker (`-C
-// linker-flavor=gcc:$linker`) is passed to `cc` as `-fuse-ld`
+// Test ensuring that the enriched `gcc` linker flavor requesting `lld` (`-C
+// linker-flavor=gcc:lld`) is passed to `cc` as `-fuse-ld=lld`
 
 fn main() {}

src/test/ui/linkers/gcc_ld_mismatch.rs

@@ -1,5 +1,5 @@
-// check-fail
-// compile-flags: -Zgcc-ld=lld -Clinker-flavor=gcc:not_lld -Zunstable-options
+// build-fail
+// compile-flags: -Zgcc-ld=lld -Clinker-flavor=em -Zunstable-options
 
 // Test ensuring that until the unstable flag is removed (if ever), if both the linker-flavor and
 // `gcc-ld` flags are used, they ask for the same linker.

src/test/ui/linkers/gcc_ld_mismatch.stderr

@@ -1,2 +1,4 @@
-error: `-Zgcc-ld=lld` and `-Clinker-flavor` differ in their linker choice. The latter should be `-Clinker-flavor=gcc:lld`
+error: `-Zgcc-ld` is used even though the linker flavor is not `gcc`
+
+error: aborting due to previous error
 

src/test/ui/linkers/unstable_linker_flavor.lld.stderr

@@ -1,9 +1,7 @@
 // check-fail
-// revisions: lld other
-// [lld] compile-flags: -C linker-flavor=gcc:lld
-// [other] compile-flags: -C linker-flavor=gcc:other
+// compile-flags: -C linker-flavor=gcc:lld
 
-// Test ensuring that the unstable `gcc:*` values of the stable `-C linker-flavor` flag require
+// Test ensuring that the unstable `gcc:lld` value of the stable `-C linker-flavor` flag requires
 // using `-Z unstable options`
 
 fn main() {}

src/test/ui/linkers/unstable_linker_flavor.other.stderr

@@ -0,0 +1,2 @@
+error: the `gcc:lld` linker flavor is unstable, the `-Z unstable-options` flag must also be passed to use it
+