Generalize configuring LLD as the default linker in bootstrap

[Kobzol]

NOTE: This PR was resubmitted in #147626 due to some issues with bors.

This PR generalizes the previous hardcoded logic for setting self-contained LLD to be used as the default Linker on Linux GNU targets. The changes made:

1. rust.lld now only controls whether LLD is built and included in the sysroot. If rust.lld is set to false, it will disable the default opt into LLD on x64 Linux.
2. The linker override for using rust-lld through cc can now be applied to all Linux targets. It is configured through target.<target>.default-linker-linux-override = "self-contained-lld-cc"/"off"

Here is how it behaves:

1. If you don't set any options, x64 Linux will default into default-linker-linux-override = "self-contained-lld-cc" and also rust.lld = true.
2. If you set rust.lld = false, you disable this override
3. If you set target.x86_64-unknown-linux-gnu.default-linux-linker-override = "off", you disable this override
4. If you set target.x86_64-unknown-linux-gnu.llvm-config = ..., you disable this override

Note that in contrast to what I described in #146640, I didn't bother moving rust.lld to llvm.lld. We can do that separately later, but I don't think it's worth the churn. I realized that rust is perhaps a better place for this, because it not only controls whether LLD is built, but also if it is included in the compiler sysroot. So to truly distinguish these two, we'd need both llvm.lld and rust.lld, which doesn't seem worth it. Note that rust.codegen-backends = ["llvm"] works in the same way, it tells bootstrap to build LLVM and include it in the sysroot. So it is consistent with rust.lld

Related to: #146640

r? @jieyouxu

[rustbot]

This PR modifies bootstrap.example.toml.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

These commits modify compiler targets.
(See the Target Tier Policy.)

[petrochenkov]

This was supposed to be linux_gnu.rs, not linux_musl.rs?

[Kobzol]

Oops, the files are too similar 😆 I actually wanted to put this into linux.rs directly, as the override should also work for MUSL targets. Unless you think we should only allow it for linux-gnu.

[Kobzol]

Hmm, but if we put it into linux.rs, then musl would override link_self_contained: LinkSelfContainedDefault::InferredForMusl, that's not ideal. Ideally we should use the override at the very end of the config, not at the beginning, I guess.

[lqd]

3. Bootstrap no longer automatically enables LLD for x86_64-unknown-linux-gnu if there is no external LLVM config being used

Do you mean this is disabling the lld default for x64 linux and contributors have to change their local configs to keep it?

[Kobzol]

Currently yes. I realize now that this is probably not a good idea, as we want to have as much coverage of LLD as possible.

Then what I would do it configure this to be enabled by default in bootstrap for this specific target (either in code or bootstrap.toml default profiles), and then allow distros to opt-out.

But enabling it by default would require us to also set rust.lld to true, or only override rust-lld when rust.lld is enabled, which is essentially what happened before and what I wanted to get rid off =D

Ok then I would propose:

• Enable the override by default
• If rust.lld is unset, enable rust.lld when the override is enabled

Thus essentially the other way around than it was before.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Kobzol]

Updated the PR to apply the override by default, with the possibility to opt out. Updated the PR descripton.

[jieyouxu]

Two nits, otherwise makes sense to me.

View changes since this review

[jieyouxu]

@rustbot author

[Kobzol]

@rustbot ready

[Zalathar]

@bors r=jieyouxu

[bors]

📌 Commit da86710 has been approved by jieyouxu

It is now in the queue for this repository.

[Zalathar]

For whatever reason, this PR seems to confuse bors whenever it’s at the head of the queue.

It might be prudent to close this PR and reopen a new one with the same changes.

@bors r-

[Kobzol]

Let's try closing/reopening.

[Kobzol]

@bors r=jieyouxu

[bors]

📌 Commit da86710 has been approved by jieyouxu

It is now in the queue for this repository.

[Kobzol]

Hmm, yeah, seems like bors can't figure out the mergeability status of this PR.

[Kobzol]

Resubmitted in #147626.