-
Notifications
You must be signed in to change notification settings - Fork 13.9k
Ensure lld is supported with download-ci-llvm
#104748
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@bors try |
|
⌛ Trying commit fdf2238424e42ef67cd1826723a792c86735ded7 with merge 2b02e73d38e5508c9eeda99c5c321b11cd0667f6... |
|
☀️ Try build successful - checks-actions |
cba3d17 to
573b2ba
Compare
lld is packaged in download-ci-llvmlld is supported with download-ci-llvm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand correctly, --enable-full-tools will also enable rust.lld, and this is why LLD is already packaged today in the rust-dev component on the main targets (and why -Zgcc-ld=lld does work there).
Can you expand on "main targets"? Is it available on all tier 1 targets, or only targets where we build LLVM from source? and if it's on all tier 1 targets, what is this change doing?
Ah I only meant the targets listed in the OP (minus aarch64 darwin which is tier 2) where I manually tested that
The current situation is a bit subtle and I think in #100010 it was expected that we don't package lld in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for explaining. This looks good to me if you change LLD to be included in RustDev unconditionally.
I am not quite sure what the relation is here, but FWIW I don't have any problem with speculatively approving this and seeing if CI fails or not. |
|
To summarize the intent I described on zulip: our This PR is ultimately to fix CI so that this doesn't regress anymore: the test builders will have access to lld with |
|
☔ The latest upstream changes (presumably #106000) made this pull request unmergeable. Please resolve the merge conflicts. |
Makes the lld step avoid building it from source when possible: when dist has packaged it along the other LLVM binaries for the rust-dev component.
|
@jyn514 #101792 has just landed, so #101653 is fixed: that means the various I've pushed a commit making the LLD step I'm not sure we really need to bump the @rustbot ready |
|
Thanks, this looks great!
I think it's not strictly necessary, but there's no harm bumping it, the download isn't too big. @bors r+ |
…mpiler-errors Rollup of 8 pull requests Successful merges: - rust-lang#104748 (Ensure `lld` is supported with `download-ci-llvm`) - rust-lang#105541 (Simplify some iterator combinators) - rust-lang#106045 (default OOM handler: use non-unwinding panic, to match std handler) - rust-lang#106157 (Don't trim path for `unsafe_op_in_unsafe_fn` lints) - rust-lang#106353 (Reduce spans for `unsafe impl` errors) - rust-lang#106381 (Jsondoclint: Add `--verbose` and `--json-output` options) - rust-lang#106411 (rustdoc: remove legacy font-feature-settings CSS) - rust-lang#106414 (Add cuviper to the review rotation for libs) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
… r=jyn514 Use CI LLVM in `test-various` builder It was disabled because it needs `lld`, but since rust-lang#104748 was merged it is no longer needed. This will speed this test, since it no longer needs to build LLVM.
This PR:
native::LLDstep support using the packagedci-llvm/bin/lld, instead of building it from source (which would most likely not be available today, nor in the future wheredownload-ci-llvm = if-availableis the default).If I understand correctly,
--enable-full-toolswill also enablerust.lld, and this is why LLD is already packaged today in therust-devcomponent on the main targets (and why-Zgcc-ld=llddoes work there).That means it's likely that this PR will not be able to land before I've reworked and landed #101792: if LLD is available in
download-ci-llvm, theneeds-rust-lldtests should start being executed on the x64 macOS test builders, and CI would fail today.I've tested locally that building with
download-ci-llvm = trueandlld = truewith the LLVM submodule unregistered was successful, and thatrust-lldand the variouslld-wrappers are present and-Zgcc-ld=lldworks as well, on a few different platforms:x86_64-unknown-linux-gnuaarch64-apple-darwinx86_64-pc-windows-msvc(with-Clinker=rust-lldrather than-Zgcc-ld=lld)x86_64-apple-darwin, with theMACOSX_DEPLOYMENT_TARGETworkaround for -Z gcc-ld=lld fails again #101653I don't think we really need to bump the
download-ci-llvm-stampin this case, since./build/$triple/ci-llvm/bin/lldis present on all the above targets already, but have added it mechanically, and it should probably be removed to avoid unnecessary downloads/churn.Fixes #98340
Supersedes #100010