Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support new TextFormat group decoding support #1624

Merged
merged 3 commits into from
Apr 16, 2024

Conversation

thomasvl
Copy link
Collaborator

The message_encoding = DELIMITED feature in Editions maps the field to be a "group" however there is/was a grey space in what the the "field name" should be for TextFormat, it was using the message's name from the group but if one does an editions file with DELIMITED encoding on a field we get into an edge case of what exactly should the naming for TextFormat be. Upstream has address this by supporting both the message name or the field name when decoding TextFormat but keeping the existing encoding behavior. The intent appears to be the 2024 Edition will get a new feature to explicitly spec all this and thus avoid the "group like" sport this all keys off of now.

The `message_encoding = DELIMITED` feature in Editions maps the field to be a
"group" however there is/was a grey space in what the the "field name" should be
for TextFormat, it was using the message's name from the group but if one does
an editions file with `DELIMITED` encoding on a field we get into an edge case
of what exactly should the naming for TextFormat be. Upstream has address this
by supporting both the message name or the field name when decoding TextFormat
but keeping the existing encoding behavior. The intent appears to be the 2024
Edition will get a new feature to explicitly spec all this and thus avoid the
"group like" sport this all keys off of now.

The "best" way to handle this would probably be to add a new case to the enum
used for the `_NameTable` that indicates when we need to decode the two forms of
the field name; however, that would be a breaking change (we'd also have to rev
the `ProtobufAPIVersionCheck` to go with it). Instead, we rely on the fact that
the name entries are adding to the internal mappings in the `_NameTable` in
order, so we output an alternate form first, and then the preferred (existing)
name second, so the decoding mapping with have both forms of the protobuf name
but then encoding will have the preferred as the overriding value and continue
to use that.
@thomasvl thomasvl requested a review from allevato April 10, 2024 22:49
@thomasvl thomasvl merged commit 6f3a3c0 into apple:main Apr 16, 2024
10 of 11 checks passed
@thomasvl thomasvl deleted the textformat_group_both_names branch April 16, 2024 12:41
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