Repository navigation
Fix indented comment parsed as a key, dropping the next key/value pair (#155) - #157
Merged
zonyitoo merged 1 commit intoAug 26, 2026
Conversation
With default features an indented comment line silently drops the following
key/value pair: load_from_str("[s]\na=1\n ; c\nb=2\n") leaves section s with a
bogus property "; c\nb"="2" and get_from("s","b") returns None with no error.
This is a regression - 0.21.1 returned an inline-comment error - introduced by
the leading-whitespace key support (zonyitoo#139/zonyitoo#145/zonyitoo#152).
In Parser::parse the whitespace arm consumes indentation then dispatches on the
next char; with no arm for a comment marker, an indented ;/# fell through to key
parsing, whose parse_str_until scans past the marker and across the newline to
the next line's =, producing a bogus key and swallowing the following pair. Add
an arm handling an indented ;/# as a whole-line comment via parse_comment,
matching configparser.
Fixes zonyitoo#155
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.
Fixes #155.
Problem
With default features, an indented comment line silently drops the following key/value pair:
Section
sends up with a bogus property"; c\nb" = "2", andget_from(Some("s"), "b")returnsNone-- no error is raised.This is a regression: rust-ini 0.21.1 returned
Err("3:4 doesn't support inline comment")for this exact input, so the current behaviour is a silent data loss introduced by the leading-whitespace key support (PRs #139 / #145 / #152).Root cause
In
Parser::parse(), the' ' | '\t'arm consumes the leading indentation and then dispatches on the next character. With no arm for a comment marker, an indented;/#fell through to the generic key-parsing branch, whoseparse_str_until(&[Some('='), Some(':')], ...)scans past the comment marker and across the newline to the=on the next line -- producing a bogus key and swallowing the following pair. The top-level comment arm never sees indented comments.Fix
Handle an indented
;/#as a whole-line comment (via the existingparse_comment), matching Python's configparser and virtually every INI consumer. The reporter accepted eitherb = "2"or a parse error; this picks the configparser-consistent whole-line-comment behavior, which also restores the pre-regression intent without reintroducing the hard error. A tab-indented#behaves identically.Tests
Added
indented_comment_not_parsed_as_key, covering both; cand# cindented comments and assertingastill parses andbis recovered. Verified red/green (reverting the fix makes the new test fail withb == None); full suite is 69 tests + 3 doc-tests, all green.This PR was prepared with AI assistance (Claude Code); the fix, tests, and red/green verification were reviewed by me.