Skip to content

v1.10.2

Compare
Choose a tag to compare
@jhump jhump released this 02 Feb 15:47
d02a936

This release contains several fixes to the desc/protoparse and dynamic packages.

"github.com/jhump/protoreflect/desc/protoparse"

Changes/fixes:

  • If a custom option has a type with a oneof in it, then option values in proto sources should not be allowed to set more than one of the fields. Previously, this package would accept such sources, and only the last field (in source location order) would end up being set in the option value. Now the package will report an error.
  • This package would incorrectly accept numeric literals in formats that the Go language accepts but that the Protocol Buffer does not. For example: "0b0100", "0o1735", and "1_000_000" are not legal integer literals in proto source, but are legal Go integer literals and were incorrectly accepted by this package. Similarly, Go accepts "1_000.314" as a float literal and so did this package. But this is not allowed in proto source. These issues have been fixed and this package now accepts numeric literals using the same rules as protoc.
  • This package would report an error if a numeric literal over-flowed what can be represented by a 64-bit floating point value (IEEE754 double precision). However, protoc accepts such sources and, like other floating point literals that cannot be perfectly represented, picks the nearest/best option. In the case of overflow, that value is infinity. This package now behaves like protoc and substitutes an infinite value for numeric literals that would otherwise overflow a 64-bit floating point value.
  • A NUL character in a source file (code point zero, 0x00) could be misinterpreted as end-of-file. This character is not allowed in proto sources, but would not only be accepted in some cases but also result in incomplete compilation. Similarly, this package accepted such characters inside of comments, but that is also not allowed. This has been remedied and source files with such characters will be rejected.
  • This package would incorrectly allow an integer literal like "09", treating it as decimal. However, in proto sources, an integer literal that starts with a zero must be octal (in the given example, "9" is out of range and should have resulted in error). This is fixed.
  • This package would allow reserved ranges and extension ranges to start at zero. However one is lowest acceptable value for such ranges. This has been fixed.
  • This package would incorrectly allow two different oneofs in the same message to have the same name. This has been fixed.
  • This package would allow proto source files that try to directly import the same file more than once. While it is allowed for the transitive dependency graph of a file to include a file more than once, a single proto source file cannot reference the same file multiple times. This is fixed and now reported as an error.
  • Custom option values that used the message literal syntax were required to use a colon separator between a repeated field name and an array literal (e.g. multiple values inside of [ and ]). However, protoc does not require the colon in this context. This package has been updated to match the behavior of protoc.
  • Parsing a source file could lead to a runtime panic under some conditions of symbol collisions. For example, if an operation used a built-in/well-known import (such as google/protobuf/descriptor.proto) without supplying its own copy of source and then included a source file that defined a symbol with the same fully-qualified name as an element in that import, a panic would occur. This has been fixed and the conflict is reported as an error as expected.
  • This package previously populated trailing comments differently from protoc for block elements (i.e. those with elements defined inside of brances { }, including messages, groups, oneofs, extend blocks, enums, services, and methods). This package used the comment immediately following the closing brace (}) as the element's trailing comment. However, protoc uses the comment immediately following the opening brace ({) as the trailing comment. The behavior in this package has been changed to match that of protoc.

"github.com/jhump/protoreflect/desc/protoprint"

Changes/fixes:

  • This package previously assumed that trailing comments for block elements (i.e. those with elements defined inside of brances { }, including messages, groups, oneofs, extend blocks, enums, services, and methods) should be rendered after the closing brace. However, this is not how trailing comments are parsed by protoc: they are the comment immediately following the opening brace instead. So this package has been updated to render the trailing comment for these elements after the opening brace.

"github.com/jhump/protoreflect/dynamic"

Changes/fixes:

  • When unmarshaling JSON into a dynamic message, where one of the fields is of type google.protobuf.Value, this package would incorrectly process values that were JSON arrays. This should be allowed and result in the field's list_value field being set with the contents of the array. Instead, the field would be set to a single value equal to the last value in the JSON array. This has been fixed.
  • When marshaling a dynamic message to JSON, if a field used a custom JSON name that included a character that was non-printable or outside of the 7-bit range (e.g. a control character, code points 0-31, or any code point >= 127), the result JSON output would be invalid. The characters would be encoded in a way such that the resulting key was not a valid JSON string. This has been fixed.