Skip to content
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

Fix wunused false positive on CanEqual #18641

Merged
merged 2 commits into from
Oct 10, 2023
Merged

Fix wunused false positive on CanEqual #18641

merged 2 commits into from
Oct 10, 2023

Conversation

szymon-rd
Copy link
Member

Fixes #17762

* Ignore CanEqual imports
*/
private def isImportIgnored(imp: tpd.Import, sel: ImportSelector)(using Context): Boolean =
(sel.isWildcard && imp.expr.tpe.allMembers.exists(p => p.symbol.typeRef.baseClasses.exists(_.derivesFrom(defn.CanEqualClass)))) ||
Copy link
Member

@bishabosha bishabosha Oct 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is problematic because perhaps it only imports CanEqual's that are not even used. Perhaps it makes more sense to record the CanEqual usages in the typer?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also this should check if its also a "given" import, rather than "*"

Copy link
Member Author

@szymon-rd szymon-rd Oct 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, after a lengthy discussion with Martin and the team and making some PoCs, we decided that extracting that information from Typer is unfeasible without making the Typer and Implicit resolution slower / more complex. So we want to emulate it or fix false positives. But I will address the second comment 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Emulating the feature will require summoning the exact same implicit again wont it? seems like even more work

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, and this logic could get even more complex I suppose given that it is a type param, and the resolution is pre typer vs the emulation would be post typer. Not a good idea

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im not sure how it works, but might it produce more accurate warnings if you only ignore warnings generated by the import selector when the specific unused symbol derives from CanEqual?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's pretty much what we are doing here

Copy link
Member

@bishabosha bishabosha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approve for ignoring only wildcard given

@szymon-rd szymon-rd merged commit a133b41 into main Oct 10, 2023
35 checks passed
@szymon-rd szymon-rd deleted the can-equal-wunused branch October 10, 2023 15:23
@Kordyjan Kordyjan added this to the 3.4.0 milestone Dec 20, 2023
WojciechMazur added a commit that referenced this pull request Jun 20, 2024
Backports #18641 to the LTS branch.

PR submitted by the release tooling.
[skip ci]
WojciechMazur added a commit that referenced this pull request Jun 20, 2024
Backports #18641 to the LTS branch.

PR submitted by the release tooling.
[skip ci]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

spurious unused warning of local given for CanEqual with -Wunused:locals and -language:strictEquality
3 participants