v1.9.0

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

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

Changes/fixes:

• When adding a message to another (to make a nested/enclosed type), the target enclosing message could be incorrectly detached from its parent element. This was the result of a typo in the implementation code and has been fixed.

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

Additions:

• The protoparse package now issues warnings when it detects that a source file has unused imports. This mirrors the warnings that protoc issues in the same cases. This feature requires the use of a WarningReporter with a parse operation. The concrete type of value provided to the warning reporter will be a protoparse.ErrorUnusedImport.

Changes/fixes:

• The protoc compiler was more strict than protoparse when it comes to resolving relative (vs. full qualified) names. This led to conditions where protoparse would accept a proto source file that protoc would reject. The issue is when the first component of an identifier could match multiple lexical scopes. In such a case protoc only matches the most enclosing scope. But protoparse would fallback to other enclosing scopes if the most enclosing scope could not be used to resolve a symbol. (Hard to describe succinctly, so see the example in this bug report.) This issue is now fixed and protoparse resolves names in the same manner as protoc.
• The protoc compiler uses "C++ enum scoping rules" for protobuf enums. This means that enum values are declared in the namespace of the enclosing enum (as siblings of the enum itself). But protoparse incorrectly treated the enum as the parent scope/namespace. This led to source files that protoparse would accept but that protoc would reject. This issue is now fixed.
• The use of custom options in oneof statements could incorrectly result in error messages about failing to resolve the custom option name, even if the source file and the option reference were valid. This has been fixed.

"github.com/jhump/protoreflect/dynamic/msgregistry"

Additions:

• A new error type, ErrUnexpectedType, was introduced. When a call to FindMessageTypeByUrl or FindEnumTypeByUrl fails because of a type mismatch (expecting a message, got an enum, or vice versa), this can now be determined programmatically by type-asserting the error to the new error type. This provides a proper/robust way to detect this kind of error (previously, callers would have to examine the error text, which is quite brittle).