Optimize type checking range lookup with binary search

[DebanKsahu]

Pull Request

Key changes include:

Functional Improvements:

• Improved the logic for checking if an AST node is inside a TYPE_CHECKING block by sorting the ranges and using bisect_right for efficient range lookup in _in_type_checking, enhancing both correctness and performance.
• Ensured that the list of ranges for TYPE_CHECKING blocks is always sorted before use, which is necessary for the new binary search approach.

Code Style and Readability:

• All other changes are due to ruff format and ruff check --fix

Change Type

• Bug fix
• Feature
• Documentation
• Refactoring
• Improvement

[lukasniessen-bain]

Thanks for the contribution. I don’t think we should merge the binary-search optimization for _in_type_checking() as part of this PR.

The current implementation uses any(start <= lineno <= end for start, end in ranges), which is very straightforward and easy to reason about. In practice, I would expect the number of TYPE_CHECKING blocks per file to be very small, often zero or one, so the performance benefit from replacing this with sorting plus bisect_right() is likely to be negligible.

Even if the new implementation is correct, it adds complexity to code that is currently simple. It also makes the behavior harder to reason about in edge cases such as overlapping or nested ranges, because the binary-search version only checks one candidate range instead of naturally checking all ranges. From a KISS perspective, I don’t think the likely performance gain justifies the added complexity and maintenance cost here.

The normalization change looks reasonable to me, though: precomputing the normalized Python file set avoids rebuilding it repeatedly and keeps the code simple.

Could you please update the PR so it only includes the normalized file set change, and leaves the _in_type_checking() implementation as-is?

[DebanKsahu]

Sure.