Rebuild llvm spuriously less frequently #138333
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @onur-ozkan rustbot has assigned @onur-ozkan. Use |
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
I noticed that `x check` was rebuilding rustc_llvm basically every time I modified
a source file. I tracked this down to the following env variable change:
```
cargo::core::compiler::fingerprint: dirty: EnvVarChanged { name: "REAL_LIBRARY_PATH", old_value: Some("/home/jyn/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib"), new_value: None }
```
The problem was that I had installed rust-analyzer from rustup, not as a
standalone tool. As a result, rustup sets
`LD_LIBRARY_PATH=$(rustc --print target-libdir)` in the environment
under the assumption that rust-analyzer needs it to link to
rustc_private crates. This is not in fact the case; RA does not link to
rustc_private. But rustup does not know this. Ideally we would make
rustup smarter, but that takes a while because rustup has infrequent
releases.
In the meantime, as a workaround, be a little more selective about when we forward
LD_LIBRARY_PATH. See the new comment for more details.
jyn514
force-pushed
the
spurious-llvm-rebuilds
branch
from
a191eb0 to
2a8c87b
Compare
|
@bors r+ |
bors
added
S-waiting-on-bors
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this pull request
Mar 12, 2025
…nur-ozkan
Rebuild llvm spuriously less frequently
I noticed that `x check` was rebuilding rustc_llvm basically every time I modified a source file. I tracked this down to the following env variable change:
```
cargo::core::compiler::fingerprint: dirty: EnvVarChanged { name: "REAL_LIBRARY_PATH", old_value: Some("/home/jyn/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib"), new_value: None }
```
The problem was that I had installed rust-analyzer from rustup, not as a standalone tool. As a result, rustup sets
`LD_LIBRARY_PATH=$(rustc --print target-libdir)` in the environment under the assumption that rust-analyzer needs it to link to rustc_private crates. This is not in fact the case; RA does not link to rustc_private. But rustup does not know this. Ideally we would make rustup smarter, but that takes a while because rustup has infrequent releases.
In the meantime, as a workaround, be a little more selective about when we forward LD_LIBRARY_PATH. See the new comment for more details.
Note that there are still cases when we will spuriously rebuild; in particular when setting `llvm-config = /path/to/llvm-config` and using rust-analyzer installed from rustup. but both of those are individually rare, and the combination seems very unlikely to me.
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this pull request
Mar 12, 2025
…nur-ozkan
Rebuild llvm spuriously less frequently
I noticed that `x check` was rebuilding rustc_llvm basically every time I modified a source file. I tracked this down to the following env variable change:
```
cargo::core::compiler::fingerprint: dirty: EnvVarChanged { name: "REAL_LIBRARY_PATH", old_value: Some("/home/jyn/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib"), new_value: None }
```
The problem was that I had installed rust-analyzer from rustup, not as a standalone tool. As a result, rustup sets
`LD_LIBRARY_PATH=$(rustc --print target-libdir)` in the environment under the assumption that rust-analyzer needs it to link to rustc_private crates. This is not in fact the case; RA does not link to rustc_private. But rustup does not know this. Ideally we would make rustup smarter, but that takes a while because rustup has infrequent releases.
In the meantime, as a workaround, be a little more selective about when we forward LD_LIBRARY_PATH. See the new comment for more details.
Note that there are still cases when we will spuriously rebuild; in particular when setting `llvm-config = /path/to/llvm-config` and using rust-analyzer installed from rustup. but both of those are individually rare, and the combination seems very unlikely to me.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 12, 2025
Rollup of 25 pull requests Successful merges: - rust-lang#134076 (Stabilize `std::io::ErrorKind::InvalidFilename`) - rust-lang#136842 (Add libstd support for Trusty targets) - rust-lang#137314 (change definitely unproductive cycles to error) - rust-lang#137504 (Move methods from Map to TyCtxt, part 4.) - rust-lang#137621 (Add std support to cygwin target) - rust-lang#137701 (Convert `ShardedHashMap` to use `hashbrown::HashTable`) - rust-lang#138109 (make precise capturing args in rustdoc Json typed) - rust-lang#138161 (Add PeekMut::refresh) - rust-lang#138162 (Update the standard library to Rust 2024) - rust-lang#138174 (Elaborate trait assumption in `receiver_is_dispatchable`) - rust-lang#138175 (Support rmeta inputs for --crate-type=bin --emit=obj) - rust-lang#138269 (uefi: fs: Implement FileType, FilePermissions and FileAttr) - rust-lang#138313 (Update books) - rust-lang#138318 (Rustdoc: remove a bunch of `@ts-expect-error` from main.js) - rust-lang#138331 (Use `RUSTC_LINT_FLAGS` more) - rust-lang#138333 (Rebuild llvm spuriously less frequently) - rust-lang#138343 (Enable `f16` tests for `powf`) - rust-lang#138345 (Some autodiff cleanups) - rust-lang#138346 (naked functions: on windows emit `.endef` without the symbol name) - rust-lang#138347 (Reduce `kw::Empty` usage, part 2) - rust-lang#138360 (Fix false-positive in `expr_or_init` and in the `invalid_from_utf8` lint) - rust-lang#138371 (Update compiletest's `has_asm_support` to match rustc) - rust-lang#138372 (Refactor `pick2_mut` & `pick3_mut` to use `get_disjoint_mut`) - rust-lang#138376 (Item-related cleanups) - rust-lang#138377 (Remove unnecessary lifetime from `PatInfo`.) r? `@ghost` `@rustbot` modify labels: rollup
|
This looks most likely to have caused rollup failure on dist-x86_64-linux, running try-job to check. @bors r- |
bors
added
S-waiting-on-author
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 12, 2025
Rebuild llvm spuriously less frequently
I noticed that `x check` was rebuilding rustc_llvm basically every time I modified a source file. I tracked this down to the following env variable change:
```
cargo::core::compiler::fingerprint: dirty: EnvVarChanged { name: "REAL_LIBRARY_PATH", old_value: Some("/home/jyn/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib"), new_value: None }
```
The problem was that I had installed rust-analyzer from rustup, not as a standalone tool. As a result, rustup sets
`LD_LIBRARY_PATH=$(rustc --print target-libdir)` in the environment under the assumption that rust-analyzer needs it to link to rustc_private crates. This is not in fact the case; RA does not link to rustc_private. But rustup does not know this. Ideally we would make rustup smarter, but that takes a while because rustup has infrequent releases.
In the meantime, as a workaround, be a little more selective about when we forward LD_LIBRARY_PATH. See the new comment for more details.
Note that there are still cases when we will spuriously rebuild; in particular when setting `llvm-config = /path/to/llvm-config` and using rust-analyzer installed from rustup. but both of those are individually rare, and the combination seems very unlikely to me.
try-job: dist-x86_64-linux
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
Shourya742
approved these changes
Mar 24, 2025
|
i think the actual fix is to unset this in rust-analyzer config. |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I noticed that
x checkwas rebuilding rustc_llvm basically every time I modified a source file. I tracked this down to the following env variable change:The problem was that I had installed rust-analyzer from rustup, not as a standalone tool. As a result, rustup sets
LD_LIBRARY_PATH=$(rustc --print target-libdir)in the environment under the assumption that rust-analyzer needs it to link to rustc_private crates. This is not in fact the case; RA does not link to rustc_private. But rustup does not know this. Ideally we would make rustup smarter, but that takes a while because rustup has infrequent releases.In the meantime, as a workaround, be a little more selective about when we forward LD_LIBRARY_PATH. See the new comment for more details.
Note that there are still cases when we will spuriously rebuild; in particular when setting
llvm-config = /path/to/llvm-configand using rust-analyzer installed from rustup. but both of those are individually rare, and the combination seems very unlikely to me.try-job: dist-x86_64-linux