Repository navigation
Conversation
Author
|
The one failing check here is not from this change. The same job fails identically on other open PRs that do not touch parsing — run 38073613876 on Every other check passes: the 3.9-3.13 test matrix on Ubuntu, macOS and Windows, and the five other integration jobs. Failure log: https://github.com/python-poetry/tomlkit/actions/runs/38060239938/job/114236854801 |
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
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.
Summary
The line and column reported in a parse error depend on the document's line endings.
Source._to_linecolsplits the source withsplitlines(), which drops the terminators, and then assumes every break costs exactly one character:A
\r\nbreak costs two, so the running offset falls one character behind for every line before the error, and the error lands on the wrong line and the wrong column.exceptions.pydocuments that aParseError"references the line and location within the line where the error was encountered", andtoml_file.py:36-44only normalises\r\nwhen the whole document uses it consistently — so a file with mixed endings read from disk reaches this path today.The fix lets each split line carry its own terminator (
splitlines(keepends=True)) and uses that length, so the offset matches the characters actually consumed. Documents that use only\ncome out identical; CRLF and mixed documents now report the position the LF form already did.Test:
pytest tests/test_parser.py -k positionfails on main (858186a) — the CRLF case reportsUnexpectedCharError("Unexpected character: '@' at line 4 col 0")where the character is on line 3, column 4 — and passes on this branch. The full suite (pytest --ignore=tests/test_toml_tests.py -q) is 420 passed, andruff check/ruff format --checkat the version pinned in.pre-commit-config.yaml(0.16.10) are clean. I also walked every character index of every file undertests/examplesand compared the reported position before and after: 6913 positions disagreed for CRLF copies of those documents and 0 disagree after the change, while LF-only documents show 0 differences either way.Not run:
tests/test_toml_tests.py, because thetests/toml-testsubmodule is empty in this checkout. I read it — it assertsTOMLKitErroris raised for invalid documents and compares parsed JSON for valid ones, and does not look at line/column — but that is a reading, not a run.Agent Drafting Metadata