Avoid explicitly setting linker args in rust by default

[leonhma]

What happened

When building a rust project for an embedded device inside of a devenv environment with the default settings for rust:

languages.rust = {
     enable = true;
     channel = "nightly";
     components = [ "rustc" "rust-src" "cargo" "clippy" "rustfmt" "rust-analyzer" ];
};

I got the error collect2: could not find 'ld', referring to the target-custom ld linker binary provided by the manufacturer toolchain. After some less-than-fun hours of troubleshooting I finally found out what's going on. Because RUSTFLAGS is set to -C -fuse-ld=mold, collect2 only looks for ld.mold and then of course misses the custom linker. It turns out, this can be avoided by setting mold.enable = false; in the devenv config.

The Solution

mold.enable was enabled by default on my machine, because I am running on x86 linux and didn't specify a custom target (there is no target to be installed for this chip). The solution was to set mold.enable to false explicitly. From a UI-philosophical standpoint, I would strongly argue against making it the default to forcefully override defaults set by other programs, as this can (and did!) lead to frustrating error scenarios. Think about it: Because it is not the default, rust/cargo assume that the -C -fuse-ld=mold option is set knowingly by the user. As such, there is no incentive for error messages (far less descriptive ones) and also no reason to discuss possible errors in the rust documentation - because the user is assumed to already know about the overridden linker. "Taking this knowledge from the user" by making it a default leads to hard-to-pinpoint errors and frustration.

I propose to make it the default for languages.rust.mold.enable to be disabled by default in all scenarios. If performance is a consideration, I would suggest including a note in the languages.rust.enable section about manually enabling languages.rust.mold.enable fro improved performance. This way it is an informed choice by the user.

Repro
Repro repo: esprs@6f2da8f

devenv allow && devenv reload && cargo build gives:

...
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: [ldproxy] Running ldproxy
          Error: Linker /home/leonhma/Documents/Code/esprs/.embuild/espressif/tools/riscv32-esp-elf/esp-13.2.0_20240530/riscv32-esp-elf/bin/riscv32-esp-elf-gcc failed: exit status: 1
          STDERR OUTPUT:
          collect2: fatal error: cannot find 'ld'
          compilation terminated.
          
          

error: could not compile `esprs` (bin "esprs") due to 1 previous error

Version

devenv 1.3.1 using flakes