refactor(linter/plugins): pass fix/suggestion offsets to Rust as i64s#19159
Conversation
ea456c1 to
f7e0221
Compare
896e1a6 to
58d4d89
Compare
Merging this PR will not alter performance
Comparing Footnotes
|
There was a problem hiding this comment.
Pull request overview
This PR simplifies JS→Rust fix/suggestion range handling by removing the “+1 offset” workaround and instead representing fix start/end offsets as signed 64-bit integers, enabling -1 (BOM-relative) while still supporting the full u32 range once validated on the Rust side.
Changes:
- Refactors Rust
JsFixto usestart: i64/end: i64and adds validation/conversion logic for negative/out-of-range offsets. - Updates JS plugin
FixReportto sendstart/enddirectly (no+1encoding). - Updates fixture snapshots to reflect new error surfaces and output formatting.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| crates/oxc_linter/src/external_linter.rs | Switches JsFix offsets to i64 and adds conversion/validation path for invalid offsets and BOM -1. |
| apps/oxlint/src-js/plugins/fix.ts | Updates JS-side payload shape to { start, end, text } and adjusts documentation accordingly. |
| apps/oxlint/test/fixtures/suggestions/output.snap.md | Snapshot updates reflecting new error behavior/output. |
| apps/oxlint/test/fixtures/suggestions/fix.snap.md | Snapshot updates reflecting new error behavior/output. |
| apps/oxlint/test/fixtures/suggestions/fix-suggestions.snap.md | Snapshot updates reflecting new error behavior/output. |
| apps/oxlint/test/fixtures/fixes/output.snap.md | Snapshot updates reflecting new error behavior/output. |
| apps/oxlint/test/fixtures/fixes/fix.snap.md | Snapshot updates reflecting new error behavior/output. |
58d4d89 to
f3db61b
Compare
f7e0221 to
6e8ef38
Compare
f3db61b to
215f80e
Compare
215f80e to
7c71615
Compare
Merge activity
|
…`s (#19159) Follow-on after #19092. That PR added 1 to offsets of fixes before sending them to Rust side, to support offset `-1` (legal when fix is to remove a BOM). Upon reflection, I think that solution is too complicated and confusing. Instead, represent `start` and `end` offsets of fixes as `i64`s in `JsFix`. This supports `-1` as an offset, and also the full range of valid `u32` values. Check on Rust side that the values are in range before converting to `u32`s. This also makes for better error messages for invalid offsets - no more inexplicable "Failed to deserialize JSON returned by `lintFile`" errors.
7c71615 to
55be9fe
Compare
…`s (oxc-project#19159) Follow-on after oxc-project#19092. That PR added 1 to offsets of fixes before sending them to Rust side, to support offset `-1` (legal when fix is to remove a BOM). Upon reflection, I think that solution is too complicated and confusing. Instead, represent `start` and `end` offsets of fixes as `i64`s in `JsFix`. This supports `-1` as an offset, and also the full range of valid `u32` values. Check on Rust side that the values are in range before converting to `u32`s. This also makes for better error messages for invalid offsets - no more inexplicable "Failed to deserialize JSON returned by `lintFile`" errors.

Follow-on after #19092.
That PR added 1 to offsets of fixes before sending them to Rust side, to support offset
-1(legal when fix is to remove a BOM).Upon reflection, I think that solution is too complicated and confusing. Instead, represent
startandendoffsets of fixes asi64s inJsFix. This supports-1as an offset, and also the full range of validu32values. Check on Rust side that the values are in range before converting tou32s.This also makes for better error messages for invalid offsets - no more inexplicable "Failed to deserialize JSON returned by
lintFile" errors.