Bump github.com/bufbuild/protocompile from 0.1.0 to 0.4.0

[dependabot]

Bumps github.com/bufbuild/protocompile from 0.1.0 to 0.4.0.

Release notes

Sourced from github.com/bufbuild/protocompile's releases.

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.

v0.3.0

This release contains a few fixes but is mostly to align with the recent release of Protocol Buffers v22.0.

Fixes:

1. The reference compiler protoc allows the use of integer literals for enum values inside of a message literal, for custom options whose value is a message type. But this repo did not allow this, so some sources that could be compiled with protoc would result in errors with this repo. This has been fixed.
2. This repo allowed the message_set_wire_format option to be used in files that declare a syntax of proto3. However, this is not allowed; that option is only acceptable in the proto2 syntax. So this repo would accept some sources that were actually valid and would fail if compiled with protoc. This has been fixed.
3. This repo allowed certain kinds of relative references when resolving extension names in message literals, for custom options whose value is a message type, that are not allowed by the reference compiler protoc. So this repo would accept some sources that were actually valid and would fail if compiled with protoc. This has been fixed.
4. Fuzz testing identified a couple of patterns of pathological input that caused degenerate performance in the lexer and parser. These have been fixed.

Changes:

1. When using protocompile.WithStandardImports, the version of google/protobuf/descriptor.proto has been updated to match the version included with Protocol Buffers v22.0. Even if not using protocompile.WithStandardImports, sources may refer to new options added in v22.0 and the compiler will accept them.
2. The above v22.0 release included some changes to behavior when validating custom JSON names. In particular, checking for conflicting JSON names is now case-sensitive. Also, custom JSON names may not be enclosed brackets ([ and ]). These changes are now also reflected in validation done by this repo.
3. If a compile operation provides an override version of google/protobuf/descriptor.proto, it will be used during the options interpretation step. Previously, the was only supported in files that imported override definitions of the options types. If override definitions were not directly imported, options interpretation would always use the version of the options types linked into the compiler program (via the google.golang.org/protobuf/types/descriptorpb package). To provide an override version, implement a protocompile.Resolver that returns a result for google/protobuf/descriptor.proto that is different from the result supplied when using protocompile.WithStandardImports.

Additions:

1. The linker.Result interface has a new method named ResolveOptionsType. This is used to implement the above new strategy for resolving options message types when a compile operation includes an override version of google/protobuf/descriptor.proto. This is technically a backwards-incompatible change. Such an incompatible change was made because (1) this repo is still pre-v1.0, and (2) this interface is not intended to be implemented by code outside of this repo.

v0.2.0

This release contains a couple of bug-fixes and one minor addition.

Fixes:

1. If a protocompile.SourceResolver has an Accessor function that returns an error that wraps an ErrNotExist, it could incorrectly abort searching through import paths. It instead required that the function directly return that error sentinel, without wrapping. Now it correctly handles if the ErrNotExist error is wrapped.
2. When using an error reporter that accumulates many errors (vs. failing after the first one) and parsing source with an invalid string literal that contained incorrect escape sequences, the lexer could get into an incorrect state and report many confusing errors. It effectively behaved as if the incorrect escape sequence was the end of the string literal; it would then report tokenization errors about the rest of the string literal contents, as if they were regular source code not inside a string literal. This has been fixed, and error messages in these situations are now intuitive.

Additions:

1. The protocompile.SearchResult type has a new field ParseResult. This allows the compiler to make more efficient use of the result if the resolver already has an instance of parser.Result. Previously, the resolver would have to decide to return either the file descriptor proto or the AST. Now it can return both.

Commits

• fa737f6 Sleep not necessary: race detector consistently detects race without it (#104)
• 5340254 Update protoc to v22.0 (#100)
• 2c27603 Fix data race in compiler when resolver provides unlinked descriptor proto (#...
• 80a64ae Update deps to address depend-a-bot alerts (#99)
• 7c5114e Allow any file to make use of custom descriptor.proto (#97)
• 6df82ab Message literals allow ints for enums (#98)
• c1a7e84 Bump github.com/golangci/golangci-lint from 1.51.1 to 1.51.2 in /internal/too...
• e7c7eaa Improve doc comments in parser and ast packages (#95)
• df9a36d Bump golang.org/x/tools from 0.5.0 to 0.6.0 in /internal/tools (#93)
• e6dde81 Bump github.com/bufbuild/buf from 1.13.1 to 1.14.0 in /internal/tools (#94)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #21.