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

[flake8-type-checking] Adds implementation for TCH007 and TCH008 #12927

Open
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

Daverball
Copy link

@Daverball Daverball commented Aug 16, 2024

This is part of a series of pull requests fulfilling my promise in #9573 to port some of the enhancements and new rules from flake8-type-checking to ruff.

Summary

This adds the missing flake8-type-checking rules TC(H)007 and TC(H)008 including auto fixes.

There is some overlap between TC(H)007 and TC(H)004, currently the existing rule takes precedence, although ideally we would still emit both violations and share a fix for overlaps based on the selected strategy (if it is possible for violations of two different rules to share the same fix). We could probably move the analysis for TC(H007) into the same function as TC(H)004 in order to accomplish that. But we could defer that to a future pull request.

There is also some potential overlap between TC(H)008 and TC(H)010. Currently TC(H)010 is prioritized, but since it currently has no fix it might make more sense to either prioritize TC(H)008 or add a fix for TC(H)010, although that could be covered by a future pull request.

Test Plan

cargo nextest run

The implementation for TCH007 is incomplete and also requires some
changes to TCH004 in order to avoid conflicts between TCH004 and TCH007
Copy link
Contributor

github-actions bot commented Aug 16, 2024

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

ℹ️ ecosystem check detected linter changes. (+5 -0 violations, +0 -0 fixes in 1 projects; 53 projects unchanged)

zulip/zulip (+5 -0 violations, +0 -0 fixes)

ruff check --no-cache --exit-zero --ignore RUF9 --output-format concise --preview --select ALL

+ analytics/views/stats.py:342:14: TCH008 [*] Remove quotes from type alias
+ analytics/views/stats.py:344:16: TCH008 [*] Remove quotes from type alias
+ confirmation/models.py:76:5: TCH008 [*] Remove quotes from type alias
+ confirmation/models.py:77:5: TCH008 [*] Remove quotes from type alias
+ zerver/lib/push_notifications.py:75:49: TCH008 [*] Remove quotes from type alias

Changes by rule (1 rules affected)

code total + violation - violation + fix - fix
TCH008 5 5 0 0 0

@Daverball

This comment was marked as resolved.

Copy link

codspeed-hq bot commented Aug 16, 2024

CodSpeed Performance Report

Merging #12927 will not alter performance

Comparing Daverball:feat/tch007-tch008 (bd31311) with main (591a7a1)

Summary

✅ 32 untouched benchmarks

@Daverball

This comment was marked as resolved.

@Daverball

This comment was marked as resolved.

@Daverball

This comment was marked as resolved.

@Daverball
Copy link
Author

@charliermarsh It might be worth to move the TCH010 logic to where the TCH008 logic currently sits, so we can actually autofix TCH010 in the same cases where we would otherwise emit a TCH008 by removing the quotes when we know that the quoted expression should be entirely available at runtime.

Concretely we would pass it at the stage where we parse deferred string annotations and check if the current parent expression is a | BinOp. Rather than walk the AST of type definitions to collect the string literals (which doesn't appear to currently properly handle deeply nested cases like eg. list["Foo" | None]).

The drawback would be that it may be more difficult to create an autofix in the opposite case that expands the quotes to the entire type expression, since we would need to walk the parent nodes in order to determine the root node of the type expression.

@Daverball Daverball marked this pull request as ready for review August 20, 2024 16:01
@MichaReiser MichaReiser added the rule Implementing or modifying a lint rule label Sep 2, 2024
@charliermarsh
Copy link
Member

Thanks @Daverball, sorry that I haven't had a chance to review this yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rule Implementing or modifying a lint rule
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants