MSVC-like targets ignore target spec's linker field

[hanna-kruppe]

Normally if -C linker is not specified, the target spec is consulted. However, is is_like_msvc is set, rustc uses "link.exe" unconditionally. This seems like an oversight. For example, it prevents setting up link.exe-flavored LLD in a target spec (which works fine with -C linker, at least as far as invoking the right executable goes).

cc @retep998

[hanna-kruppe]

Correction: Since it looks only at is_like_msvc, not at linker_flavor, it's still possible to use link.exe-flavored LLD by just not setting the former. Still seems odd to hard code that name and yet let -C linker override it.

[retep998]

Unlike all other targets, for the msvc targets rustc ends up going through some very complex logic to figure out where link.exe is, as well as library paths. At the time LLD was not a viable option and there were never any msvc linkers other than link.exe, so it was easier to hardcode link.exe into all the complex search logic, instead of plumbing through the target spec configuration.

If we do choose to respect the target spec in this case, then there are some unresolved questions. For example, should we still do all that complex search logic? It's extremely unlikely LLD will be found the same way as link.exe. If we do end up just blindly shelling out to the linker when it isn't link.exe, do we still want to find the Windows SDK library paths ourselves? Currently for -C linker we don't do any special logic and just expect the user to go through all the hard work of ensuring the linker is in PATH and all the library paths are configured correctly.

[hanna-kruppe]

I think it's reasonable for target.options.linker to behave exactly like -C linker.

[alexcrichton]

This was fixed in #48125