)]}'
{
  "commit": "4fcf39725a9c99bd495d8c73af83628a256ff9a9",
  "tree": "cbed309f8c197ff16440663af429cfe49e598ec7",
  "parents": [
    "2e2b193f8ada105f27608b7be81c293e0d7292cb",
    "3a91281217abd4c0e3d4a3de0f1e598c5bef31a3"
  ],
  "author": {
    "name": "bors",
    "email": "bors@rust-lang.org",
    "time": "Thu Sep 03 06:01:49 2026 +0000"
  },
  "committer": {
    "name": "bors",
    "email": "bors@rust-lang.org",
    "time": "Thu Sep 03 06:01:49 2026 +0000"
  },
  "message": "Auto merge of #161290 - Kobzol:bootstrap-llvm-4, r\u003djieyouxu\n\nAssorted bootstrap LLVM refactors (part 4/N)\n\n\n\nContinuation on https://github.com/rust-lang/rust/pull/161247.\r\n\r\nThis PR completely removes handling of git changes or LLVM downloads from config parsing, and moves it into the `LlvmFromCi` step. Thanks to that, we now also allow downloading LLVM for non-host targets.\r\n\r\nThere is one annoyance related to that, and that is that `download-ci-llvm` now applies to all targets for which you try to build LLVM (d\u0027uh), but that also means that if (for whatever reason) LLVM fails to be downloaded from CI, the build will fail. So if you build for target T2 from target T1:\r\n- If you want to download T1, but build T2, that\u0027s not possible to express.\r\n- If T2 fails to be downloaded, the build fails, even if it could be built locally.\r\n\r\nI think that we mostly have four options how to deal with this:\r\n1. Just ignore it and wait to see if someone complains.\r\n2. Revert the change and always download only for the host target. Worked so far. However, downloading LLVM for non-host targets would be quite useful for further bootstrap improvements and refactorings, because the current logic around sysroots and libdirs is.. convoluted, to say the last, and making cross-compilation easier would help with that a lot.\r\n3. Allow specifying `download-ci-llvm` *per target* in the target config section. So that you can say that you want to download for T1, but build for T2.\r\n4. Make download failures non-fatal, and cause them to trigger a local build. This would also help with removing the hacky `is_ci_llvm_available_for_target` logic, which hard-codes a bunch of targets to \"know\" which ones offer LLVM and which don\u0027t. We could just try to download, and if the result is 404, then we print a warning and continue with building (but this is slightly orthogonal, we can do this even if we don\u0027t make LLVM build failures non-fatal).\r\n\r\nI think that 3 or 4 would be the best solution, perhaps slightly opting for 4. If we get a 404, there\u0027s no way we can download, so we build instead. If we get a different error, we still make the failed download fail the build. And only if someone has a use-case for 3, we\u0027d add the new config.\r\n\r\nAlready before this PR, we did this:\r\n```\r\n// If download-ci-llvm\u003dtrue we also want to check that CI llvm is available\r\nb \u0026\u0026 llvm::is_ci_llvm_available_for_target(\u0026dwn_ctx.host_target, asserts)\r\n```\r\nso if LLVM wasn\u0027t available, we just silently reverted from `download-ci-llvm\u003dtrue` to `download-ci-llvm\u003dfalse`. The 4. proposal would just generalize that, to actually check whether the LLVM files are present on the CDN or not.\r\n\r\nThe problem with 4. is that you can\u0027t really set any custom build options for LLVM though, because if you also enable `download-ci-llvm`, the config sanity check will tell you to GTFO :( So we would probably need to make some changes there.\r\n\r\nr? jieyouxu",
  "tree_diff": []
}