Skip to content

Ship LLVM (rust-dev) in fast try builds again - #151196

Merged
rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
Kobzol:try-builds-llvm
Jan 16, 2026
Merged

Ship LLVM (rust-dev) in fast try builds again#151196
rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
Kobzol:try-builds-llvm

Conversation

@Kobzol

@Kobzol Kobzol commented Jan 16, 2026

Copy link
Copy Markdown
Member

#142963 stopped shipping rust-dev in fast try builds, which was not actually correct, because if a PR modifies the LLVM submodule, we should provide the prebuilt LLVM for rustc-perf even in a (fast) try build. So why didn't we find out about this earlier? Well, because soon before that PR landed, we started using new bors for try builds, which actually broke bootstrap's git change detection logic, because new bors used a different e-mail address for merge commits.

So the two bugs kind of masked each other out. Recently, we fixed the e-mail address and git change detection with new bors, since it's now also used for auto builds, but that in turn broke fast try builds that modify LLVM (#150722 (comment)), because rustc-perf saw that LLVM was modified in the try build, and it (correctly!) tried to download rust-dev for the given try build commit, but that was (incorrectly!) missing on CI, due to being skipped.

This PR restored building the rust-dev component in fast try builds. In theory, we could use the same git detection logic that bootstrap uses and only do this if LLVM is actually modified in the given commit, but I'd rather do the correct thing here, than introduce additional opportunities for the git detection to desync.

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 16, 2026
@rustbot

rustbot commented Jan 16, 2026

Copy link
Copy Markdown
Collaborator

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@Kobzol Kobzol mentioned this pull request Jan 16, 2026
10 tasks

@jieyouxu jieyouxu left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Can you please leave an elaborating comment for why not to skip here? r=me after.

View changes since this review

@jieyouxu

Copy link
Copy Markdown
Member

r? me

@Kobzol

Kobzol commented Jan 16, 2026

Copy link
Copy Markdown
Member Author

@bors r=jieyouxu

@rust-bors

rust-bors Bot commented Jan 16, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 41daada has been approved by jieyouxu

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 16, 2026
rust-bors Bot pushed a commit that referenced this pull request Jan 16, 2026
Rollup of 4 pull requests

Successful merges:

 - #151196 (Ship LLVM (`rust-dev`) in fast try builds again)
 - #151198 (Add an additional help note to the ambiguity lint error)
 - #151215 (Add missing closing brackets to THIR output.)
 - #151218 (compiletest: Add `AuxCrate` struct with docs.)

r? @ghost
@rust-bors
rust-bors Bot merged commit eb5b70a into rust-lang:main Jan 16, 2026
11 checks passed
@rustbot rustbot added this to the 1.94.0 milestone Jan 16, 2026
rust-timer added a commit that referenced this pull request Jan 16, 2026
Rollup merge of #151196 - try-builds-llvm, r=jieyouxu

Ship LLVM (`rust-dev`) in fast try builds again

#142963 stopped shipping `rust-dev` in fast try builds, which was not actually correct, because if a PR modifies the LLVM submodule, we should provide the prebuilt LLVM for rustc-perf even in a (fast) try build. So why didn't we find out about this earlier? Well, because soon before that PR landed, we started using new bors for try builds, which actually broke bootstrap's git change detection logic, because new bors used a different e-mail address for merge commits.

So the two bugs kind of masked each other out. Recently, we fixed the e-mail address and git change detection with new bors, since it's now also used for auto builds, but that in turn broke fast try builds that modify LLVM (#150722 (comment)), because rustc-perf saw that LLVM was modified in the try build, and it (correctly!) tried to download `rust-dev` for the given try build commit, but that was (incorrectly!) missing on CI, due to being skipped.

This PR restored building the `rust-dev` component in fast try builds. In theory, we could use the same git detection logic that bootstrap uses and only do this if LLVM is actually modified in the given commit, but I'd rather do the correct thing here, than introduce additional opportunities for the git detection to desync.
@Kobzol
Kobzol deleted the try-builds-llvm branch January 17, 2026 07:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants