v1.10.3
This release contains several fixes to the desc/protoparse
package and one fix to the grpcreflect
package.
"github.com/jhump/protoreflect/desc/protoparse"
Changes/fixes:
- If a custom option value contains a message literal,
protoc
accepts identifierst
,f
,True
, andFalse
as synonyms fortrue
andfalse
. Use of these alternate spellings would be rejected by this package. This is now fixed so that this package accepts the same values asprotoc
. - If a custom option refers to an enum which has values named
true
orfalse
, this package would reject the option, misunderstanding thetrue
orfalse
identifier to be a boolean literal instead of an enum value name. This has been fixed. - There were several cases where references to a custom option or extension, in an option name or in a message literal, were resolved differently by this package than by
protoc
. This lead to some variances -- some source files thatprotoc
would accept but that this package would not (because it was unable to resolve a reference), and some source files that this package would accept but thatprotoc
would reject (because this package was using different lexical scoping rules during resolution). This has been fixed and this package now resolves extension names the same way asprotoc
. - When specifying a custom option value for a message whose type is
google.protobuf.Any
,protoc
supports a special syntax that makes it possible to use a simple text format for the contained message, instead of having to include a byte string representation of a marshaled/encoded value. This package did not previously implement that syntax, so would reject proto sources that used it. This has been remedied, and the special syntax is now supported by this package. - This package would previously accept a
repeated
extension for a message that used message-set wire format. However, onlyoptional
extensions are allowed for such messages. This has been fixed, and proto sources that try to define such arepeated
extension will be rejected. - Extensions are not allowed to set a
json_name
option, however this package was accepting proto sources that did so. This has been fixed, and proto sources that define an extension with thejson_name
option will be rejected.
"github.com/jhump/protoreflect/grpcreflect"
Changes/fixes:
- In some cases, servers implementing the reflection service has been observed to incorrectly include extra file descriptors in response to a
file_containing_symbol
request. Also, the reflection service does not actually specify any ordering requirements for responses that choose to include more than one file. But this package mistakenly assumed an ordering (based on an older implementation of the reflection service in the official Java runtime), which could cause such cases (responses with multiple or even superfluous files) to return the incorrect file descriptor. This has been fixed. Now all responses tofile_containing_symbol
,file_containing_extension
andfile_by_filename
requests correctly support multiple files (even superfluous ones) in any order.