feat(linter/plugins): implement code path analysis (CFG)#17229
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
There was a problem hiding this comment.
Pull request overview
This PR implements Control Flow Graph (CFG) analysis, also known as "Code Path Analysis" in ESLint terminology, which was the last remaining gap in the plugin API. The implementation integrates ESLint's code path analysis functionality to support CFG event handlers like onCodePathStart, onCodePathEnd, etc., enabling plugin rules that depend on control flow information.
Key changes:
- Added CFG event handlers support to the visitor system
- Implemented CFG construction using ESLint's
CodePathAnalyzer - Extended type ID mappings to include CFG event names
- Added comprehensive test fixtures to verify CFG functionality and error handling
Reviewed changes
Copilot reviewed 19 out of 22 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| apps/oxlint/src-js/plugins/cfg.ts | New module implementing CFG construction and AST walking with CFG events |
| apps/oxlint/src-js/plugins/visitor.ts | Extended visitor compilation to support CFG event handlers with new VISITOR_CFG state |
| apps/oxlint/src-js/plugins/lint.ts | Integrated CFG walking when visitor contains CFG event listeners |
| apps/oxlint/src-js/plugins/selector.ts | Added filtering to exclude CFG event names from node type selectors |
| apps/oxlint/src-js/generated/type_ids.ts | Added CFG event names to type ID mappings |
| tasks/ast_tools/src/generators/estree_visit.rs | Modified codegen to include CFG event names in type ID map |
| apps/oxlint/test/fixtures/cfg/* | Added test fixtures to verify CFG event handling |
| apps/oxlint/test/fixtures/lint_visit_cfg_error/* | Added test fixtures to verify error handling and state reset |
| apps/oxlint/conformance/src/filter.ts | Removed CFG-dependent rules from exclusion list |
| pnpm-lock.yaml, apps/oxlint/package.json | Added @eslint/plugin-kit dependency for CFG types |
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
6427333 to
cc6d0cf
Compare
Merge activity
|
Implement CFG (or "code path analysis" as ESLint calls it). This is the was the last remaining gap in our API. The implementation is pretty slow, I imagine. I've pulled in ESLint's code for the actual control flow graph construction, and copied ESLint's code for the rest. Fitting with how we combine enter and exit nodes for leaf nodes (`Identifier`s etc) required skipping creating "steps" for exiting leaf nodes, which should also be a perf gain, as they're so common. But that apart, I've made no effort to optimize it. There's plenty of scope for improving it. I've added comments with some starting points for doing that, and will open an issue in the hope someone would like to pick up on that. I also cannot for the life of me figure out how to add the CFG event handlers (`onCodePathStart` etc) to `VisitorObject` type, without breaking everything. Me and Claude went at it for about an hour, and got nowhere. So I'm just leaving that for now.
cc6d0cf to
d913f87
Compare

Implement CFG (or "code path analysis" as ESLint calls it).
This is the was the last remaining gap in our API.
The implementation is pretty slow, I imagine. I've pulled in ESLint's code for the actual control flow graph construction, and copied ESLint's code for the rest.
Fitting with how we combine enter and exit nodes for leaf nodes (
Identifiers etc) required skipping creating "steps" for exiting leaf nodes, which should also be a perf gain, as they're so common. But that apart, I've made no effort to optimize it. There's plenty of scope for improving it. I've added comments with some starting points for doing that, and will open an issue in the hope someone would like to pick up on that.I also cannot for the life of me figure out how to add the CFG event handlers (
onCodePathStartetc) toVisitorObjecttype, without breaking everything. Me and Claude went at it for about an hour, and got nowhere. So I'm just leaving that for now.