You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is most likely a long-term improvement, and the boundaries of what should and should not be flagged are relatively blurred.
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.
The text was updated successfully, but these errors were encountered:
This is most likely a long-term improvement, and the boundaries of what should and should not be flagged are relatively blurred.
![image](https://private-user-images.githubusercontent.com/44340603/261289550-10656256-ae99-49c9-8e76-263c74f9203c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTkxODQyMjIsIm5iZiI6MTcxOTE4MzkyMiwicGF0aCI6Ii80NDM0MDYwMy8yNjEyODk1NTAtMTA2NTYyNTYtYWU5OS00OWM5LThlNzYtMjYzYzc0ZjkyMDNjLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA2MjMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNjIzVDIzMDUyMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTViNDA2M2QwZDdiZTI4MjVjZjhhOTE1OWExYzQ2MmFhYTYwZWEzNmFhZGE3Y2Q2YTkzMWNmZDRmNjljNTI3ZjkmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.UPFaogrxEDy3nddzGn4xkqrMUyB2juGdEf8cGWTIBHc)
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.
The text was updated successfully, but these errors were encountered: