-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
show linker output even if the linker succeeds #119286
base: master
Are you sure you want to change the base?
Conversation
|
060a457
to
a34d7ae
Compare
This comment has been minimized.
This comment has been minimized.
64cb47a
to
ab6fb2b
Compare
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 |
This comment has been minimized.
This comment has been minimized.
ab6fb2b
to
ba4425d
Compare
ba4425d
to
43edbe0
Compare
☔ The latest upstream changes (presumably #119662) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
hmm. that test has the following comment: rust/tests/incremental/commandline-args.rs Lines 13 to 20 in e9a009f
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? |
Sure |
I prefer not doing this. It is helpful whenever a linkage issue is opened to not have to ask to rerun with |
6906d56
to
23216bc
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
ok, the current problem is that rustc_codegen_gcc ignores RUSTFLAGS=-Alinker-messages, which results in this error:
@antoyo how do you prefer i fix this? i can either:
|
actually wait what, where is -D warnings coming from i don't see that in the flags y.sh passes to rustc |
@jyn514: You can pass the flags through |
☔ The latest upstream changes (presumably #134052) made this pull request unmergeable. Please resolve the merge conflicts. |
…jyn514 don't show the full linker args unless `--verbose` is passed the linker arguments can be *very* long, especially for crates with many dependencies. often they are not useful. omit them unless the user specifically requests them. split out from rust-lang#119286. fixes rust-lang#109979. r? `@bjorn3`
…jyn514 don't show the full linker args unless `--verbose` is passed the linker arguments can be *very* long, especially for crates with many dependencies. often they are not useful. omit them unless the user specifically requests them. split out from rust-lang#119286. fixes rust-lang#109979. r? ``@bjorn3``
…jyn514 don't show the full linker args unless `--verbose` is passed the linker arguments can be *very* long, especially for crates with many dependencies. often they are not useful. omit them unless the user specifically requests them. split out from rust-lang#119286. fixes rust-lang#109979. r? ```@bjorn3```
…jyn514 don't show the full linker args unless `--verbose` is passed the linker arguments can be *very* long, especially for crates with many dependencies. often they are not useful. omit them unless the user specifically requests them. split out from rust-lang#119286. fixes rust-lang#109979. r? ````@bjorn3````
don't show the full linker args unless `--verbose` is passed the linker arguments can be *very* long, especially for crates with many dependencies. often they are not useful. omit them unless the user specifically requests them. split out from rust-lang#119286. fixes rust-lang#109979. r? `@bjorn3` try-build: dist-x86_64-linux
…jyn514 don't show the full linker args unless `--verbose` is passed the linker arguments can be *very* long, especially for crates with many dependencies. often they are not useful. omit them unless the user specifically requests them. split out from rust-lang#119286. fixes rust-lang#109979. r? `@bjorn3` try-build: dist-x86_64-linux
…jyn514 don't show the full linker args unless `--verbose` is passed the linker arguments can be *very* long, especially for crates with many dependencies. often they are not useful. omit them unless the user specifically requests them. split out from rust-lang#119286. fixes rust-lang#109979. r? ``@bjorn3`` try-build: dist-x86_64-linux
don't show the full linker args unless `--verbose` is passed the linker arguments can be *very* long, especially for crates with many dependencies. often they are not useful. omit them unless the user specifically requests them. split out from rust-lang#119286. fixes rust-lang#109979. r? `@bjorn3` try-build: i686-mingw
…jyn514 don't show the full linker args unless `--verbose` is passed the linker arguments can be *very* long, especially for crates with many dependencies. often they are not useful. omit them unless the user specifically requests them. split out from rust-lang#119286. fixes rust-lang#109979. r? `@bjorn3` try-build: i686-mingw
Rollup merge of rust-lang#133633 - jyn514:hide-linker-args, r=bjorn3,jyn514 don't show the full linker args unless `--verbose` is passed the linker arguments can be *very* long, especially for crates with many dependencies. often they are not useful. omit them unless the user specifically requests them. split out from rust-lang#119286. fixes rust-lang#109979. r? `@bjorn3` try-build: i686-mingw
this was slightly complicated because codegen_ssa doesn't have access to a tcx.
b3b0202
to
f89d8db
Compare
@bjorn3 this is ready for review :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from some concern about serialization of Span
without serializing the corresponding source map, this LGTM.
@@ -173,7 +173,7 @@ impl TyCtxt<'_> { | |||
/// This struct represents a lint expectation and holds all required information | |||
/// to emit the `unfulfilled_lint_expectations` lint if it is unfulfilled after | |||
/// the `LateLintPass` has completed. | |||
#[derive(Clone, Debug, HashStable)] | |||
#[derive(Clone, Debug, Encodable, Decodable, HashStable)] | |||
pub struct LintExpectation { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
--verbose
is passed--verbose
is passedfixes #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