Skip to content
This repository was archived by the owner on Aug 1, 2024. It is now read-only.

build(deps): bump github.com/jhump/protoreflect from 1.8.2 to 1.11.0 - #89

Closed
dependabot[bot] wants to merge 1 commit into
masterfrom
dependabot/go_modules/github.com/jhump/protoreflect-1.11.0
Closed

build(deps): bump github.com/jhump/protoreflect from 1.8.2 to 1.11.0#89
dependabot[bot] wants to merge 1 commit into
masterfrom
dependabot/go_modules/github.com/jhump/protoreflect-1.11.0

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Feb 14, 2022

Copy link
Copy Markdown
Contributor

Bumps github.com/jhump/protoreflect from 1.8.2 to 1.11.0.

Release notes

Sourced from github.com/jhump/protoreflect's releases.

v1.11.0

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

Changes/fixes:

  • If an option on a method included comments and was the kind of option that protoprint is able to handle, they would fail to be included in the printed output. Options were supported on all other types, just not on methods. This has been remedied: methods now have the same support for options comments as other elements.
  • The Printer type includes three new fields, to control formatting of complex options: ShortOptionsExpansionThresholdCount and ShortOptionsExpansionThresholdLength control when "short options" will be expanded to multiple lines, based on the number of options and the length of the options when rendered; MessageLiteralExpansionThresholdLength controls when message literals in option values will be expanded to multi-line form, based on if the length of the rendered string is too long.

"github.com/jhump/protoreflect/grpcreflect"

Changes/fixes:

  • The LoadServiceDescriptors function now accepts an interface, not just the concrete type *grpc.Server. Since *grpc.Server implements the interface, this change should be mostly backwards compatible. However, if there are usages that rely on the precise signature, such as assigning to a function variable whose signature requires *grpc.Server, this is a minor breaking change. Such usage is not expected.

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 identifiers t, f, True, and False as synonyms for true and false. Use of these alternate spellings would be rejected by this package. This is now fixed so that this package accepts the same values as protoc.
  • If a custom option refers to an enum which has values named true or false, this package would reject the option, misunderstanding the true or false 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 that protoc 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 that protoc 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 as protoc.
  • 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, only optional extensions are allowed for such messages. This has been fixed, and proto sources that try to define such a repeated 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 the json_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 to file_containing_symbol, file_containing_extension and file_by_filename requests correctly support multiple files (even superfluous ones) in any order.

v1.10.2

This release contains several fixes to the desc/protoparse and dynamic packages.

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

Changes/fixes:

  • If a custom option has a type with a oneof in it, then option values in proto sources should not be allowed to set more than one of the fields. Previously, this package would accept such sources, and only the last field (in source location order) would end up being set in the option value. Now the package will report an error.
  • This package would incorrectly accept numeric literals in formats that the Go language accepts but that the Protocol Buffer does not. For example: "0b0100", "0o1735", and "1_000_000" are not legal integer literals in proto source, but are legal Go integer literals and were incorrectly accepted by this package. Similarly, Go accepts "1_000.314" as a float literal and so did this package. But this is not allowed in proto source. These issues have been fixed and this package now accepts numeric literals using the same rules as protoc.
  • This package would report an error if a numeric literal over-flowed what can be represented by a 64-bit floating point value (IEEE754 double precision). However, protoc accepts such sources and, like other floating point literals that cannot be perfectly represented, picks the nearest/best option. In the case of overflow, that value is infinity. This package now behaves like protoc and substitutes an infinite value for numeric literals that would otherwise overflow a 64-bit floating point value.
  • A NUL character in a source file (code point zero, 0x00) could be misinterpreted as end-of-file. This character is not allowed in proto sources, but would not only be accepted in some cases but also result in incomplete compilation. Similarly, this package accepted such characters inside of comments, but that is also not allowed. This has been remedied and source files with such characters will be rejected.
  • This package would incorrectly allow an integer literal like "09", treating it as decimal. However, in proto sources, an integer literal that starts with a zero must be octal (in the given example, "9" is out of range and should have resulted in error). This is fixed.
  • This package would allow reserved ranges and extension ranges to start at zero. However one is lowest acceptable value for such ranges. This has been fixed.
  • This package would incorrectly allow two different oneofs in the same message to have the same name. This has been fixed.
  • This package would allow proto source files that try to directly import the same file more than once. While it is allowed for the transitive dependency graph of a file to include a file more than once, a single proto source file cannot reference the same file multiple times. This is fixed and now reported as an error.
  • Custom option values that used the message literal syntax were required to use a colon separator between a repeated field name and an array literal (e.g. multiple values inside of [ and ]). However, protoc does not require the colon in this context. This package has been updated to match the behavior of protoc.

... (truncated)

Commits
  • e5b6528 protoprint: new fields to control expanding short options and message literal...
  • 0e352eb protoprint: fix bug where comments on method options were not included in out...
  • 6224817 grpcdynamic, grpcreflect: use grpc.ClientConnInterface and reflection.GRPCSer...
  • c329f1e some cleanup in Makefile, CI config, and dependencies (#490)
  • 65315df protoparse: message-set extensions must be optional (#489)
  • 4ced19e protoparse: extensions are not allowed to use json_name option (#488)
  • 38023d3 grpcreflect: handle case where server sends back multiple files (#487)
  • 1bb2aa9 protoparse: add support for special syntax for Any messages in message litera...
  • 260eab9 protoparse: fix extension resolution in custom options to match protoc (#484)
  • d4949d2 improvements to protoparse's handling of message literals in custom options (...
  • Additional commits viewable in compare view

Dependabot compatibility score

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)

Bumps [github.com/jhump/protoreflect](https://github.com/jhump/protoreflect) from 1.8.2 to 1.11.0.
- [Release notes](https://github.com/jhump/protoreflect/releases)
- [Commits](jhump/protoreflect@v1.8.2...v1.11.0)

---
updated-dependencies:
- dependency-name: github.com/jhump/protoreflect
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added the dependencies Pull requests that update a dependency file label Feb 14, 2022
@dependabot @github

dependabot Bot commented on behalf of github Feb 14, 2022

Copy link
Copy Markdown
Contributor Author

Dependabot tried to add @alexanderbez and @fedekunze as reviewers to this PR, but received the following error from GitHub:

POST https://api.github.com/repos/haderech/cosmos-sdk/pulls/89/requested_reviewers: 422 - Reviews may only be requested from collaborators. One or more of the users or teams you specified is not a collaborator of the haderech/cosmos-sdk repository. // See: https://docs.github.com/rest/reference/pulls#request-reviewers-for-a-pull-request

@dependabot @github

dependabot Bot commented on behalf of github Feb 14, 2022

Copy link
Copy Markdown
Contributor Author

The following labels could not be found: automerge.

@dependabot @github

dependabot Bot commented on behalf of github Feb 21, 2022

Copy link
Copy Markdown
Contributor Author

Superseded by #90.

@dependabot dependabot Bot closed this Feb 21, 2022
@dependabot
dependabot Bot deleted the dependabot/go_modules/github.com/jhump/protoreflect-1.11.0 branch February 21, 2022 09:18
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

dependencies Pull requests that update a dependency file

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants