fix: pos_to_line_col always reports column 0#226
Merged
Conversation
The `Break` arm computed the column as `pos - offset.max(pos)`. On that arm `offset` is the byte offset of the previous newline, which is always `<= pos`, so `offset.max(pos)` is always `pos` and the column is always 0. This regressed in g-plane#223, which changed the expression from `pos - offset + 1` to `pos - offset.max(pos)` (the subtraction can never underflow on this arm, so the `max` guard was unnecessary and broke the result). Restore `pos - offset + 1` and add a regression test.
✅ Deploy Preview for markup-fmt ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
5 tasks
Xavrir
added a commit
to Xavrir/deno
that referenced
this pull request
Jun 1, 2026
…gression markup_fmt 0.27.2 introduced a regression in helpers::pos_to_line_col that reports column 0 (g-plane/markup_fmt#226). Pin to the fix commit via [patch.crates-io] to unblock CI; revert to a 0.27.3 version bump once released. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
Xavrir
added a commit
to Xavrir/deno
that referenced
this pull request
Jun 1, 2026
…gression markup_fmt 0.27.2 introduced a regression in helpers::pos_to_line_col that reports column 0 (g-plane/markup_fmt#226). Pin to the fix commit via [patch.crates-io] to unblock CI; revert to a 0.27.3 version bump once released.
g-plane
approved these changes
Jun 2, 2026
Xavrir
added a commit
to Xavrir/deno
that referenced
this pull request
Jun 2, 2026
markup_fmt 0.27.3 includes the upstream fix for the pos_to_line_col column-0 regression (g-plane/markup_fmt#226, now merged and released), so the temporary [patch.crates-io] git pin is no longer needed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In
helpers::pos_to_line_col, theBreakarm computes the column as:On the
Breakarm,offsetis the byte offset of the previous newline, whichis always
<= pos. Thereforeoffset.max(pos)is alwayspos, and the columnis always
0, regardless of the actual position on the line.This regressed in #223, which changed the expression from
pos - offset + 1topos - offset.max(pos). Since the subtraction can never underflow on this arm(
offset <= pos), themaxguard was unnecessary and produced an incorrectresult. As a consequence, every syntax-error message now reports
column 0(e.g.
expected close tag for opening tag <h1> from line 4, column 0instead of... column 2).This PR restores
pos - offset + 1and adds a unit test that pins the column toa non-zero value for positions taking the
Breakarm. The test fails on thecurrent code (
(1, 0)instead of(1, 1)) and passes with the fix.