-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Collapse multiple dead code warnings into a single diagnostic #97853
Collapse multiple dead code warnings into a single diagnostic #97853
Conversation
r? @davidtwco (rust-highfive has picked a reviewer for you, use r? to override) |
5adad17
to
b7ecc07
Compare
fb7100b
to
8a7cbf5
Compare
Thanks for applying the changes I asked for, the code is much simpler now 🎉. But I'm not sure if I like how this renders -- I would prefer either continuing to be as verbose as we are now, or grouping all 4 of these diagnostics into one, i.e. "these fields are unused". Also this only applies to structs, not enums or unions -- if we want to land this, it should probably be generalized to all ADTs. But I will defer to the reviewer to a call on whether this change is worth merging. |
@compiler-errors Thank you :)
That is a good idea. I will open an issue about that. |
I'm not sure how I feel about this change - implementation looks good, just unsure about the actual change. On the one hand, we're giving the user less output to sift through, which is probably a good thing. On the other hand, if the user looks at one of the diagnostics without the note first, it's now less helpful, which isn't great. I think the best outcome would be to collapse these into a single diagnostic, as has been suggested already. |
@davidtwco |
You can do either, feel free to update this or close it and open a new PR - whichever is easiest for you. |
This comment has been minimized.
This comment has been minimized.
9e9013f
to
8491b73
Compare
compiler/rustc_passes/src/dead.rs
Outdated
( | ||
Node::Item(hir::Item { | ||
kind: | ||
hir::ItemKind::Struct(hir::VariantData::Struct(..), ..) |
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.
Why not Tuple
fields too?
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.
That is because rustc does not warn about tuple fields (positional fields) like the following if I am not wrong.
rust/compiler/rustc_passes/src/dead.rs
Line 653 in 20ad820
!field.is_positional() |
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.
It'd be interesting to see how much noise would be caused by checking tuple fields as well, even if it is only on rustc 👀
I wonder what the original rationale for not doing so was.
I really have a lot of doubts about this change. This brings a lot of additional complexity, manually re-implements some of the lint handling infrastructure, and makes testing more brittle since we can't annotate the whole list of unused fields any more. I'd see such complexity much more keenly if they were making the lint more precise. As we already stopped pointing to the ignored trait derives, half of the output in #97643 is gone. I'm a bit tempted to close the issue and this PR. Other possibility: could such merging of lints be done at the level of the diagnostic infrastructure itself? (It's a naive question, I don't know that code at all.) This would allow to keep a low complexity in the analysis itself, and have the support code handle it, and maybe be much easier to extend to other verbose lints. |
@cjgillot Thank you for your review! I would like to know what the others think about. @rust-lang/wg-diagnostics |
I actually was unaware that the more verbose output had already been mostly suppressed for a much shorter note somewhere between stable and nightly. In that case, I actually probably agree with @cjgillot that this is a lot of overhead for suppressing just a few lines of diagnostics. |
Finished benchmarking commit (3d829a0): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
@TaKO8Ki and @estebank, please don't approve PRs that update cargo to an uncommitted PR. If there is a problem with cargo's tests not passing due to a diagnostic change, please work with the cargo team to change the tests to pass and to have that committed to master before updating the submodule. Thanks! |
Fix tests due to change in dead_code diagnostic. rust-lang/rust#97853 changed some diagnostics which is causing some tests to fail on the latest nightly. This updates the tests to work on both stable and nightly.
@ehuss Ok. I understand. I appreciate your help. |
@ehuss apologies for the breakdown of process. |
This also changed the rls submodule to a commit not in the rls repo (https://github.com/rust-lang/rls/tree/27f4044df03d15c7c38a483c3e4635cf4f51807d), which means currently I cannot build rustc locally since it fails to fetch that commit. |
Can this PR be reverted to get the repo into a state again where its submodules point to existing commits? |
@RalfJung Wouldn't merging this pull request solve this provlem? rust-lang/rls#1780 |
Maybe, but when a PR has unintended side-effects the right reaction is to back it out and try again -- not to hurry and land some fix in a haste. |
Don't worry, we do want to have your PR. :) We just want to make sure that it doesn't break anything else, and (due to no fault of yours -- the process should have caught this) this PR caused more trouble than it should. I know seeing one's PR reverted can be frustrating, but this is really just a temporary thing, and then we have all the time we need to figure out how to land this properly without causing trouble. |
This merges this commit into RLS master; it was pulled into rust-lang/rust by mistake in rust-lang/rust#97853 before it was merged into rust-lang/rls master branch. The commit in its raw form is persisted on rust-lang/rls by way of a new branch (retain-for-rustc-3d829a0922d865d7a77fb284424fd8ba6afaea3b), and after being merged into master we will bump rust-lang/rust to the latest version of rust-lang/rls master.
Of primary interest, this merges rust-lang/rls@ece09b8 into rust-lang/rust, which brings in the changes that fix RLS tests broken by rust-lang#97853. rust-lang#97853 already introduced that commit's changes (under 27f4044df03d15c7c38a483c3e4635cf4f51807d) but without putting those changes on rust-lang/rls as a branch, so we ended up with an orphan commit that caused trouble when updating submodules in rust-lang/rust. This commit, once merged into rust-lang/rust, should continue to let RLS tests to pass on rust-lang/rust's side and move us back into a healthy state where tip of the submodule points to a valid master commit in the rust-lang/rls repository.
OK, I've now posted branches to both rust-lang/cargo and rust-lang/rls to preserve the wrongly-introduced commits for the future; that will likely already fix the submodule updates (but I have no confirmation as of this commit from users reporting breakage). We've already bumped Cargo since this PR in #98395, which moved us back onto Cargo master. I've also posted #98488 to move us back onto RLS master, and nominated for beta backport (to the beta branching next week; i.e., 1.63). I believe that should resolve the problem here and avoid a revert which would've been annoying to backport to 1.63 and such. |
@RalfJung Thanks. Is there anything I can help? |
…lbini Bump RLS to latest master on rust-lang/rls Of primary interest, this merges rust-lang/rls@ece09b8 into rust-lang/rust, which brings in the changes that fix RLS tests broken by rust-lang#97853. rust-lang#97853 already introduced that commit's changes (under rust-lang/rls@27f4044) but without putting those changes on rust-lang/rls as a branch, so we ended up with an orphan commit that caused trouble when updating submodules in rust-lang/rust. This commit, once merged into rust-lang/rust, should continue to let RLS tests to pass on rust-lang/rust's side and move us back into a healthy state where tip of the submodule points to a valid master commit in the rust-lang/rls repository. cc rust-lang#98451, but not marking as fixed as I believe we need to add verification to prevent future oversights.
…lbini Bump RLS to latest master on rust-lang/rls Of primary interest, this merges rust-lang/rls@ece09b8 into rust-lang/rust, which brings in the changes that fix RLS tests broken by rust-lang#97853. rust-lang#97853 already introduced that commit's changes (under rust-lang/rls@27f4044) but without putting those changes on rust-lang/rls as a branch, so we ended up with an orphan commit that caused trouble when updating submodules in rust-lang/rust. This commit, once merged into rust-lang/rust, should continue to let RLS tests to pass on rust-lang/rust's side and move us back into a healthy state where tip of the submodule points to a valid master commit in the rust-lang/rls repository. cc rust-lang#98451, but not marking as fixed as I believe we need to add verification to prevent future oversights.
…lbini Bump RLS to latest master on rust-lang/rls Of primary interest, this merges rust-lang/rls@ece09b8 into rust-lang/rust, which brings in the changes that fix RLS tests broken by rust-lang#97853. rust-lang#97853 already introduced that commit's changes (under rust-lang/rls@27f4044) but without putting those changes on rust-lang/rls as a branch, so we ended up with an orphan commit that caused trouble when updating submodules in rust-lang/rust. This commit, once merged into rust-lang/rust, should continue to let RLS tests to pass on rust-lang/rust's side and move us back into a healthy state where tip of the submodule points to a valid master commit in the rust-lang/rls repository. cc rust-lang#98451, but not marking as fixed as I believe we need to add verification to prevent future oversights.
Of primary interest, this merges rust-lang/rls@ece09b8 into rust-lang/rust, which brings in the changes that fix RLS tests broken by rust-lang#97853. rust-lang#97853 already introduced that commit's changes (under 27f4044df03d15c7c38a483c3e4635cf4f51807d) but without putting those changes on rust-lang/rls as a branch, so we ended up with an orphan commit that caused trouble when updating submodules in rust-lang/rust. This commit, once merged into rust-lang/rust, should continue to let RLS tests to pass on rust-lang/rust's side and move us back into a healthy state where tip of the submodule points to a valid master commit in the rust-lang/rls repository.
Fix tests due to change in dead_code diagnostic. rust-lang/rust#97853 changed some diagnostics which is causing some tests to fail on the latest nightly. This updates the tests to work on both stable and nightly.
…r=lcnr dead-code-lint: de-dup multiple unused assoc functions Fixes rust-lang#109600 Prior art: rust-lang#97853
closes #97643