poor diagnostic for unsupported -fuse-ld=lld flag

[Mark-Simulacrum]

On older platforms (e.g., Amazon Linux 2 is where I encountered this), the current implementation of LLD-by-default in rustc leads to a tracing::warn! log line: https://github.com/rust-lang/rust/blob/dcecb99176edf2eec51613730937d21cdd5c8f6e/compiler/rustc_codegen_ssa/src/back/link.rs#L771C24-L771C54

The linker driver does not support `-fuse-ld=lld`. Retrying without it

This is at minimum a diagnostics bug, but I'm not sure the warning makes sense -- if we're not able to use LLD and have a well-supported fallback path, as long as the user isn't explicitly requesting LLD it seems plausible that a silent fallback is better than complaining noisily (and still falling back)?

[Mark-Simulacrum]

cc @Kobzol (per offline discussion of this) -- my sense is this is probably not blocking for #140525 but would be worth considering whether we can silence / change the diagnostic away from tracing (so it at least doesn't show up from dependency links...).

[Kobzol]

Since we do support a range of Linux distributions, based on the minimal supported glibc version, I agree that LLD should work out of the box (without any weird warnings) on all of these distribution. And since some of these indeed seem to use too old GCC, we should IMO get rid of the error, at least in the case where we do use the default option. CC @lqd (happy to work on implementing this)

[lqd]

I don't know why these are warn!s instead of debug logs per se (maybe to nudge people into trying to update their gcc/linker?) but they are very old. Some of them are from 2017.

We can remove the warning from the -fuse-ld=lld case if you'd like.

[Mark-Simulacrum]

I can't tell from #97402 whether we didn't explore the -B path suggested there as supporting a broader range of GCC versions for some reason other than "not worth it". Maybe worth re-examining? But I'd be OK with just changing the warn! to info! (so it's still available with RUSTC_LOG unlike debug!) and skipping lld on the too-old gcc, though we should document that in our stabilization report as the behavior we're pursuing if so.