Skip to content

chore: bump to cc@1.4.3 for rustc_llvm and library - #161260

Open
weihanglo wants to merge 3 commits into
rust-lang:mainfrom
weihanglo:cc-1.4.3
Open

chore: bump to cc@1.4.3 for rustc_llvm and library#161260
weihanglo wants to merge 3 commits into
rust-lang:mainfrom
weihanglo:cc-1.4.3

Conversation

@weihanglo

@weihanglo weihanglo commented Aug 17, 2026

Copy link
Copy Markdown
Member

What is this?

Old cc-rs derives this from the -Clto rustflag on its own.
cc@1.2.39 starts gating that behind -Clinker-plugin-lto,
which bootstrap doesn't pass.
Therefore,
we need to pass this flag explicitly to keep LTO mode

Previous efforts:

I personally want this because of cc 1.3.0+ has the support of Cargo -Ztrim-paths,
which helps what I am experimenting in #161049.

How to review

Commit by commit.

To keep commits bisect-able,
I added the first commit without cc bump.
clang should be fine with duplicate -flto flags.

One thing I am not certain is whether we should probe -flto flag in this case,
or just make this fail if -flto isn't supported.
(I assume -flto is quote widely supported)

r? Kobzol

🤖 LLM disclosure: I used LLM for the experiment of #161049, but not the bootstrap LTO change in this PR.

@weihanglo
bootstrap: keep rustc C deps with configured LTO mode
6839ade 
Old cc-rs derives this from the `-Clto` rustflag on its own.
`cc@1.2.39` starts gating that behind `-Clinker-plugin-lto`,
which bootstrap doesn't pass.
Therefore,
we need to pass this flag explicitly to keep LTO mode
@weihanglo
rustc_llvm: bump cc to 1.4.3
8552aff 
Also pulls in

* find-msvc-tools 0.1.5 -> 0.1.11
* shlex 2.0.1 (new transitive dep of cc)
@weihanglo
library: bump cc to 1.4.3
f2427c4 
Also pulls in

* find-msvc-tools 0.1.5 -> 0.1.11
* shlex 1.3.0 -> 2.0.1
@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-tidy Area: The tidy tool S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 17, 2026
@rustbot

rustbot commented Aug 17, 2026

Copy link
Copy Markdown
Collaborator

Kobzol is not on the review rotation at the moment.
They may take a while to respond.

@weihanglo

weihanglo commented Aug 17, 2026

Copy link
Copy Markdown
Member Author

@bors try @rust-timer queue

and cc @bjorn3 @Kobzol

@rust-timer

This comment has been minimized.

Sign in to view
@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Aug 17, 2026
@rust-bors

This comment has been minimized.

Sign in to view
rust-bors Bot pushed a commit that referenced this pull request Aug 17, 2026
@bors
Auto merge of #161260 - weihanglo:cc-1.4.3, r=<try>
7256718 
chore: bump to cc@1.4.3 for rustc_llvm and library
@weihanglo weihanglo mentioned this pull request Aug 17, 2026
Open
@rust-bors

rust-bors Bot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

☀️ Try build successful (CI)
Build commit: 7256718 (7256718699c6a701d58e50866ab3f86a2ffa8cef)
Base parent: 6d656b1 (6d656b1efca82491a110b476ac9bbe712628ccb6)

@rust-timer

This comment has been minimized.

Sign in to view
@rust-timer

rust-timer commented Aug 17, 2026

Copy link
Copy Markdown
Collaborator

Finished benchmarking commit (7256718): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

This perf run didn't have relevant results for this metric.

Cycles

This perf run didn't have relevant results for this metric.

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 468.493s -> 459.635s (-1.89%)
Artifact size: 398.93 MiB -> 398.87 MiB (-0.01%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Aug 17, 2026
@weihanglo

weihanglo commented Aug 17, 2026

Copy link
Copy Markdown
Member Author

@Kobzol od you know why there is no result? I guess because GitHub was down?

@weihanglo

weihanglo commented Aug 17, 2026

Copy link
Copy Markdown
Member Author

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

Sign in to view
@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Aug 17, 2026
@rust-bors

This comment has been minimized.

Sign in to view
rust-bors Bot pushed a commit that referenced this pull request Aug 17, 2026
@bors
Auto merge of #161260 - weihanglo:cc-1.4.3, r=<try>
52a6c34 
chore: bump to cc@1.4.3 for rustc_llvm and library
@rust-bors

rust-bors Bot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

☀️ Try build successful (CI)
Build commit: 52a6c34 (52a6c343ae344ec730508ef19f1eb62167f1b4ad)
Base parent: e702eca (e702ecae8a3e3756e8a499f8592be1e3efac0e8f)

@rust-timer

This comment has been minimized.

Sign in to view
@rust-timer

rust-timer commented Aug 18, 2026

Copy link
Copy Markdown
Collaborator

Finished benchmarking commit (52a6c34): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

Results (secondary 1.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)		 - - 0
Regressions ❌
(secondary)		 1.6% [0.6%, 2.5%] 2
Improvements ✅
(primary)		 - - 0
Improvements ✅
(secondary)		 - - 0
All ❌✅ (primary) - - 0

Cycles

This perf run didn't have relevant results for this metric.

Binary size

Results (primary 0.1%, secondary 0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)		 0.1% [0.0%, 0.1%] 75
Regressions ❌
(secondary)		 0.1% [0.0%, 0.1%] 114
Improvements ✅
(primary)		 - - 0
Improvements ✅
(secondary)		 - - 0
All ❌✅ (primary) 0.1% [0.0%, 0.1%] 75

Bootstrap: 457.751s -> 457.734s (-0.00%)
Artifact size: 398.90 MiB -> 398.92 MiB (0.00%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Aug 18, 2026
@weihanglo

weihanglo commented Aug 18, 2026

Copy link
Copy Markdown
Member Author

Ah. I see. No relevant largely means insignificant. Then I think this is ready.

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 18, 2026
@weihanglo
weihanglo marked this pull request as ready for review August 18, 2026 01:42
@rustbot

rustbot commented Aug 18, 2026

Copy link
Copy Markdown
Collaborator

These commits modify the library/Cargo.lock file. Unintentional changes to library/Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging.

cc @davidtwco, @BoxyUwU

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

Kobzol
Kobzol reviewed Aug 18, 2026
View reviewed changes

@Kobzol Kobzol left a comment •
edited by rustbot
Loading

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.

Perf runs are good. Though as always, I worry that bumping CC so much will cause various kinds of breakage in various places 🥶 But we should try.

View changes since this review

Comment thread src/bootstrap/src/core/builder/cargo.rs
// Compiler's C deps, like jemalloc and llvm-wrapper, should be
// with the same LTO mode as the Rust code they are linked into.
// FIXME: should we apply LTO to tools and other modes?
let lto_cflag = if self.mode == Mode::Rustc

@Kobzol Kobzol Aug 18, 2026

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.

I think that we should do this for all C/C++ deps, not just compiler ones, so you can remove the mode check.

@Kobzol

Kobzol commented Aug 18, 2026

Copy link
Copy Markdown
Member

Since we already gate this on Clang, I suppose that it should universally support the LTO flag (?), so let's try to do it unconditionally first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Kobzol Kobzol Kobzol left review comments

At least 1 approving review is required to merge this pull request.

Assignees

@Kobzol Kobzol

Labels

A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-tidy Area: The tidy tool S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@weihanglo @rustbot @rust-timer @Kobzol