-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Include lld
in rust-dev
package
#91229
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
(rust-highfive has picked a reviewer for you, use r? to override) |
@bors try |
⌛ Trying commit 9afc013df9f25d16be3198d0d0271f0afcecb9b4 with merge e774ca25315475b9480cbb24892ba8aaf626f583... |
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
src/bootstrap/dist.rs
Outdated
@@ -2082,6 +2082,7 @@ impl Step for RustDev { | |||
"llvm-bcanalyzer", | |||
"llvm-cov", | |||
"llvm-dwp", | |||
"lld", |
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.
Hmm, I was going to suggest adding ensure(native::Lld)
somewhere, but I don't see any ensure calls in this function. Maybe this step is assuming it's run from some other step? But it seems better to just call ensure
anyway for all the tools it lists here.
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.
I'm not very familiar with this code - I think it would be better to add in ensure
calls in a separate PR.
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 41b5b3808f251e856387093f354575aaa7eea59f with merge 668b61ea6d1ba3681ab71c90dd4a6d7ceb3ef175... |
Oops, I didn't mean to queue the timer... |
☀️ Try build successful - checks-actions |
Queued 668b61ea6d1ba3681ab71c90dd4a6d7ceb3ef175 with parent 454cc5f, future comparison URL. |
Finished benchmarking commit (668b61ea6d1ba3681ab71c90dd4a6d7ceb3ef175): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. @bors rollup=never |
I suspect this will fail on CI builders that do build rust-dev but don't enable LLD (and so the file won't be present). We probably will want to optionally populate lld into this directory if it's available if that's the case. In any case, I'm a little uncertain that this is the right path -- we actually already have rust-lld available in the downloaded packages for rustbuild, at least on x86_64-unknown-linux-gnu (build/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld). I suspect that adding another copy is probably not the right path to making LLD more available if it's missing on other targets from a similar location... (Edit: Sorry for a potentially misleading comment on the issue.) |
@Mark-Simulacrum Isn't the downloaded stage0 rust-lld potentially different from the LLD we build from LLVM? If we've bumped the LLVM submodule sometime after performing a stage0 bump, then the stage0 lld will be built from a different LLVM source tree, right? |
That's true - do we really need a absolutely recent lld though? Generally speaking Rust users will not be using the most recent lld, so I'm not sure rustc compilation requires it. I'm not strictly opposed to doing this, but I think it would be good to better understand the motivation for why we need an even more recent lld than beta. |
The motivation is to have a set of working LLVM tools when using |
Hm. Yes, that seems true. It's worth noting that in my experience LLD is really quite fast to build, so it may be possible to just have rustbuild directly build it if it's asked for, against the downloaded LLVM artifacts. But that doesn't seem particularly better than just downloading a fresh copy, so it seems OK to package it up with the artifacts we provide in rust-dev, though (I think) nothing will currently reach for it directly, so it's only for manual usage? Anyway, I'm fine with this PR (r=me) though as mentioned, I'd expect it to fail with missing LLD on platforms we're not currently building lld for -- so @bors rollup=iffy |
Fixes rust-lang#88941 This will allow using `download-ci-llvm` while still having LLD available.
@Mark-Simulacrum I modified the PR to only add LLD to the tarball if it exists. |
That still requires cloning llvm-project, which takes a while and uses a lot of disk space. |
Hm, OK -- I guess I was expecting us to rather try to build it more frequently (by eagerly requesting via ensure(native::Lld ...) for example, or In particular if the goal is to ensure it's reliably available, the current PR will likely make it available for just
as best as I can tell based on cursory CI inspection, which seems pretty limited. But r=me if that seems OK to you. |
Since the main motivation is local rustc development, I think it's fine to just support a few platforms for now, and add in others as the need arises. @bors r=Mark-Simulacrum |
📌 Commit 7826c57 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (6c189bc): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Fixes #88941
This will allow using
download-ci-llvm
while still having LLDavailable.