Change the global default for download-ci-llvm to if-available

[jyn514]

Proposal

Switch the None branch of this match to return is_ci_llvm_available instead of false: https://github.com/rust-lang/rust/blob/b0f3940c35d565399dccf8c79f38147b40f2724a/src/bootstrap/config.rs#L1086-L1092

Background and Motivation

x.py has a tiered defaults system. It has a global default, which is used if no config.toml exists, and then opt-in "profiles" (library, compiler, user). Right now, the global default for download_ci_llvm is false and the profile default is "if-available" for all profiles except user. This works generally well for frequent contributors to the compiler, but means that first-time contributors get a sub-standard experience (see for example @pnkfelix's stream where more than half of the first-time build is spent building llvm: https://www.youtube.com/watch?v=oG-JshUmkuA). This is particularly bad because LLVM takes enormously long to build, and it's worse on computers with fewer hardware threads.

I suggest changing the global default to if-available. "if-available" currently means "any tier 1 platform" (there are some additional checks related to running in CI, but they're not important for local development).

Drawbacks

There are two possible downsides:

• Some platforms appear to be building the LLVM artifacts wrong, and haven't been fixed because not many people use those platforms to build rustc: rust-dev LLVM artifacts are corrupt on FreeBSD 13 rust#96633. We can avoid regressing behavior there by removing them from the if-available check if we notice they're broken.
• Distros building rustc from source will not like this new behavior and will have to opt-out with ./configure --set llvm.download-ci-llvm=false. I think this is fine as long as the change is documented in bootstrap's changelog.

Mentors or Reviewers

@pnkfelix for helping me convince t-compiler this is a good idea
@Mark-Simulacrum for thinking of any downsides I may have missed

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[oli-obk]

@rustbot second

[apiraino]

@rustbot label -final-comment-period +major-change-accepted