Perform ThinLTO on x86_64-pc-windows-msvc dist builder

[Zoxc]

View all comments

This reenables ThinLTO on x86_64-pc-windows-msvc.

try-job: dist-x86_64-msvc

[rustbot]

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
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

[jieyouxu]

FYI @rust-lang/infra

[lqd]

I don't think we're in a situation where we can yet have a definite yes/no answer for this PR yet.

Marking as blocked on #122790. The discussions and underlying issues there shouldn't be split amongst PRs.

@rustbot blocked

[bors]

☔ The latest upstream changes (presumably #130506) made this pull request unmergeable. Please resolve the merge conflicts.

[Zoxc]

@rustbot ready

This is no longer blocked, at least not on my previous PR.

Are the binaries built by dist jobs properly tested now?
Are there any other knowns issues with ThinLTO on Windows?

[Kobzol]

They are tested, not sure if properly :) Last time we tried it, one test was still miscompiled, we could try again.

• comment out DIST_TRY_BUILD insrc/ci/github-actions/jobs.yml
• add a line try-job: dist-x86_64-msvc to the PR description
• run a try build

[jieyouxu]

They are tested, not sure if properly :)

As far as I know, Windows dist artifacts are not tested at all (note that dist artifacts are not necessarily equivalent to test job artifacts; and usually they are not equivalent due to configuration differences). We do have Windows test jobs that run the full test suites but they aren't testing the dist artifacts.

EDIT: x86_64-pc-windows-msvc goes through opt-dist but not the other i686-pc-windows-msvc apparently.

Recently we broke i686-pc-windows-gnu rustc binaries in a way that caused rustc binary to completely not work (rustc -vV failed) but no tests caught it.

[lqd]

As far as I know, Windows dist artifacts are not tested at all

We do test dist x64 msvc artifacts in opt-dist.

[jieyouxu]

Huh. I must be thinking of x86_64 windows-gnu or maybe the 32 bit windows-msvc target?

EDIT: in any case you're right:

https://github.com/rust-lang/rust/blob/master/src%2Fci%2Fgithub-actions%2Fjobs.yml#L584

[Kobzol]

@bors try

[bors]

⌛ Trying commit 3d3aba0 with merge b9d7ae0...

[bors]

💔 Test failed - checks-actions

[Kobzol]

@bors try

[bors]

⌛ Trying commit a832199 with merge 359c9af...

[rust-bors]

💔 Test for 74ab0d8 failed: CI. Failed jobs:

• try - dist-x86_64-msvc (web logs, extended logs)

[Zoxc]

@bors try

[rust-bors]

💔 Test for 9f3fcfb failed: CI. Failed job:

• try - dist-x86_64-msvc (web logs, enhanced plaintext logs)

[rustbot]

Warning

If you are changing how CI LLVM is built or linked, make sure to bump
src/bootstrap/download-ci-llvm-stamp.

cc @jieyouxu

[Zoxc]

@bors try

[rust-bors]

💔 Test for 6399134 failed: CI. Failed job:

• try - dist-x86_64-msvc (web logs, enhanced plaintext logs)

[Zoxc]

@bors try

[rust-bors]

☀️ Try build successful (CI)
Build commit: bade842 (bade8423709cf67d44e2e352dc9a078bb939b837)
Base parent: 008fa22 (008fa22ce3f8d3c8dfaca2e6486043c2b21851eb)

[Zoxc]

Claude Opus 5 was able to spot that tool LTO builds were affected by rust-lang/cargo#14575. I've worked around that.

Might want to wait on #158734 in case that cause issues.

@rustbot ready

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.