Skip to content

fix nested syntax in custom options - #3673

Merged
oldergod merged 2 commits into
square:masterfrom
tmanninger:master
Aug 14, 2026
Merged

fix nested syntax in custom options#3673
oldergod merged 2 commits into
square:masterfrom
tmanninger:master

Conversation

@tmanninger

Copy link
Copy Markdown
Contributor

This Pull requests fix the following issue: #3672

An option name component followed by a parenthesized extension failed to parse,
as in protovalidate's:

    [(buf.validate.field).string.(buf.validate.predefined) = true]

readWord() absorbed the dots in a name, so the component before
"(buf.validate.predefined)" was read as "string." and the parser then failed
with "expected '=' in option".

The dots in an option name are separators between its components, so consume
them in OptionReader.readOption(), which already loops over them, rather than
letting the word absorb them. Because the reader skips whitespace and comments
between any two tokens, this also accepts the equivalent spellings that protoc
accepts and that a lookahead on the character after the dot would not:

    [(foo.field).string . (foo.datetime) = true]
    [(foo.field).string./* comment */(foo.datetime) = true]

A component is now also kept whole when it is bracketed, instead of being split
on the dots inside its brackets, which produced the unresolvable names "[foo"
and "datetime]".

See square#3672
@oldergod

Copy link
Copy Markdown
Member

Thank you @tmanninger I've added a commit as well. Can you sign our CLA so that I can merge this PR?

@tmanninger

Copy link
Copy Markdown
Contributor Author

Thank you @tmanninger I've added a commit as well. Can you sign our CLA so that I can merge this PR?

done.

@oldergod
oldergod merged commit a145ef6 into square:master Aug 14, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants