v0.4.0

Fixes:

1. If a protocompile.Resolver returns search results with parser results or descriptor protos that are shared across more than one compile operation, a data race could occur. This happens when a descriptor proto needs to be modified during compilation (like to replace unqualified references with fully-qualified references during linking, to interpret options, or to add source code info). In that case the modification could be made to the same descriptor, concurrently from the different compile operations. If the race detector is enabled, this will result in a crash.
2. If a program directly calls parser.ResultFromAST, passing false for whether to validate the result, it could get back a different file descriptor proto than if true were passed, even if the result is in fact valid. In particular, when validation was skipped, field descriptors may be missing values for the label field. This is now fixed such that there is no difference in the result (other than the possibility of an error when validating, due to extra validation checks).
3. If a protocompiler.Resolver returns a search result with an invalid type reference, such that a field's type_name field resolved to a message but the type field was incorrectly set to TYPE_ENUM, an invalid compile result would be produced. And if the converse occurred (type_name resolved to an enum, but type indicated TYPE_MESSAGE), it would be silently ignored but produce a valid result (by correcting the errant type field value). Now, if either of these kinds of mismatches are detected, an error will occur.
4. The binary format of a CanonicalProto from a linker.Result did not match the serialization format that protoc uses in some obscure cases. If the compile operation contained an override version of "google/protobuf/descriptor.proto" that re-declared a known field (e.g. same tag number as a field statically known to the program) with an incompatible type, protoc includes it with other unrecognized fields after recognized fields are serialized. But this repo was including it with recognized fields. This has been fixed.

Changes:

1. When computing source code info, comments that would previously have been dropped due to ambiguity may not be attributed. When a sequence of comments is ambiguous (i.e. unclear whether they should be attributed as trailing comment to prior token, leading comment to subsequent token, or detached), instead of being dropped they will now be attributed as follows:

   • If there is one comment, it will be detached.
   • If there are two or more comments, the first will be a trailing comment on prior token, the last will be a leading comment on subsequent token, and any other comments in between will be detached.

   This mirrors the behavior of protoc as of v22.0, in which an equivalent change was made to comment attribution logic.

Additions:

1. A new function, Clone(parser.Result) parser.Result, has been added to the parser sub-package. This makes a deep copy of a parser.Result, which can be used to make defensive copies (such as to prevent data races). This clones the result's file descriptor proto and also re-creates an internal index that maps elements of the file descriptor proto to nodes in the AST.