show linker output even if the linker succeeds

[jyn514]

Show stderr and stderr by default, controlled by a new linker_messages lint.

fixes #83436. fixes #38206. cc https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/uplift.20some.20-Zverbose.20calls.20and.20rename.20to.E2.80.A6.20compiler-team.23706/near/408986134

try-job: aarch64-apple

r? @bjorn3

[rustbot]

rustc_macros::diagnostics was changed

cc @davidtwco, @compiler-errors, @TaKO8Ki

[jyn514]

hmm actually this is a slight expansion of scope but @bjorn3 how would you feel about not printing the giant list of linker arguments unless someone passes --verbose (#109979)

[jyn514]

also i know we settled on not showing stdout by default but it's useful for debugging search paths - maybe we should show it after all? it seems silly to have to pass both -Wl,--verbose and --verbose. #46998 (comment)

[bors]

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

[jyn514]

hmm. that test has the following comment:

rust/tests/incremental/commandline-args.rs

Lines 13 to 20 in e9a009f

	// Between revisions 1 and 2, we are changing the debuginfo-level, which should
	// invalidate the cache. Between revisions 2 and 3, we are adding `--verbose`
	// which should have no effect on the cache. Between revisions, we are adding
	// `--remap-path-prefix` which should invalidate the cache:
	//[rpass1] compile-flags: -C debuginfo=0
	//[rpass2] compile-flags: -C debuginfo=2
	//[rpass3] compile-flags: -C debuginfo=2 --verbose
	//[rpass4] compile-flags: -C debuginfo=2 --verbose --remap-path-prefix=/home/bors/rust=src

i suppose those lines are all invalid now, it should be testing that the CGU is not reused? i'm not sure why it's testing --verbose specifically, maybe it's enough to test any untracked CLI arg. i'll change it to --diagnostic-width.

i'm realizing your comments are all about #119129. i feel slightly uncomfortable making unrelated changes in this PR ... how do you feel about splitting them into a separate PR so i can assign michaelwoerister?

[bjorn3]

how do you feel about splitting them into a separate PR so i can assign michaelwoerister?

Sure

[bjorn3]

hide the linker cli args unless --verbose is passed

I prefer not doing this. It is helpful whenever a linkage issue is opened to not have to ask to rerun with RUSTFLAGS="--verbose". If you revert this change r=me. If you still want to keep it, let me thing about it for a bit.

[bors]

⌛ Testing commit 8b92619 with merge 2524b21...

[rust-log-analyzer]

The job x86_64-mingw-1 failed! Check out the build log: (web) (plain)

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

[RUSTC-TIMING] rustc_std_workspace_core test:false 0.175
error: could not compile `rustc-std-workspace-core` (lib)

Caused by:
  process didn't exit successfully: `D:\a\rust\rust\build\bootstrap\debug\rustc 'D:\a\rust\rust\build\bootstrap\debug\rustc' --crate-name rustc_std_workspace_core --edition=2021 'library\rustc-std-workspace-core\lib.rs' --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C codegen-units=1 -C debug-assertions=on --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values())' -C metadata=9582fd8c2723cb5a -C extra-filename=-6ff60ea8d941e302 --out-dir 'D:\a\rust\rust\build\x86_64-pc-windows-gnu\stage1-std\x86_64-pc-windows-gnu\release\deps' --target x86_64-pc-windows-gnu -L 'dependency=D:\a\rust\rust\build\x86_64-pc-windows-gnu\stage1-std\x86_64-pc-windows-gnu\release\deps' -L 'dependency=D:\a\rust\rust\build\x86_64-pc-windows-gnu\stage1-std\release\deps' --extern 'core=D:\a\rust\rust\build\x86_64-pc-windows-gnu\stage1-std\x86_64-pc-windows-gnu\release\deps\libcore-d39d7221210743d5.rmeta' -Csymbol-mangling-version=legacy '--check-cfg=cfg(feature,values(any()))' -Zunstable-options '--check-cfg=cfg(bootstrap)' -Zmacro-backtrace -Csplit-debuginfo=packed -Cprefer-dynamic -Zinline-mir -Zinline-mir-preserve-debug -Zmir_strip_debuginfo=locals-in-tiny-functions -Alinker-messages -Cembed-bitcode=yes -Cforce-frame-pointers=yes '-Zcrate-attr=doc(html_root_url="https://doc.rust-lang.org/nightly/")' -Z binary-dep-depinfo` (exit code: 0xc00000fd, STATUS_STACK_OVERFLOW)
[RUSTC-TIMING] libc test:false 0.183
[RUSTC-TIMING] compiler_builtins test:false 5.147
[RUSTC-TIMING] core test:false 37.219
Build completed unsuccessfully in 0:41:00
Build completed unsuccessfully in 0:41:00
make: *** [Makefile:120: ci-mingw-x] Error 1
  network time: Sat, 25 Jan 2025 15:10:06 GMT
##[error]Process completed with exit code 2.
Post job cleanup.
[command]"C:\Program Files\Git\bin\git.exe" version

[bors]

💔 Test failed - checks-actions

[jyn514]

probably spurious?

     Compiling rustc-std-workspace-core v1.99.0 (D:\a\rust\rust\library\rustc-std-workspace-core)
  
  thread 'main' has overflowed its stack

@bors retry

[bors]

⌛ Testing commit 8b92619 with merge f7cc13a...

[ChrisDenton]

probably spurious?

     Compiling rustc-std-workspace-core v1.99.0 (D:\a\rust\rust\library\rustc-std-workspace-core)
  
  thread 'main' has overflowed its stack

A stack overflow is probably not spurious. Or if it is then it's a new one.

[bors]

☀️ Test successful - checks-actions
Approved by: bjorn3
Pushing f7cc13a to master...

[madsmtm]

Wow, thanks for getting this in Jyn, this is a really good idea, and a massive amount of work!

[nicholasbishop]

apparently lld unconditionally warns when compiling any program with debuginfo for UEFI

Thanks for the heads up on this. Fortunately it looks like this is only an issue with the less common target i686-unknown-uefi. x86_64-unknown-uefi and aarch64-unknown-uefi do not produce any unwanted linker output. I'll take a look at i686.

[rust-timer]

Finished benchmarking commit (f7cc13a): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.1%, 0.4%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	2
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 0.7%, secondary -1.7%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.5%	[0.5%, 2.6%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.0%	[-1.0%, -1.0%]	1
Improvements ✅ (secondary)	-1.7%	[-1.7%, -1.7%]	1
All ❌✅ (primary)	0.7%	[-1.0%, 2.6%]	3

Cycles

Results (primary -2.2%, secondary 2.6%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.6%	[2.6%, 2.6%]	1
Improvements ✅ (primary)	-2.2%	[-2.2%, -2.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.2%	[-2.2%, -2.2%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 770.579s -> 771.158s (0.08%)
Artifact size: 325.79 MiB -> 325.82 MiB (0.01%)