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

(Diagnostics) consider label parameters as global variables #372

Open
Gouvernathor opened this issue Aug 17, 2023 · 0 comments
Open

(Diagnostics) consider label parameters as global variables #372

Gouvernathor opened this issue Aug 17, 2023 · 0 comments

Comments

@Gouvernathor
Copy link
Member

Gouvernathor commented Aug 17, 2023

This is most likely a long-term improvement, and the boundaries of what should and should not be flagged are relatively blurred.
image
Here, you can see that the variable is flagged as not defaulted. But if it's a label parameter (see just above), then the variable exists (as long as you come from that label being called and did not return from it yet, and that's a more difficult if not impossible thing to check).
That variable cannot be unbound (whether the label parameter is defaulted or required), at least while we are in the label block and have not passed another label.
Even a use of highlight_properties in another file may be correct too, because if I jump or call a label of the other file from game_loop, the variable will still be bound.

So, I don't think we can realistically narrow down the issue more than this : every parameter of every label should be marked as correct regarding being defaulted.
The only exception would be a label which doesn't call or jump anywhere, doesn't contain any python (which could jump), screens or custom statements (same) and just returns. In that case we can be sure its parameters are only bound within that label. But asserting that would require pretty heavy reachability analysis.

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

No branches or pull requests

1 participant