chore: bump to cc@1.4.3 for rustc_llvm and library

[weihanglo]

View all comments

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:

• Update cc-rs to 1.2.39 #146186
• Update the cc crate for rustc_llvm #155438

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.

[rustbot]

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

[weihanglo]

@bors try @rust-timer queue

and cc @bjorn3 @Kobzol

[rust-bors]

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

[rust-timer]

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%)

[weihanglo]

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

[weihanglo]

@bors try @rust-timer queue

[rust-bors]

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

[rust-timer]

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%)

[weihanglo]

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

@rustbot ready

[weihanglo]

I'm not sure if I understand the question though. Is there something blocking this?

@Kobzol I added this fix 2f9f649, but I am not certain about it. And maybe there are more dockerfile/image need the same tweaks. We may need a systematic fix.

[Kobzol]

That seems fine, we use the same thing for x64. As long as the build passes, we should be good. Further failures we can only get from the ecosystem.

[weihanglo]

@rustbot ready

[weihanglo]

That seems fine, we use the same thing for x64. As long as the build passes, we should be good. Further failures we can only get from the ecosystem.

Considered this as a green light :)

@bors r=Kobzol

[rust-bors]

📌 Commit 055eace has been approved by Kobzol

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 10. This pull request will be tested once the tree is reopened.

Reason for tree closure: Main branch is broken

[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.

[weihanglo]

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.

Rebased to fix import item conflicts. Zero range-diff. Considered it still green.

@bors r=Kobzol

[rust-bors]

📌 Commit 91defaa has been approved by Kobzol

It is now in the queue for this repository.

[rust-bors]

☀️ Test successful - CI
Approved by: Kobzol
Duration: 3h 37m 7s
Pushing 124c16e to main...

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

   Compiling diff v0.1.13
   Compiling glob-match v0.2.1
   Compiling citool v0.1.0 (/home/runner/work/rust/rust/src/ci/citool)
    Finished `release` profile [optimized] target(s) in 54.36s
     Running `target/release/citool post-merge-report c656540d6467dee1381f0cbd882412d6bd1cd5ae 124c16e0de934595dfcdb0845cb39d2bcb8b970d`
Downloading metrics of job aarch64-gnu
Downloading metrics of job arm-android
Downloading metrics of job aarch64-gnu-debug
Downloading metrics of job armhf-gnu
Downloading metrics of job dist-aarch64-linux
Downloading metrics of job dist-android