-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
RUF012 false positive with annotations set as strings #12288
Comments
I think this is the case for other rules as well like |
👍 Yeah we would need to parse these. I wonder if we should consider parsing these in the parser and adding them to the AST... |
Actually, we probably can't do that because you often need semantic information to know if a string is a type annotation. |
We do parse it: https://github.com/astral-sh/ruff/blob/ecd6865d2800a574baf122583b6e463605af2ef5/crates/ruff_python_parser/src/typing.rs; I guess we need to provide some API to resolve it to the AST node if the model is in a type annotation context. |
Yeah we just parse it much later, at the end IIRC. |
Perhaps we could parse these on-demand and store them on the semantic model. |
I guess that might not work because in theory these need to be evaluated lazily, at the very end (e.g., they can reference symbols that are imported afterwards, IIRC). |
At least for these 3 rules, they all require a class node which means we can store them in ruff/crates/ruff_linter/src/checkers/ast/deferred.rs Lines 30 to 37 in ecd6865
deferred_class.rs (similar to deferred_lambdas.rs ) to check for violations for these rules. We might want to update existing logic to not raise a violation if the annotation is a string.
|
minimal case:
with
ruff 0.5.1
I got the errorfor
cv_str
,cv_final_str
anduse_case
(that was my initial scenario...)The text was updated successfully, but these errors were encountered: