Change:
config.changelog_seen = toml.changelog_seen; let build = toml.build.unwrap_or_default(); <ins> if let Some(file_build) = build.build { config.build = TargetSelection::from_user(&file_build); }; </ins> set(&mut config.out, flags.build_dir.or_else(|| build.build_dir.map(PathBuf::from))); // NOTE: Bootstrap spawns various commands with different working directories.

Discussion:
Since there is no variation of CI action for , prebuilt llvm is never published for arm macs. Hence compete bootstrap like will always fail on arm macs with downloading https://ci-<commit-hash/rust-dev-nightly-aarch64-apple- curl: (22) The requested URL returned error: 404 error: failed to download llvm from ci help: old builds get deleted after a certain time help: if trying to compile an old commit of rustc, disable in [llvm] download-ci-llvm = false Although it's straightforward to fix by following the hint from error message and finding correct (among other 's), bootstrap experience could be better: could point to correct config file, since there are really few of them; could be set to for those host triplets that have no published llvm; llvm could be published for ie creating CI action; of fallback distros could be introduced ie is fallback for .
label +T-bootstrap +T-infra does point to the correct file: in the root of your checkout, this is where you should put the config, and not in the build should not fail if CI LLVM is not found, it should be built from source instead (is this the real bug?) is this something that is possible / wanted, seeing the proportion of ARM Macs increasing? Should it also be done for the linux build? do not think this is really possible, as each target for which rustc is build is unique enough that they are incompatible with each other.
thank you for response! All clear with 1. 3. 4. Regarding 2: I don't think this is a bug in implementation since the logic is to stop build (exit the process) on missing remote resource. However this is indeed an unpleasant behavior. So as a user, epecialy first time one, I would prefer process to proceed with llvm build, or depending on configuration, fallback to probing local llvm installation.
I meant that the default is , thus should not fail the build if it can't download CI LLVM, but build it from source as if the config was set to , and print a warning.
T-infra said in the meeting today that it's intentional that we don't distribute alt artifacts for tier 2 platforms: https://rust- is going to confirm today that this is limited to alt artifacts.

this seems useful as long as the error is a 404, but we shouldn't build from source if is having trouble (people should have to explicitly opt-in). Separately, we may also want to distinguish tier 1 from tier 2 platforms in bootstrap, and not attempt to download the alt artifacts in the first place for tier 2 platforms. I don't like this idea, we shouldn't silently change the platform we're building (and mixing x86 with aarch64 won't work anyway I don't think). For this specific case we could suggest setting or explicitly in , but it shouldn't be a silent fallback.
Can confirm, that download attempt and following failure happening when either section does not have entry or is set to . Thank you for clarification Seems we may want to remove from the list of supported platforms. Also bear in mind, that only link leads to 404, for instance https://ci- works fine. So I'm not sure how it fit the logic of list referred above.
This isn't the right fix because it will regress the experience for people using llvm without assertions. See my message above for what I think we should do.
Ah, I believe I'm getting it. The problem is that has no idea whether we consulting it with downloading distribution in mind or a basic one.
Patching like that did the trick for me.
are you interested in making a patch like that for all the tier 2 targets? :) you can find a list here: (it will probably be easier to have a separate tier 1 and tier 2 list so you don't have to duplicate the names)
sure, let me try. Another option would be to have as an array of . So we can do the check like Not sure which one is cleaner/easier to maintain, I'm going to experiment with both.