protocolbuffers/protobuf-go
### [`v1.27.1`](https://togithub.com/protocolbuffers/protobuf-go/releases/v1.27.1)
[Compare Source](https://togithub.com/protocolbuffers/protobuf-go/compare/v1.27.0...v1.27.1)
Notable changes since [v1.27.0](https://togithub.com/protocolbuffers/protobuf-go/releases/tag/v1.27.0):
- [CL/331149](https://golang.org/cl/331149): cmd/protoc-gen-go: fix generation of enum defaults
### [`v1.27.0`](https://togithub.com/protocolbuffers/protobuf-go/releases/v1.27.0)
[Compare Source](https://togithub.com/protocolbuffers/protobuf-go/compare/v1.26.0...v1.27.0)
- [Overview](#v1.27-overview)
- [Notable changes](#v1.27-notable-changes)
- [Reflectively ranging over a message](#v1.27-reflection-ranging)
- [Upcoming breakage changes](#v1.27-breaking-changes)
#### Overview
The release provides new functionality for iterating through a message using protobuf reflection. There are some minor changes to the code generator.
#### Notable changes
**New features:**
- [CL/309669](https://golang.org/cl/309669): testing/protopack: add Message.UnmarshalAbductive
**Bug fixes:**
- [CL/317430](https://golang.org/cl/317430): encoding/prototext: fix skipping of unknown fields
- [CL/321529](https://golang.org/cl/321529): internal/impl: support typed nil source for Merge of aberrant messages
**Generator changes**
- [CL/305574](https://golang.org/cl/305574): cmd/protoc-gen-go: remove generation of the ExtensionRangeArray method
- [CL/319649](https://golang.org/cl/319649): cmd/protoc-gen-go: avoid referencing remote enum values by name
- [CL/316949](https://golang.org/cl/316949): compiler/protogen: relax rules for valid import paths
- [CL/306209](https://golang.org/cl/306209): cmd/protoc-gen-go: add protoc suffix
##### Reflectively ranging over a message
- [CL/236540](https://golang.org/cl/236540): reflect: add protopath and protorange packages
The new [`reflect/protorange`](https://pkg.go.dev/google.golang.org/protobuf/reflect/protorange) package supports recursively ranging through all populated fields of a message. There are many use cases for such a feature. See [the examples for inspiration](https://pkg.go.dev/google.golang.org/protobuf/reflect/protorange#pkg-examples).
#### Upcoming breakage changes
This release removes generation of the `ExtensionRangeArray` method, as originally announced since the [v1.20.0 release on March 2nd, 2020](https://togithub.com/protocolbuffers/protobuf-go/releases/tag/v1.20.0#v1.20-breaking-changes). Our analysis of the [entire public module proxy](https://proxy.golang.org/) found no static usages of this method. This method is pseudo-internal to the implementation and we expect removal of it to have no material impact. If something is broken by this change, please file an issue and we can consider re-generating this method in a patch release.
There are no *new* upcoming breaking changes to announce in this release.
### [`v1.26.0`](https://togithub.com/protocolbuffers/protobuf-go/releases/v1.26.0)
[Compare Source](https://togithub.com/protocolbuffers/protobuf-go/compare/v1.25.0...v1.26.0)
- [Overview](#v1.26-overview)
- [Notable changes](#v1.26-notable-changes)
- [Reduced dependencies](#v1.26-reduce-dependencies)
- [Require Go import path](#v1.26-require-import-path)
- [Fatal namespace conflicts](#v1.26-fatal-namespace-conflicts)
- [Support for aberrant message types](#v1.26-support-aberrant-types)
- [Upcoming breakage changes](#v1.26-breaking-changes)
#### Overview
This release reduces dependencies on other modules, enforces strict behavior with generated Go packages and name conflicts, expands support for aberrant message types, and provides minor new features in protobuf reflection.
#### Notable changes
**New features:**
- [CL/242377](https://golang.org/cl/242377): proto: add MessageName helper
- [CL/236777](https://golang.org/cl/236777): reflect/protoreflect: add MessageFieldTypes
- [CL/239838](https://golang.org/cl/239838): reflect/protoreflect: add FieldDescriptor.TextName
- [CL/238000](https://golang.org/cl/238000): reflect/protoreflect: improve source information usability
**Behavior changes:**
- [CL/240017](https://golang.org/cl/240017): internal/impl: introduce instability to protoreflect.Message.Range order
- [CL/262681](https://golang.org/cl/262681): internal/encoding/text: escape \x7f (DEL) in strings
- [CL/262682](https://golang.org/cl/262682): internal/encoding/text: escape Unicode control characters in strings
- [CL/259900](https://golang.org/cl/259900): internal/filedesc: remove ProtoLegacyRawDesc method
- [CL/286132](https://golang.org/cl/286132): internal/descfmt: always include type name in FormatList
- [CL/302330](https://golang.org/cl/302330): cmd/protoc-gen-go: support --help flag
- [CL/301952](https://golang.org/cl/301952): cmd/protoc-gen-go: print version to stdout
- [CL/244297](https://golang.org/cl/244297): all: return less-specific, but more informative wire unmarshal errors
**Bug fixes:**
- [CL/247458](https://golang.org/cl/247458): testing/protocmp: fix representation of empty bytes
- [CL/241658](https://golang.org/cl/241658): testing/prototest: fix suggestion for field name
- [CL/259899](https://golang.org/cl/259899): reflect/protodesc: fix round-tripping for package field
- [CL/247737](https://golang.org/cl/247737): encoding/protojson: restrict valid values for google.protobuf.Value.number_value
- [CL/246097](https://golang.org/cl/246097): types/known/fieldmaskpb: repeated and map fields are only valid in the last position of a path
- [CL/244718](https://golang.org/cl/244718): internal/impl: make errInvalidUTF8 be a proto.Error
**Performance optimizations:**
- [CL/253100](https://golang.org/cl/253100): proto/equal: reduce equal scalar value allocation
- [CL/240378](https://golang.org/cl/240378): reflect/protoregistry: avoid checking for '/' in FindMessageByName
##### Reduced dependencies
- [CL/259901](https://golang.org/cl/259901): cmd/protoc-gen-go: remove reference to legacy ProtoPackageIsVersion4
- [CL/262679](https://golang.org/cl/262679): all: rely on dynamic dependency check for genproto
- [CL/262683](https://golang.org/cl/262683): all: remove weak dependency on github.com/golang/protobuf
- [CL/262684](https://golang.org/cl/262684): all: add weak dependency on github.com/golang/protobuf
- [CL/235283](https://golang.org/cl/235283): all: update protobuf toolchain dependency
Go code generated by `protoc-gen-go` no longer have a hard dependency on the [`github.com/golang/protobuf`](https://pkg.go.dev/github.com/golang/protobuf) module. In previous releases, the generator would [emit a reference to the `ProtoPackageIsVersion4` constant](https://golang.org/cl/259901) to statically enforce that a sufficiently new version of the older module was being linked in. In the last year, [most of the Go ecosystem has moved to Go modules](https://blog.golang.org/#TOC\_8.), where we can rely on Go modules to enforce a minimum version constraint on the older protobuf module. While there continues to be a cyclic dependency between the `github.com/golang/protobuf` and `google.golang.org/protobuf` modules, the cyclic dependency was [briefly broken](https://golang.org/cl/262683) and [re-added](https://golang.org/cl/262684) to clear out the infinitely growing list of `go.sum` entries.
The module dependency on the [`google.golang.org/genproto`](https://google.golang.org/genproto) module [has been removed](https://golang.org/cl/262679). Any program that depends on both `google.golang.org/protobuf` and `google.golang.org/genproto` must use at least version [`cb27e3aa` from May 26th, 2020](https://togithub.com/googleapis/go-genproto/commit/cb27e3aa201319f013ddb1872c3111662191a225). There is a [runtime check at program initialization](https://togithub.com/protocolbuffers/protobuf-go/blob/bdf6e19f23595fa5ab7582143efd9ad54d69f901/reflect/protoregistry/registry.go#L175-L214) that panics when too old of a version of the `genproto` module is being linked into the binary.
The well-known types provided by this module are built from [v3.15.3 of the protobuf toolchain](https://togithub.com/protocolbuffers/protobuf/releases/tag/v3.15.3).
##### Require Go import path
- [CL/301953](https://golang.org/cl/301953): compiler/protogen: require that the import path be specified
As mentioned in the [v1.20.0 release from March 2nd, 2020](https://togithub.com/protocolbuffers/protobuf-go/releases#v1.20-required-gopackage), the Go generator will require that the Go import path be specified for all `.proto` files being generated and their transitive dependencies. Since v1.20.0, every occurrence of a `.proto` file missing a Go import path has resulted in a warning being printed to standard error that this will eventually become a fatal error. The Go import path is normally specified by declaring a `go_package` option in the `.proto` file. Alternatively, this can be specified at compile-time with a `M` flag passed on the command line. See the [developer documentation for more information](https://developers.google.com/protocol-buffers/docs/reference/go-generated#package) on the `go_package` option and `M` flag.
##### Fatal namespace conflicts
- [CL/235298](https://golang.org/cl/235298): reflect/protoregistry: panic upon registration conflicts
- [CL/295349](https://golang.org/cl/295349): reflect/protoregistry: add compile-time opt-out for registration conflicts
As mentioned in the [v1.20.0 release from March 2nd, 2020](https://togithub.com/protocolbuffers/protobuf-go/releases#v1.20-namespace-enforcement), the Go protobuf runtime will fatally fail if it detects the registration of duplicate names. Since v1.20.0, every occurrence of a conflict has resulted in a warning being printed to standard error that this will eventually become a fatal error. See the [developer documentation](https://developers.google.com/protocol-buffers/docs/reference/go/faq#namespace-conflict) for more information about what a namespace conflict is and how to resolve it.
While it is preferable that the source of the conflict be fixed, the fatal error can be immediately worked around in one of two ways:
1. **At compile time.** The default behavior for handling conflicts can be specified at compile time with a linker-initialized variable:
go build -ldflags "-X google.golang.org/protobuf/reflect/protoregistry.conflictPolicy=warn"
2. **At program execution.** The behavior for handling conflicts when executing a particular Go binary can be set with an environment variable:
GOLANG_PROTOBUF_REGISTRATION_CONFLICT=warn ./main
This will cause the runtime to use the conflict handling behavior from v1.25.0 and earlier, which is to simply warn about them.
##### Support for aberrant message types
- [CL/300869](https://golang.org/cl/300869): internal/impl: add runtime support for aberrant messages
- [CL/244937](https://golang.org/cl/244937): internal/impl: add runtime support for \*\[]byte unknown representation
This project's [compatibility document](https://togithub.com/protocolbuffers/protobuf-go#compatibility) specifies that we only guarantee runtime compatibility with messages generated by [`protoc-gen-go`](https://pkg.go.dev/google.golang.org/protobuf/cmd/protoc-gen-go). Use of this module's runtime with any other custom message type will have mixed results, ranging from panics, to unspecified behavior, to working correctly. The proper way for custom message types to perfectly work with this module is for the custom type to implement the [`protoreflect.ProtoMessage`](https://pkg.go.dev/google.golang.org/protobuf/reflect/protoreflect#ProtoMessage) interface, which allows a given message implementation to self-describe how its contents should be introspected.
Since some widely depended upon modules have custom message types not generated by `protoc-gen-go`, we [expand support in this module's runtime](https://golang.org/cl/300869) to be able to handle those aberrant message types. This change should reduce the probability that using one of those modules with this module results in a panic and instead have reasonably correct behavior.
This support is **not covered by this project's [compatibility guarantee](https://togithub.com/protocolbuffers/protobuf-go#compatibility)** and may be modified or removed in a future version of this module without notice. Custom types must move to supporting protobuf reflection to ensure long-term compatibility.
#### Upcoming breakage changes
This release makes some potentially disruptive changes that have been announced since the [v1.20.0 release on March 2nd, 2020](https://togithub.com/protocolbuffers/protobuf-go/releases/tag/v1.20.0#v1.20-breaking-changes). Not all breaking changes mentioned in the v1.20.0 have been made and may still take effect in a later version of this module.
There are no *new* upcoming breaking changes to announce in this release.
Configuration
📅 Schedule: At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
[ ] If you want to rebase/retry this PR, click this checkbox.
This PR contains the following updates:
v1.25.0->v1.27.1Release Notes
protocolbuffers/protobuf-go
### [`v1.27.1`](https://togithub.com/protocolbuffers/protobuf-go/releases/v1.27.1) [Compare Source](https://togithub.com/protocolbuffers/protobuf-go/compare/v1.27.0...v1.27.1) Notable changes since [v1.27.0](https://togithub.com/protocolbuffers/protobuf-go/releases/tag/v1.27.0): - [CL/331149](https://golang.org/cl/331149): cmd/protoc-gen-go: fix generation of enum defaults ### [`v1.27.0`](https://togithub.com/protocolbuffers/protobuf-go/releases/v1.27.0) [Compare Source](https://togithub.com/protocolbuffers/protobuf-go/compare/v1.26.0...v1.27.0) - [Overview](#v1.27-overview) - [Notable changes](#v1.27-notable-changes) - [Reflectively ranging over a message](#v1.27-reflection-ranging) - [Upcoming breakage changes](#v1.27-breaking-changes) #### Overview The release provides new functionality for iterating through a message using protobuf reflection. There are some minor changes to the code generator. #### Notable changes **New features:** - [CL/309669](https://golang.org/cl/309669): testing/protopack: add Message.UnmarshalAbductive **Bug fixes:** - [CL/317430](https://golang.org/cl/317430): encoding/prototext: fix skipping of unknown fields - [CL/321529](https://golang.org/cl/321529): internal/impl: support typed nil source for Merge of aberrant messages **Generator changes** - [CL/305574](https://golang.org/cl/305574): cmd/protoc-gen-go: remove generation of the ExtensionRangeArray method - [CL/319649](https://golang.org/cl/319649): cmd/protoc-gen-go: avoid referencing remote enum values by name - [CL/316949](https://golang.org/cl/316949): compiler/protogen: relax rules for valid import paths - [CL/306209](https://golang.org/cl/306209): cmd/protoc-gen-go: add protoc suffix ##### Reflectively ranging over a message - [CL/236540](https://golang.org/cl/236540): reflect: add protopath and protorange packages The new [`reflect/protorange`](https://pkg.go.dev/google.golang.org/protobuf/reflect/protorange) package supports recursively ranging through all populated fields of a message. There are many use cases for such a feature. See [the examples for inspiration](https://pkg.go.dev/google.golang.org/protobuf/reflect/protorange#pkg-examples). #### Upcoming breakage changes This release removes generation of the `ExtensionRangeArray` method, as originally announced since the [v1.20.0 release on March 2nd, 2020](https://togithub.com/protocolbuffers/protobuf-go/releases/tag/v1.20.0#v1.20-breaking-changes). Our analysis of the [entire public module proxy](https://proxy.golang.org/) found no static usages of this method. This method is pseudo-internal to the implementation and we expect removal of it to have no material impact. If something is broken by this change, please file an issue and we can consider re-generating this method in a patch release. There are no *new* upcoming breaking changes to announce in this release. ### [`v1.26.0`](https://togithub.com/protocolbuffers/protobuf-go/releases/v1.26.0) [Compare Source](https://togithub.com/protocolbuffers/protobuf-go/compare/v1.25.0...v1.26.0) - [Overview](#v1.26-overview) - [Notable changes](#v1.26-notable-changes) - [Reduced dependencies](#v1.26-reduce-dependencies) - [Require Go import path](#v1.26-require-import-path) - [Fatal namespace conflicts](#v1.26-fatal-namespace-conflicts) - [Support for aberrant message types](#v1.26-support-aberrant-types) - [Upcoming breakage changes](#v1.26-breaking-changes) #### Overview This release reduces dependencies on other modules, enforces strict behavior with generated Go packages and name conflicts, expands support for aberrant message types, and provides minor new features in protobuf reflection. #### Notable changes **New features:** - [CL/242377](https://golang.org/cl/242377): proto: add MessageName helper - [CL/236777](https://golang.org/cl/236777): reflect/protoreflect: add MessageFieldTypes - [CL/239838](https://golang.org/cl/239838): reflect/protoreflect: add FieldDescriptor.TextName - [CL/238000](https://golang.org/cl/238000): reflect/protoreflect: improve source information usability **Behavior changes:** - [CL/240017](https://golang.org/cl/240017): internal/impl: introduce instability to protoreflect.Message.Range order - [CL/262681](https://golang.org/cl/262681): internal/encoding/text: escape \x7f (DEL) in strings - [CL/262682](https://golang.org/cl/262682): internal/encoding/text: escape Unicode control characters in strings - [CL/259900](https://golang.org/cl/259900): internal/filedesc: remove ProtoLegacyRawDesc method - [CL/286132](https://golang.org/cl/286132): internal/descfmt: always include type name in FormatList - [CL/302330](https://golang.org/cl/302330): cmd/protoc-gen-go: support --help flag - [CL/301952](https://golang.org/cl/301952): cmd/protoc-gen-go: print version to stdout - [CL/244297](https://golang.org/cl/244297): all: return less-specific, but more informative wire unmarshal errors **Bug fixes:** - [CL/247458](https://golang.org/cl/247458): testing/protocmp: fix representation of empty bytes - [CL/241658](https://golang.org/cl/241658): testing/prototest: fix suggestion for field name - [CL/259899](https://golang.org/cl/259899): reflect/protodesc: fix round-tripping for package field - [CL/247737](https://golang.org/cl/247737): encoding/protojson: restrict valid values for google.protobuf.Value.number_value - [CL/246097](https://golang.org/cl/246097): types/known/fieldmaskpb: repeated and map fields are only valid in the last position of a path - [CL/244718](https://golang.org/cl/244718): internal/impl: make errInvalidUTF8 be a proto.Error **Performance optimizations:** - [CL/253100](https://golang.org/cl/253100): proto/equal: reduce equal scalar value allocation - [CL/240378](https://golang.org/cl/240378): reflect/protoregistry: avoid checking for '/' in FindMessageByName ##### Reduced dependencies - [CL/259901](https://golang.org/cl/259901): cmd/protoc-gen-go: remove reference to legacy ProtoPackageIsVersion4 - [CL/262679](https://golang.org/cl/262679): all: rely on dynamic dependency check for genproto - [CL/262683](https://golang.org/cl/262683): all: remove weak dependency on github.com/golang/protobuf - [CL/262684](https://golang.org/cl/262684): all: add weak dependency on github.com/golang/protobuf - [CL/235283](https://golang.org/cl/235283): all: update protobuf toolchain dependency Go code generated by `protoc-gen-go` no longer have a hard dependency on the [`github.com/golang/protobuf`](https://pkg.go.dev/github.com/golang/protobuf) module. In previous releases, the generator would [emit a reference to the `ProtoPackageIsVersion4` constant](https://golang.org/cl/259901) to statically enforce that a sufficiently new version of the older module was being linked in. In the last year, [most of the Go ecosystem has moved to Go modules](https://blog.golang.org/#TOC\_8.), where we can rely on Go modules to enforce a minimum version constraint on the older protobuf module. While there continues to be a cyclic dependency between the `github.com/golang/protobuf` and `google.golang.org/protobuf` modules, the cyclic dependency was [briefly broken](https://golang.org/cl/262683) and [re-added](https://golang.org/cl/262684) to clear out the infinitely growing list of `go.sum` entries. The module dependency on the [`google.golang.org/genproto`](https://google.golang.org/genproto) module [has been removed](https://golang.org/cl/262679). Any program that depends on both `google.golang.org/protobuf` and `google.golang.org/genproto` must use at least version [`cb27e3aa` from May 26th, 2020](https://togithub.com/googleapis/go-genproto/commit/cb27e3aa201319f013ddb1872c3111662191a225). There is a [runtime check at program initialization](https://togithub.com/protocolbuffers/protobuf-go/blob/bdf6e19f23595fa5ab7582143efd9ad54d69f901/reflect/protoregistry/registry.go#L175-L214) that panics when too old of a version of the `genproto` module is being linked into the binary. The well-known types provided by this module are built from [v3.15.3 of the protobuf toolchain](https://togithub.com/protocolbuffers/protobuf/releases/tag/v3.15.3). ##### Require Go import path - [CL/301953](https://golang.org/cl/301953): compiler/protogen: require that the import path be specified As mentioned in the [v1.20.0 release from March 2nd, 2020](https://togithub.com/protocolbuffers/protobuf-go/releases#v1.20-required-gopackage), the Go generator will require that the Go import path be specified for all `.proto` files being generated and their transitive dependencies. Since v1.20.0, every occurrence of a `.proto` file missing a Go import path has resulted in a warning being printed to standard error that this will eventually become a fatal error. The Go import path is normally specified by declaring a `go_package` option in the `.proto` file. Alternatively, this can be specified at compile-time with a `M` flag passed on the command line. See the [developer documentation for more information](https://developers.google.com/protocol-buffers/docs/reference/go-generated#package) on the `go_package` option and `M` flag. ##### Fatal namespace conflicts - [CL/235298](https://golang.org/cl/235298): reflect/protoregistry: panic upon registration conflicts - [CL/295349](https://golang.org/cl/295349): reflect/protoregistry: add compile-time opt-out for registration conflicts As mentioned in the [v1.20.0 release from March 2nd, 2020](https://togithub.com/protocolbuffers/protobuf-go/releases#v1.20-namespace-enforcement), the Go protobuf runtime will fatally fail if it detects the registration of duplicate names. Since v1.20.0, every occurrence of a conflict has resulted in a warning being printed to standard error that this will eventually become a fatal error. See the [developer documentation](https://developers.google.com/protocol-buffers/docs/reference/go/faq#namespace-conflict) for more information about what a namespace conflict is and how to resolve it. While it is preferable that the source of the conflict be fixed, the fatal error can be immediately worked around in one of two ways: 1. **At compile time.** The default behavior for handling conflicts can be specified at compile time with a linker-initialized variable: go build -ldflags "-X google.golang.org/protobuf/reflect/protoregistry.conflictPolicy=warn" 2. **At program execution.** The behavior for handling conflicts when executing a particular Go binary can be set with an environment variable: GOLANG_PROTOBUF_REGISTRATION_CONFLICT=warn ./main This will cause the runtime to use the conflict handling behavior from v1.25.0 and earlier, which is to simply warn about them. ##### Support for aberrant message types - [CL/300869](https://golang.org/cl/300869): internal/impl: add runtime support for aberrant messages - [CL/244937](https://golang.org/cl/244937): internal/impl: add runtime support for \*\[]byte unknown representation This project's [compatibility document](https://togithub.com/protocolbuffers/protobuf-go#compatibility) specifies that we only guarantee runtime compatibility with messages generated by [`protoc-gen-go`](https://pkg.go.dev/google.golang.org/protobuf/cmd/protoc-gen-go). Use of this module's runtime with any other custom message type will have mixed results, ranging from panics, to unspecified behavior, to working correctly. The proper way for custom message types to perfectly work with this module is for the custom type to implement the [`protoreflect.ProtoMessage`](https://pkg.go.dev/google.golang.org/protobuf/reflect/protoreflect#ProtoMessage) interface, which allows a given message implementation to self-describe how its contents should be introspected. Since some widely depended upon modules have custom message types not generated by `protoc-gen-go`, we [expand support in this module's runtime](https://golang.org/cl/300869) to be able to handle those aberrant message types. This change should reduce the probability that using one of those modules with this module results in a panic and instead have reasonably correct behavior. This support is **not covered by this project's [compatibility guarantee](https://togithub.com/protocolbuffers/protobuf-go#compatibility)** and may be modified or removed in a future version of this module without notice. Custom types must move to supporting protobuf reflection to ensure long-term compatibility. #### Upcoming breakage changes This release makes some potentially disruptive changes that have been announced since the [v1.20.0 release on March 2nd, 2020](https://togithub.com/protocolbuffers/protobuf-go/releases/tag/v1.20.0#v1.20-breaking-changes). Not all breaking changes mentioned in the v1.20.0 have been made and may still take effect in a later version of this module. There are no *new* upcoming breaking changes to announce in this release.Configuration
📅 Schedule: At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.