-
-
Notifications
You must be signed in to change notification settings - Fork 736
refactor(oxlint/lsp): store Option<Vec<FixedContent>> for DiagnosticReport code action part
#16514
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR refactors the diagnostic code action data structure in the language server, replacing the PossibleFixContent enum with an Option<LinterCodeAction> design. This simplifies the code by using a more direct representation where None indicates no fixes and Some(LinterCodeAction) contains a vector of available fixes.
Key changes:
- Replaced
PossibleFixContentenum (None/Single/Multiple variants) withOption<LinterCodeAction>containingVec<FixedContent> - Refactored
add_ignore_fixesto mutate a vector instead of returning a transformed enum - Updated code action generation logic to work with the new structure using
filter_map
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 10 comments.
| File | Description |
|---|---|
crates/oxc_language_server/src/linter/error_with_position.rs |
Introduces LinterCodeAction struct, removes PossibleFixContent enum, and refactors message_to_lsp_diagnostic and add_ignore_fixes to use mutable vector approach |
crates/oxc_language_server/src/linter/code_actions.rs |
Updates function signatures to accept LinterCodeAction references and simplifies logic by working directly with vectors instead of enum matching |
crates/oxc_language_server/src/linter/server_linter.rs |
Adapts code action generation to use filter_map with the new Option<LinterCodeAction> structure |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
e12d085 to
a7fa043
Compare
b27f09a to
648a732
Compare
648a732 to
c82b7b0
Compare
c82b7b0 to
058e234
Compare
Merge activity
|
…icReport` code action part (#16514) > This PR refactors the diagnostic code action data structure in the language server, replacing the PossibleFixContent enum with an Option<LinterCodeAction> design. This simplifies the code by using a more direct representation where None indicates no fixes and Some(LinterCodeAction) contains a vector of available fixes. Because the fixes are mostly 2 or more, this data struct is better (that what ChatGPT told me). 2 for ignoring the diagnostic for the line/file and possible more for fixing it. The only time a fix is zero or one is when a parser error happened or an unused disable directive is reported. > Given: > -mostly None > -often multiple fixes (≥3) > -rarely Single > → You should prefer the Option<Vec<FixedContent>> version. > ✔️ Smaller memory use for the dominant cases > ✔️ No enum tag overhead > ✔️ Only one representation (Vec) simplifies code > ✔️ Very efficient for multiple items > ✔️ No downside since Single is rare
058e234 to
316ef44
Compare

Because the fixes are mostly 2 or more, this data struct is better (that what ChatGPT told me).
2 for ignoring the diagnostic for the line/file and possible more for fixing it.
The only time a fix is zero or one is when a parser error happened or an unused disable directive is reported.