Skip to content

Fix false positive with nested shadowed alias #13564

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

Merged
merged 4 commits into from
May 16, 2024

Conversation

sabiwara
Copy link
Contributor

Closes #13563.

For now, I went with the suggestion to fix the issue:

Perhaps we could track the scope of the alias in such cases (for example, only consider it overridden if outside of a function?).

We might be able to do something even smarter with function in order to track unused shadowing within a function, I'm not sure yet, will keep exploring. Otherwise seems like a good compromise if this keeps the state simpler.

trace({alias, Meta, _Old, New, Opts}, #{lexical_tracker := Pid}) ->
?tracker:add_alias(Pid, New, Meta, should_warn(Meta, Opts)),
trace({alias, Meta, _Old, New, Opts}, #{lexical_tracker := Pid, function := Function}) ->
?tracker:add_alias(Pid, New, Meta, should_warn(Meta, Opts), Function),
Copy link
Member

Choose a reason for hiding this comment

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

Super massive nitpick:

Suggested change
?tracker:add_alias(Pid, New, Meta, should_warn(Meta, Opts), Function),
?tracker:add_alias(Pid, New, Meta, should_warn(Meta, Opts), Function /= nil),

So we send less data to the GenServer. :)

Copy link
Contributor Author

@sabiwara sabiwara May 16, 2024

Choose a reason for hiding this comment

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

493727c too much, WDYT?
Since both variables were about how to warn. Might also be less confusing than the double bool.

Copy link
Member

Choose a reason for hiding this comment

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

Too much in my opinion. I feel like I need to undo the warn logic when I have to understand its impact in the lexical tracker. While checking for warn and function? had a clearer meaning to me. WDYT?

Copy link
Contributor Author

@sabiwara sabiwara May 16, 2024

Choose a reason for hiding this comment

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

I'm fine either way.

I liked the idea of having the emitting part decide what to warn, with atom names to explain, and the receiving part just following instructions.

The downside with the non-bool atom is that I needed to come up with names (not fully satisfied with :except_unused_shadowed), and also that we'd probably need guards to make sure we don't emit something else and end up with some random accidental behavior. Finally, consistency with other messages of the module is also a strong point to keep booleans.

Will revert to the double bool!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@sabiwara sabiwara merged commit 8dc94db into elixir-lang:main May 16, 2024
8 of 9 checks passed
@sabiwara sabiwara deleted the nested-shadow-alias branch May 16, 2024 23:13
sabiwara added a commit to sabiwara/elixir that referenced this pull request May 17, 2024
sabiwara added a commit that referenced this pull request May 18, 2024
* Revert "Fix false positive with nested shadowed alias (#13564)"

This reverts commit 8dc94db.

* Revert "Warn on unused shadowed aliases (#13550)"

This reverts commit d1b3063.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

False positive alias warning on main
2 participants