Use ICF in macOS release builds to reduce binary sizes

[zanieb]

Inspired by denoland/deno#34478

Use --icf=safe for optimized macOS release artifacts, via Rust's bundled Mach-O LLD.

Measurements showed useful size wins on macOS; Linux did not show a meaningful artifact-size improvement and are excluded here. See #19615 (comment)

[astral-sh-bot]

uv test inventory changes

This PR no longer changes the tests when compared with the latest main baseline.

[zanieb]

Hm...

[zsol]

Hmm, how does that change if we do more aggressive ICF? FWIW I'm not entirely sure this amount of wins is worth the (slight) risk of confusing crash reports/coredumps. OTOH this decision is easy to reverse

[zanieb]

I can't tell if this is actually working as intended — I'm going to poke at it more.

[zaniebot]

Measurement data

Moved out of the PR body to keep the summary short.

Observed timings

These are GitHub Actions elapsed job times, not isolated linker benchmarks. The no-ICF cohort uses retained ordinary release builds (1, 2, 3); the ICF cohort uses this PR's first run and rerun. Treat the deltas as directional CI observations: the aarch64 baseline range in particular contains a noisy outlier.

Target	No ICF avg (n=3)	No ICF range	ICF avg (n=2)	ICF range	Delta
x86_64-apple-darwin	7:33	7:22-7:49	7:18	7:16-7:20	-3.3%
aarch64-apple-darwin	8:23	7:17-10:30	7:05	6:56-7:13	-15.5%
x86_64-unknown-linux-gnu	12:03	10:59-12:41	11:36	10:36-12:35	-3.7%

A same-source no-ICF control run toggled only the ICF flags off. Its single elapsed-time sample is slower than the retained cohort, which reinforces that the job-level timings are too noisy to isolate a small linker change:

Target	Same-source no ICF control (n=1)	ICF avg (n=2)	ICF range
x86_64-apple-darwin	10:20	7:18	7:16-7:20
aarch64-apple-darwin	9:38	7:05	6:56-7:13
x86_64-unknown-linux-gnu	12:36	11:36	10:36-12:35

Artifact sizes

This compares wheel artifacts from the same-source no-ICF control run with this PR's ICF rerun. The control commit changes only the workflow ICF toggle.

Wheel artifact	No ICF bytes	ICF bytes	Delta
wheels_uv-macos-x86_64	23278539	22839695	-1.89%
wheels_uv-aarch64-apple-darwin	21760071	21518309	-1.11%
wheels_uv-x86_64-unknown-linux-gnu	24857925	24854207	-0.01%
wheels_uv_build-macos-x86_64	1473768	1467721	-0.41%
wheels_uv_build-aarch64-apple-darwin	1378633	1366300	-0.89%
wheels_uv_build-x86_64-unknown-linux-gnu	1608666	1608905	+0.01%

The corresponding embedded executable deltas are -2.02% for macOS x86_64 uv, -1.41% for macOS aarch64 uv, -0.67% for macOS x86_64 uv-build, -0.66% for macOS aarch64 uv-build, -0.01% for Linux x86_64 GNU uv, and approximately 0.00% for Linux x86_64 GNU uv-build.

[codspeed-hq]

Merging this PR will degrade performance by 5.85%

❌ 1 regressed benchmark
✅ 12 untouched benchmarks

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	WallTime	unpack_sdist_many_files	1 s	1.1 s	-5.85%

Tip

Investigate this regression with the CodSpeed MCP and your agent.

---

_{Comparing zb/icf (c91cff9) with main (89f28ab)}

[zsol]

Seems a bit counterintuitive that runs with ICF are consistently faster. What should we keep an eye out for in terms of potential negative consequences? Nonsense stack traces in panics?