-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Control flow graph: setup #17064
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
Control flow graph: setup #17064
Conversation
|
code | total | + violation | - violation | + fix | - fix |
---|---|---|---|---|---|
PLW0101 | 25 | 0 | 25 | 0 | 0 |
Formatter (stable)
✅ ecosystem check detected no format changes.
Formatter (preview)
✅ ecosystem check detected no format changes.
I don't think I follow your PR approach. Is the idea that you want to reuse this PR as the target of stacked PRs later on? If so, what's the reason for merging the stacked PRs into this PR over directly merging to main (the To phrase it differently. What prevents us from merging this to main? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This overall looks good to me. I left a few in detail comments.
The biggest one is whether we want to consider an alternative representation for Block
and Edge
s that avoids the nested vectors, which is also something we can consider doing as a separate PR (and maybe even better to get an understanding for the performance characteristics)
crates/ruff_linter/resources/test/fixtures/pylint/unreachable.py
Outdated
Show resolved
Hide resolved
Nothing prevents us from merging into main except that the code would just be sitting there not used for anything for a bit. If it makes things less complicated I'm happy to just do sequential PRs directly into main! |
That seems not much different from the unreachable code that's already on main. I'm all for merging to main because it makes our live easier. |
* main: [red-knot] Add property tests for callable types (#17006) [red-knot] Disjointness for callable types (#17094) [red-knot] Flatten `Type::Callable` into four `Type` variants (#17126) mdtest.py: do a full mdtest run immediately when the script is executed (#17128) [red-knot] Fix callable subtyping for standard parameters (#17125) [red-knot] Fix more `redundant-cast` false positives (#17119) Sync vendored typeshed stubs (#17106) [red-knot] support Any as a class in typeshed (#17107) Visit `Identifier` node as part of the `SourceOrderVisitor` (#17110) [red-knot] Don't infer Todo for quite so many tuple type expressions (#17116) CI: Run pre-commit on depot machine (#17120) Error instead of `panic!` when running Ruff from a deleted directory (#16903) (#17054) Control flow graph: setup (#17064) [red-knot] Playground improvements (#17109) [red-knot] IDE crate (#17045) Update dependency vite to v6.2.4 (#17104) [red-knot] Add redundant-cast error (#17100) [red-knot] Narrowing on `in tuple[...]` and `in str` (#17059)
This PR contains the scaffolding for a new control flow graph implementation, along with its application to the
unreachable
rule. At the moment, the implementation is a maximal over-approximation: no control flow is modeled and all statements are counted as reachable. With each additional statement type we support, this approximation will improve.So this PR just contains:
ControlFlowGraph
struct and builderunreachable
using the new structsunreachable
Instructions for Viewing Mermaid snapshots
Unfortunately I don't know how to convince GitHub to render the Mermaid graphs in the snapshots. However, you can view these locally in VSCode if you install an extension that supports Mermaid graphs in Markdown, and then add this to your
settings.json
: