show linker output even if the linker succeeds

[jyn514]

• show stderr by default
• show stdout if --verbose is passed
• remove both from RUSTC_LOG
• hide the linker cli args unless --verbose is passed

fixes #83436. fixes #38206. fixes #109979. helps with #46998. 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.

[jyn514]

ok, the current problem is that rustc_codegen_gcc ignores RUSTFLAGS=-Alinker-messages, which results in this error:

 error: linker stderr: /usr/bin/ld: /checkout/obj/build/x86_64-unknown-linux-gnu/stage1-tools/cg_gcc/mini_core.mini_core.e55951eb20a0121d-cgu.0.rcgu.o: relocation in read-only section `.rodata.global.c'
       /usr/bin/ld: creating DT_TEXTREL in a shared object

@antoyo how do you prefer i fix this? i can either:

• change y.sh test to respect RUSTFLAGS, which may have other effects on your test suite
• change y.sh test to unconditionally pass -Alinker-warnings
• try and figure out how to fix the linker warning. i would appreciate your help with this.

[jyn514]

actually wait what, where is -D warnings coming from

i don't see that in the flags y.sh passes to rustc

[antoyo]

@jyn514: You can pass the flags through CG_RUSTFLAGS.

[jyn514]

@rustbot ready

note that this is based off of #133633 so you may want to review that first.

[bors]

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

[jyn514]

@bjorn3 this is ready for review :)

[bjorn3]

Apart from some concern about serialization of Span without serializing the corresponding source map, this LGTM.

[bjorn3]

CodegenResults::serialize_rlink doesn't serialize the source map. While it this is fully correct and shouldn't be changed, this means that when a LintExpectation inside CodegenResults gets deserialized in a new compiler session, the Span inside of it will be garbage and similarly for the Span in LintLevelSource. Would it be possible to avoid serializing the spans? Or if not, replace them with DUMMY_SP? I'm not sure how well the linting infrastructure handles garbage spans.

[jieyouxu]

I'm not sure how well the linting infrastructure handles garbage spans.

Probably doesn't handle garbage spans. If the spans are empty or hi < lo, I think that triggers debug assertions.

[bjorn3]

The raw lo and hi values are preserved across the serialization roundtrip (so the lo <= hi invariant is preserved (empty spans are valid and rendered as a span from lo to lo + 1)), however they refer to non-existent parts of the source map.

[jieyouxu]

Hm, if those become OOB, then I think they also trigger debug assertions (or actual assertions) if there's any lint that unwraps when trying to read a SourceMap snippet.

[jyn514]

this indeed crashes currently:

=== STDERR ===
thread 'rustc' panicked at compiler/rustc_span/src/source_map.rs:1056:40:
index out of bounds: the len is 0 but the index is 18446744073709551615

i thought i could solve this by deserializing to a dummy span but that doesn't seem to have worked for some reason? it still gives the same error.

  INFO rustc_codegen_ssa::back::link Deny Node { name: "linker_messages", span: no-location (#0), reason: None }

i think the right fix here is not to use a source span map at all during -Z link-only, to have the emitter return None in Emitter::source_map. but i am not sure exactly how to set that up.

[bors]

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