v1.8.2

This release contains numerous improvements to the protoparse package, to more closely match protoc in terms of proto source files that are acceptable.

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

Changes/fixes:

• Extensions in a syntax = "proto3" source file were not allowed to have an optional keyword. However, as of the addition of "proto3 optional" support, this is now allowed by protoc. So protoparse now accepts such declarations, to match protoc functionality.
  • Extensions that have an explicit optional keyword are marked in the descriptor with the proto3_optional option. But, unlike normal fields with the proto3_optional option set, they are not (and, in fact, cannot be) included in implicit single-field oneofs.
• The official compiler, protoc, rejects proto source files for the following reasons. However the protoparse would accept such invalid source files. This has been remedied and protoparse also now rejects such programs:
  • An enum cannot contain a value named option or reserved. This is not an explicit check but is instead a limitation of how the protoc parser works: it assumes these keywords indicate options or reserved ranges, not the start of values with these names.
  • A message cannot begin a field declaration with the keyword reserved, for example in a proto3 file where a type (message or enum) named reserved is also defined. Similar to above, the protoc parser will never recognize such a statement as a field, but protoparse would.
  • A oneof cannot contain a field whose name matches a label keyword (optional, repeated, or required). Unlike the above two, this is not related to limits of the parser but is instead an explicit check to prevent common errors: since oneof blocks do not contain labels, a field thusly named is more likely to be a typo even if otherwise syntactically correct.
  • An enum can only allow aliases (via option allow_alias = true;) if it actually contains values that are aliases. Put another way: if there are no aliases, this option must not be set.
  • A message cannot use message-set wire format (via option message_set_wire_format = true;) if it has any normal fields. Message sets must have only extension fields. Similarly, a message cannot use message-set wire format if it has no extension ranges.
  • An extension for a message that uses message-set wire format must be a message type; scalar extensions are not allowed for messages that use message-set wire format.