mirror/protobuf-go
1
0
Fork 0
mirror of https://github.com/protocolbuffers/protobuf-go.git synced 2025-02-04 12:39:49 +00:00
Code Issues Packages Projects Releases Wiki Activity
protobuf-go/cmd/protoc-gen-go/testdata/extensions/ext/ext.pb.go

1249 lines
68 KiB
Go
Raw Normal View History

cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
// Code generated by protoc-gen-go. DO NOT EDIT.
// source: extensions/ext/ext.proto
package ext
import (
go.mod: rename google.golang.org/proto as github.com/golang/protobuf/v2 This change was created by running: git ls-files | xargs sed -i "s|google.golang.org/proto|github.com/golang/protobuf/v2|g" This change is *not* an endorsement of "github.com/golang/protobuf/v2" as the final import path when the v2 API is eventually released as stable. We continue to reserve the right to make breaking changes as we see fit. This change enables us to host the v2 API on a repository that is go-gettable (since go.googlesource.com is not a known host by the "go get" tool; and google.golang.org/proto was just a stub URL that is not currently served). Thus, we can start work on a forked version of the v1 API that explores what it would take to implement v1 in terms of v2 in a backwards compatible way. Change-Id: Ia3ebc41ac4238af62ee140200d3158b53ac9ec48 Reviewed-on: https://go-review.googlesource.com/136736 Reviewed-by: Damien Neil <dneil@google.com>
2018-09-21 17:44:00 -07:00
base "github.com/golang/protobuf/v2/cmd/protoc-gen-go/testdata/extensions/base"
extra "github.com/golang/protobuf/v2/cmd/protoc-gen-go/testdata/extensions/extra"
cmd/protoc-gen-go: add support for protobuf reflection Implement support in protoc-gen-go for generating messages and enums that satisfy the v2 protobuf reflection interfaces. Specifically, the following are added: * top-level variable representing the file descriptor * ProtoReflect method on enums (to implement protoV2.Enum) * ProtoReflect method on messages (to implement protoV2.Message) The following are not supported yet: * resolving transitive dependencies for file imports * Extension descriptors * Service descriptors The implementation approach creates a single array for all the message and enum declarations and references sections of that array to complete dependencies. Since protobuf declarations can form a graph (a message may depend on itself), it is difficult to construct a graph as a single literal. One way is to use placeholder descriptors, but that is not efficient as it requires encoding the full name of each dependent enum and message and then later resolving it; thus, both expanding the binary size and also increasing initialization cost. Instead, we add a prototype.{Enum,Message}.Reference method to obtain a descriptor reference for the purposes for satisfying dependencies. As such, nested declarations and dependencies are populated in an init function. Other changes to support the implementation: * Added a protoimpl package to expose the MessageType type and also the MessageTypeOf and EnumTypeOf helper functions. * Added a protogen.File.GoIdent field to provide a suggested variable name for the file descriptor. * Added prototype.{Enum,Message}.Reference that provides a descriptor reference for the purposes for satisfying cyclic dependencies. * Added protoreflect.{Syntax,Cardinality,Kind}.GoString to obtain a Go source identifier that represents the given constant. Change-Id: I9455764882dee6ad10f251901e7d419091e8bf1d Reviewed-on: https://go-review.googlesource.com/c/150074 Reviewed-by: Damien Neil <dneil@google.com>
2018-11-15 14:44:37 -08:00
protoreflect "github.com/golang/protobuf/v2/reflect/protoreflect"
cmd/protoc-gen-go: generate for v2-only dependencies This removes yet another set of dependencies of v2 on v1. The only remaining dependency are in the _test.go files, primarily for proto.Equal. Changes made: * cmd/protoc-gen-go no longer generates any functionality that depends on the v1 package, and instead only depends on v2. * internal/fileinit.FileBuilder.MessageOutputTypes is switched from protoreflect.MessageType to protoimpl.MessageType since the implementation must be fully inialized before registration occurs. * The test for internal/legacy/file_test.go is switched to a legacy_test package to avoid a cyclic dependency. This requires Load{Enum,Message,File}Desc to be exported. Change-Id: I43e2fe64cff4eea204258ce11e791aca5eb6e569 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169298 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-25 14:41:32 -07:00
protoregistry "github.com/golang/protobuf/v2/reflect/protoregistry"
all: move v1 types over to the v2 repository As a goal, v2 should not depend on v1. As another step towards that end, we move all the types that used to be in the v1 protoapi package over to v2. For now, we place MessageV1, ExtensionRangeV1, and ExtensionDescV1 in runtime/protoiface since these are types that generated messages will probably have to reference forever. An alternative location could be reflect/protoreflect, but it seems unfortunate to have to dirty the namespace of that package with these types. We move ExtensionFieldV1, ExtensionFieldsV1, and ExtensionFieldsOf to internal/impl, since these are related to the implementation of a generated message. Since moving these types from v1 to v2 implies that the v1 protoapi package is useless, we update all usages of v1 protoapi in the v2 repository to point to the relevant v2 type or functionality. CL/168538 is the corresponding change to alter v1. There will be a temporary build failure as it is not possible to submit CL/168519 and CL/168538 atomically. Change-Id: Ide4025c1b6af5b7f0696f4b65b988b4d10a50f0b Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/168519 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-20 18:29:32 -07:00
protoiface "github.com/golang/protobuf/v2/runtime/protoiface"
cmd/protoc-gen-go: add support for protobuf reflection Implement support in protoc-gen-go for generating messages and enums that satisfy the v2 protobuf reflection interfaces. Specifically, the following are added: * top-level variable representing the file descriptor * ProtoReflect method on enums (to implement protoV2.Enum) * ProtoReflect method on messages (to implement protoV2.Message) The following are not supported yet: * resolving transitive dependencies for file imports * Extension descriptors * Service descriptors The implementation approach creates a single array for all the message and enum declarations and references sections of that array to complete dependencies. Since protobuf declarations can form a graph (a message may depend on itself), it is difficult to construct a graph as a single literal. One way is to use placeholder descriptors, but that is not efficient as it requires encoding the full name of each dependent enum and message and then later resolving it; thus, both expanding the binary size and also increasing initialization cost. Instead, we add a prototype.{Enum,Message}.Reference method to obtain a descriptor reference for the purposes for satisfying dependencies. As such, nested declarations and dependencies are populated in an init function. Other changes to support the implementation: * Added a protoimpl package to expose the MessageType type and also the MessageTypeOf and EnumTypeOf helper functions. * Added a protogen.File.GoIdent field to provide a suggested variable name for the file descriptor. * Added prototype.{Enum,Message}.Reference that provides a descriptor reference for the purposes for satisfying cyclic dependencies. * Added protoreflect.{Syntax,Cardinality,Kind}.GoString to obtain a Go source identifier that represents the given constant. Change-Id: I9455764882dee6ad10f251901e7d419091e8bf1d Reviewed-on: https://go-review.googlesource.com/c/150074 Reviewed-by: Damien Neil <dneil@google.com>
2018-11-15 14:44:37 -08:00
protoimpl "github.com/golang/protobuf/v2/runtime/protoimpl"
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
sync "sync"
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
)
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
const _ = protoimpl.EnforceVersion(protoimpl.Version - 0)
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
type Enum int32
const (
Enum_ZERO Enum = 0
)
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
// Deprecated: Use Enum.Type.Values instead.
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
var Enum_name = map[int32]string{
0: "ZERO",
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
// Deprecated: Use Enum.Type.Values instead.
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
var Enum_value = map[string]int32{
"ZERO": 0,
}
func (x Enum) Enum() *Enum {
cmd/protoc-gen-go: revert Enum simplication Go1.12 on GoLLVM with LLVM 9.0.0 has a bug where the simpler but equivalent expression results in memory corruption. Revert to the more complex expression to avoid breaking GoLLVM and it is not worth waiting for a GoLLVM fix. Change-Id: I8b42965ca9bd333deb8693021e7b22f966e13521 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/171463 Reviewed-by: Damien Neil <dneil@google.com>
2019-04-10 15:29:01 -07:00
p := new(Enum)
*p = x
return p
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
}
func (x Enum) String() string {
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
return protoimpl.X.EnumStringOf(x.Type(), protoreflect.EnumNumber(x))
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
}
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
func (Enum) Type() protoreflect.EnumType {
return xxx_File_extensions_ext_ext_proto_enumTypes[0]
}
func (x Enum) Number() protoreflect.EnumNumber {
return protoreflect.EnumNumber(x)
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
// Deprecated: Do not use.
func (x *Enum) UnmarshalJSON(b []byte) error {
num, err := protoimpl.X.UnmarshalJSONEnum(x.Type(), b)
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
if err != nil {
return err
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
*x = Enum(num)
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
return nil
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
// Deprecated: Use Enum.Type instead.
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
func (Enum) EnumDescriptor() ([]byte, []int) {
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
return xxx_File_extensions_ext_ext_proto_rawDescGZIP(), []int{0}
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
}
type Message struct {
Data []byte `protobuf:"bytes,1,opt,name=data" json:"data,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
func (x *Message) Reset() {
*x = Message{}
}
func (x *Message) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*Message) ProtoMessage() {}
func (x *Message) ProtoReflect() protoreflect.Message {
return xxx_File_extensions_ext_ext_proto_messageTypes[0].MessageOf(x)
cmd/protoc-gen-go: add support for protobuf reflection Implement support in protoc-gen-go for generating messages and enums that satisfy the v2 protobuf reflection interfaces. Specifically, the following are added: * top-level variable representing the file descriptor * ProtoReflect method on enums (to implement protoV2.Enum) * ProtoReflect method on messages (to implement protoV2.Message) The following are not supported yet: * resolving transitive dependencies for file imports * Extension descriptors * Service descriptors The implementation approach creates a single array for all the message and enum declarations and references sections of that array to complete dependencies. Since protobuf declarations can form a graph (a message may depend on itself), it is difficult to construct a graph as a single literal. One way is to use placeholder descriptors, but that is not efficient as it requires encoding the full name of each dependent enum and message and then later resolving it; thus, both expanding the binary size and also increasing initialization cost. Instead, we add a prototype.{Enum,Message}.Reference method to obtain a descriptor reference for the purposes for satisfying dependencies. As such, nested declarations and dependencies are populated in an init function. Other changes to support the implementation: * Added a protoimpl package to expose the MessageType type and also the MessageTypeOf and EnumTypeOf helper functions. * Added a protogen.File.GoIdent field to provide a suggested variable name for the file descriptor. * Added prototype.{Enum,Message}.Reference that provides a descriptor reference for the purposes for satisfying cyclic dependencies. * Added protoreflect.{Syntax,Cardinality,Kind}.GoString to obtain a Go source identifier that represents the given constant. Change-Id: I9455764882dee6ad10f251901e7d419091e8bf1d Reviewed-on: https://go-review.googlesource.com/c/150074 Reviewed-by: Damien Neil <dneil@google.com>
2018-11-15 14:44:37 -08:00
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
proto, runtime/protoiface: add support for fast-path marshaling Allow message implementations to provide optimized versions of standard operations. Generated messages now include a ProtoReflectMethods method, returning a protoiface.Methods struct containing pointers to assorted optional functions. The Methods struct also includes a Flags field indicating support for optional features such as deterministic marshaling. Implementation of the fast paths (and tests) will come in later CLs. Change-Id: Idd1beed0ecf43ec5e5e7b8da2ee1e08d3ce32213 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170340 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-04-01 13:31:55 -07:00
func (m *Message) XXX_Methods() *protoiface.Methods {
return xxx_File_extensions_ext_ext_proto_messageTypes[0].Methods()
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
// Deprecated: Use Message.ProtoReflect.Type instead.
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
func (*Message) Descriptor() ([]byte, []int) {
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
return xxx_File_extensions_ext_ext_proto_rawDescGZIP(), []int{0}
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
}
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
func (x *Message) GetData() []byte {
if x != nil {
return x.Data
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
}
return nil
}
type ExtensionGroup struct {
ExtensionGroup *string `protobuf:"bytes,120,opt,name=extension_group,json=extensionGroup" json:"extension_group,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
func (x *ExtensionGroup) Reset() {
*x = ExtensionGroup{}
}
func (x *ExtensionGroup) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*ExtensionGroup) ProtoMessage() {}
func (x *ExtensionGroup) ProtoReflect() protoreflect.Message {
return xxx_File_extensions_ext_ext_proto_messageTypes[1].MessageOf(x)
cmd/protoc-gen-go: add support for protobuf reflection Implement support in protoc-gen-go for generating messages and enums that satisfy the v2 protobuf reflection interfaces. Specifically, the following are added: * top-level variable representing the file descriptor * ProtoReflect method on enums (to implement protoV2.Enum) * ProtoReflect method on messages (to implement protoV2.Message) The following are not supported yet: * resolving transitive dependencies for file imports * Extension descriptors * Service descriptors The implementation approach creates a single array for all the message and enum declarations and references sections of that array to complete dependencies. Since protobuf declarations can form a graph (a message may depend on itself), it is difficult to construct a graph as a single literal. One way is to use placeholder descriptors, but that is not efficient as it requires encoding the full name of each dependent enum and message and then later resolving it; thus, both expanding the binary size and also increasing initialization cost. Instead, we add a prototype.{Enum,Message}.Reference method to obtain a descriptor reference for the purposes for satisfying dependencies. As such, nested declarations and dependencies are populated in an init function. Other changes to support the implementation: * Added a protoimpl package to expose the MessageType type and also the MessageTypeOf and EnumTypeOf helper functions. * Added a protogen.File.GoIdent field to provide a suggested variable name for the file descriptor. * Added prototype.{Enum,Message}.Reference that provides a descriptor reference for the purposes for satisfying cyclic dependencies. * Added protoreflect.{Syntax,Cardinality,Kind}.GoString to obtain a Go source identifier that represents the given constant. Change-Id: I9455764882dee6ad10f251901e7d419091e8bf1d Reviewed-on: https://go-review.googlesource.com/c/150074 Reviewed-by: Damien Neil <dneil@google.com>
2018-11-15 14:44:37 -08:00
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
proto, runtime/protoiface: add support for fast-path marshaling Allow message implementations to provide optimized versions of standard operations. Generated messages now include a ProtoReflectMethods method, returning a protoiface.Methods struct containing pointers to assorted optional functions. The Methods struct also includes a Flags field indicating support for optional features such as deterministic marshaling. Implementation of the fast paths (and tests) will come in later CLs. Change-Id: Idd1beed0ecf43ec5e5e7b8da2ee1e08d3ce32213 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170340 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-04-01 13:31:55 -07:00
func (m *ExtensionGroup) XXX_Methods() *protoiface.Methods {
return xxx_File_extensions_ext_ext_proto_messageTypes[1].Methods()
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
// Deprecated: Use ExtensionGroup.ProtoReflect.Type instead.
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
func (*ExtensionGroup) Descriptor() ([]byte, []int) {
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
return xxx_File_extensions_ext_ext_proto_rawDescGZIP(), []int{1}
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
}
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
func (x *ExtensionGroup) GetExtensionGroup() string {
if x != nil && x.ExtensionGroup != nil {
return *x.ExtensionGroup
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
}
return ""
}
// Extend in the scope of another type.
type ExtendingMessage struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
func (x *ExtendingMessage) Reset() {
*x = ExtendingMessage{}
}
func (x *ExtendingMessage) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*ExtendingMessage) ProtoMessage() {}
func (x *ExtendingMessage) ProtoReflect() protoreflect.Message {
return xxx_File_extensions_ext_ext_proto_messageTypes[2].MessageOf(x)
cmd/protoc-gen-go: add support for protobuf reflection Implement support in protoc-gen-go for generating messages and enums that satisfy the v2 protobuf reflection interfaces. Specifically, the following are added: * top-level variable representing the file descriptor * ProtoReflect method on enums (to implement protoV2.Enum) * ProtoReflect method on messages (to implement protoV2.Message) The following are not supported yet: * resolving transitive dependencies for file imports * Extension descriptors * Service descriptors The implementation approach creates a single array for all the message and enum declarations and references sections of that array to complete dependencies. Since protobuf declarations can form a graph (a message may depend on itself), it is difficult to construct a graph as a single literal. One way is to use placeholder descriptors, but that is not efficient as it requires encoding the full name of each dependent enum and message and then later resolving it; thus, both expanding the binary size and also increasing initialization cost. Instead, we add a prototype.{Enum,Message}.Reference method to obtain a descriptor reference for the purposes for satisfying dependencies. As such, nested declarations and dependencies are populated in an init function. Other changes to support the implementation: * Added a protoimpl package to expose the MessageType type and also the MessageTypeOf and EnumTypeOf helper functions. * Added a protogen.File.GoIdent field to provide a suggested variable name for the file descriptor. * Added prototype.{Enum,Message}.Reference that provides a descriptor reference for the purposes for satisfying cyclic dependencies. * Added protoreflect.{Syntax,Cardinality,Kind}.GoString to obtain a Go source identifier that represents the given constant. Change-Id: I9455764882dee6ad10f251901e7d419091e8bf1d Reviewed-on: https://go-review.googlesource.com/c/150074 Reviewed-by: Damien Neil <dneil@google.com>
2018-11-15 14:44:37 -08:00
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
proto, runtime/protoiface: add support for fast-path marshaling Allow message implementations to provide optimized versions of standard operations. Generated messages now include a ProtoReflectMethods method, returning a protoiface.Methods struct containing pointers to assorted optional functions. The Methods struct also includes a Flags field indicating support for optional features such as deterministic marshaling. Implementation of the fast paths (and tests) will come in later CLs. Change-Id: Idd1beed0ecf43ec5e5e7b8da2ee1e08d3ce32213 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170340 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-04-01 13:31:55 -07:00
func (m *ExtendingMessage) XXX_Methods() *protoiface.Methods {
return xxx_File_extensions_ext_ext_proto_messageTypes[2].Methods()
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
// Deprecated: Use ExtendingMessage.ProtoReflect.Type instead.
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
func (*ExtendingMessage) Descriptor() ([]byte, []int) {
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
return xxx_File_extensions_ext_ext_proto_rawDescGZIP(), []int{2}
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
}
type RepeatedGroup struct {
RepeatedXGroup []string `protobuf:"bytes,319,rep,name=repeated_x_group,json=repeatedXGroup" json:"repeated_x_group,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
func (x *RepeatedGroup) Reset() {
*x = RepeatedGroup{}
}
func (x *RepeatedGroup) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*RepeatedGroup) ProtoMessage() {}
func (x *RepeatedGroup) ProtoReflect() protoreflect.Message {
return xxx_File_extensions_ext_ext_proto_messageTypes[3].MessageOf(x)
cmd/protoc-gen-go: add support for protobuf reflection Implement support in protoc-gen-go for generating messages and enums that satisfy the v2 protobuf reflection interfaces. Specifically, the following are added: * top-level variable representing the file descriptor * ProtoReflect method on enums (to implement protoV2.Enum) * ProtoReflect method on messages (to implement protoV2.Message) The following are not supported yet: * resolving transitive dependencies for file imports * Extension descriptors * Service descriptors The implementation approach creates a single array for all the message and enum declarations and references sections of that array to complete dependencies. Since protobuf declarations can form a graph (a message may depend on itself), it is difficult to construct a graph as a single literal. One way is to use placeholder descriptors, but that is not efficient as it requires encoding the full name of each dependent enum and message and then later resolving it; thus, both expanding the binary size and also increasing initialization cost. Instead, we add a prototype.{Enum,Message}.Reference method to obtain a descriptor reference for the purposes for satisfying dependencies. As such, nested declarations and dependencies are populated in an init function. Other changes to support the implementation: * Added a protoimpl package to expose the MessageType type and also the MessageTypeOf and EnumTypeOf helper functions. * Added a protogen.File.GoIdent field to provide a suggested variable name for the file descriptor. * Added prototype.{Enum,Message}.Reference that provides a descriptor reference for the purposes for satisfying cyclic dependencies. * Added protoreflect.{Syntax,Cardinality,Kind}.GoString to obtain a Go source identifier that represents the given constant. Change-Id: I9455764882dee6ad10f251901e7d419091e8bf1d Reviewed-on: https://go-review.googlesource.com/c/150074 Reviewed-by: Damien Neil <dneil@google.com>
2018-11-15 14:44:37 -08:00
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
proto, runtime/protoiface: add support for fast-path marshaling Allow message implementations to provide optimized versions of standard operations. Generated messages now include a ProtoReflectMethods method, returning a protoiface.Methods struct containing pointers to assorted optional functions. The Methods struct also includes a Flags field indicating support for optional features such as deterministic marshaling. Implementation of the fast paths (and tests) will come in later CLs. Change-Id: Idd1beed0ecf43ec5e5e7b8da2ee1e08d3ce32213 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170340 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-04-01 13:31:55 -07:00
func (m *RepeatedGroup) XXX_Methods() *protoiface.Methods {
return xxx_File_extensions_ext_ext_proto_messageTypes[3].Methods()
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
// Deprecated: Use RepeatedGroup.ProtoReflect.Type instead.
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
func (*RepeatedGroup) Descriptor() ([]byte, []int) {
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
return xxx_File_extensions_ext_ext_proto_rawDescGZIP(), []int{3}
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
}
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
func (x *RepeatedGroup) GetRepeatedXGroup() []string {
if x != nil {
return x.RepeatedXGroup
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
}
return nil
}
// An extension of an extension.
type Extendable struct {
all: move v1 types over to the v2 repository As a goal, v2 should not depend on v1. As another step towards that end, we move all the types that used to be in the v1 protoapi package over to v2. For now, we place MessageV1, ExtensionRangeV1, and ExtensionDescV1 in runtime/protoiface since these are types that generated messages will probably have to reference forever. An alternative location could be reflect/protoreflect, but it seems unfortunate to have to dirty the namespace of that package with these types. We move ExtensionFieldV1, ExtensionFieldsV1, and ExtensionFieldsOf to internal/impl, since these are related to the implementation of a generated message. Since moving these types from v1 to v2 implies that the v1 protoapi package is useless, we update all usages of v1 protoapi in the v2 repository to point to the relevant v2 type or functionality. CL/168538 is the corresponding change to alter v1. There will be a temporary build failure as it is not possible to submit CL/168519 and CL/168538 atomically. Change-Id: Ide4025c1b6af5b7f0696f4b65b988b4d10a50f0b Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/168519 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-20 18:29:32 -07:00
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_InternalExtensions protoimpl.ExtensionFieldsV1 `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
}
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
func (x *Extendable) Reset() {
*x = Extendable{}
}
func (x *Extendable) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*Extendable) ProtoMessage() {}
func (x *Extendable) ProtoReflect() protoreflect.Message {
return xxx_File_extensions_ext_ext_proto_messageTypes[4].MessageOf(x)
cmd/protoc-gen-go: add support for protobuf reflection Implement support in protoc-gen-go for generating messages and enums that satisfy the v2 protobuf reflection interfaces. Specifically, the following are added: * top-level variable representing the file descriptor * ProtoReflect method on enums (to implement protoV2.Enum) * ProtoReflect method on messages (to implement protoV2.Message) The following are not supported yet: * resolving transitive dependencies for file imports * Extension descriptors * Service descriptors The implementation approach creates a single array for all the message and enum declarations and references sections of that array to complete dependencies. Since protobuf declarations can form a graph (a message may depend on itself), it is difficult to construct a graph as a single literal. One way is to use placeholder descriptors, but that is not efficient as it requires encoding the full name of each dependent enum and message and then later resolving it; thus, both expanding the binary size and also increasing initialization cost. Instead, we add a prototype.{Enum,Message}.Reference method to obtain a descriptor reference for the purposes for satisfying dependencies. As such, nested declarations and dependencies are populated in an init function. Other changes to support the implementation: * Added a protoimpl package to expose the MessageType type and also the MessageTypeOf and EnumTypeOf helper functions. * Added a protogen.File.GoIdent field to provide a suggested variable name for the file descriptor. * Added prototype.{Enum,Message}.Reference that provides a descriptor reference for the purposes for satisfying cyclic dependencies. * Added protoreflect.{Syntax,Cardinality,Kind}.GoString to obtain a Go source identifier that represents the given constant. Change-Id: I9455764882dee6ad10f251901e7d419091e8bf1d Reviewed-on: https://go-review.googlesource.com/c/150074 Reviewed-by: Damien Neil <dneil@google.com>
2018-11-15 14:44:37 -08:00
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
proto, runtime/protoiface: add support for fast-path marshaling Allow message implementations to provide optimized versions of standard operations. Generated messages now include a ProtoReflectMethods method, returning a protoiface.Methods struct containing pointers to assorted optional functions. The Methods struct also includes a Flags field indicating support for optional features such as deterministic marshaling. Implementation of the fast paths (and tests) will come in later CLs. Change-Id: Idd1beed0ecf43ec5e5e7b8da2ee1e08d3ce32213 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170340 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-04-01 13:31:55 -07:00
func (m *Extendable) XXX_Methods() *protoiface.Methods {
return xxx_File_extensions_ext_ext_proto_messageTypes[4].Methods()
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
// Deprecated: Use Extendable.ProtoReflect.Type instead.
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
func (*Extendable) Descriptor() ([]byte, []int) {
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
return xxx_File_extensions_ext_ext_proto_rawDescGZIP(), []int{4}
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
}
all: move v1 types over to the v2 repository As a goal, v2 should not depend on v1. As another step towards that end, we move all the types that used to be in the v1 protoapi package over to v2. For now, we place MessageV1, ExtensionRangeV1, and ExtensionDescV1 in runtime/protoiface since these are types that generated messages will probably have to reference forever. An alternative location could be reflect/protoreflect, but it seems unfortunate to have to dirty the namespace of that package with these types. We move ExtensionFieldV1, ExtensionFieldsV1, and ExtensionFieldsOf to internal/impl, since these are related to the implementation of a generated message. Since moving these types from v1 to v2 implies that the v1 protoapi package is useless, we update all usages of v1 protoapi in the v2 repository to point to the relevant v2 type or functionality. CL/168538 is the corresponding change to alter v1. There will be a temporary build failure as it is not possible to submit CL/168519 and CL/168538 atomically. Change-Id: Ide4025c1b6af5b7f0696f4b65b988b4d10a50f0b Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/168519 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-20 18:29:32 -07:00
var extRange_Extendable = []protoiface.ExtensionRangeV1{
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
{Start: 1, End: 536870911},
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
// Deprecated: Use Extendable.ProtoReflect.Type.ExtensionRanges instead.
all: move v1 types over to the v2 repository As a goal, v2 should not depend on v1. As another step towards that end, we move all the types that used to be in the v1 protoapi package over to v2. For now, we place MessageV1, ExtensionRangeV1, and ExtensionDescV1 in runtime/protoiface since these are types that generated messages will probably have to reference forever. An alternative location could be reflect/protoreflect, but it seems unfortunate to have to dirty the namespace of that package with these types. We move ExtensionFieldV1, ExtensionFieldsV1, and ExtensionFieldsOf to internal/impl, since these are related to the implementation of a generated message. Since moving these types from v1 to v2 implies that the v1 protoapi package is useless, we update all usages of v1 protoapi in the v2 repository to point to the relevant v2 type or functionality. CL/168538 is the corresponding change to alter v1. There will be a temporary build failure as it is not possible to submit CL/168519 and CL/168538 atomically. Change-Id: Ide4025c1b6af5b7f0696f4b65b988b4d10a50f0b Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/168519 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-20 18:29:32 -07:00
func (*Extendable) ExtensionRangeArray() []protoiface.ExtensionRangeV1 {
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
return extRange_Extendable
}
// Message set wire format.
type MessageSetWireFormatExtension struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
func (x *MessageSetWireFormatExtension) Reset() {
*x = MessageSetWireFormatExtension{}
}
func (x *MessageSetWireFormatExtension) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*MessageSetWireFormatExtension) ProtoMessage() {}
func (x *MessageSetWireFormatExtension) ProtoReflect() protoreflect.Message {
return xxx_File_extensions_ext_ext_proto_messageTypes[5].MessageOf(x)
cmd/protoc-gen-go: add support for protobuf reflection Implement support in protoc-gen-go for generating messages and enums that satisfy the v2 protobuf reflection interfaces. Specifically, the following are added: * top-level variable representing the file descriptor * ProtoReflect method on enums (to implement protoV2.Enum) * ProtoReflect method on messages (to implement protoV2.Message) The following are not supported yet: * resolving transitive dependencies for file imports * Extension descriptors * Service descriptors The implementation approach creates a single array for all the message and enum declarations and references sections of that array to complete dependencies. Since protobuf declarations can form a graph (a message may depend on itself), it is difficult to construct a graph as a single literal. One way is to use placeholder descriptors, but that is not efficient as it requires encoding the full name of each dependent enum and message and then later resolving it; thus, both expanding the binary size and also increasing initialization cost. Instead, we add a prototype.{Enum,Message}.Reference method to obtain a descriptor reference for the purposes for satisfying dependencies. As such, nested declarations and dependencies are populated in an init function. Other changes to support the implementation: * Added a protoimpl package to expose the MessageType type and also the MessageTypeOf and EnumTypeOf helper functions. * Added a protogen.File.GoIdent field to provide a suggested variable name for the file descriptor. * Added prototype.{Enum,Message}.Reference that provides a descriptor reference for the purposes for satisfying cyclic dependencies. * Added protoreflect.{Syntax,Cardinality,Kind}.GoString to obtain a Go source identifier that represents the given constant. Change-Id: I9455764882dee6ad10f251901e7d419091e8bf1d Reviewed-on: https://go-review.googlesource.com/c/150074 Reviewed-by: Damien Neil <dneil@google.com>
2018-11-15 14:44:37 -08:00
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
proto, runtime/protoiface: add support for fast-path marshaling Allow message implementations to provide optimized versions of standard operations. Generated messages now include a ProtoReflectMethods method, returning a protoiface.Methods struct containing pointers to assorted optional functions. The Methods struct also includes a Flags field indicating support for optional features such as deterministic marshaling. Implementation of the fast paths (and tests) will come in later CLs. Change-Id: Idd1beed0ecf43ec5e5e7b8da2ee1e08d3ce32213 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170340 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-04-01 13:31:55 -07:00
func (m *MessageSetWireFormatExtension) XXX_Methods() *protoiface.Methods {
return xxx_File_extensions_ext_ext_proto_messageTypes[5].Methods()
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
// Deprecated: Use MessageSetWireFormatExtension.ProtoReflect.Type instead.
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
func (*MessageSetWireFormatExtension) Descriptor() ([]byte, []int) {
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
return xxx_File_extensions_ext_ext_proto_rawDescGZIP(), []int{5}
cmd/protoc-gen-go: generate extensions Generate everything related to extensions: extension descriptors, XXX_InternalExtensions fields, etc. Tweak the order in which we generate code for descriptors to ensure consistent output with the previous protoc-gen-go. Change Field.ContainingType to Field.ParentMessage, since we need to get at the parent of both message fields and extensions (and the "containing type" of an extension field is the extended message, under existing terminology). Change-Id: I5d045ca80536436e7c987bca3d8fb8c1e1521e55 Reviewed-on: https://go-review.googlesource.com/136155 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2018-09-14 15:41:11 -07:00
}
cmd/protoc-gen-go: reduce technical debt The following TODOs were addressed: * Consistently collect all enums, messages, and extensions in a breadth-first order. The practical affect of this is that the declaration order in a Go file may change. This simplifies reflection generation, which relies on consistent ordering. * Removal of placeholder declarations (e.g., "var _ = proto.Marshal") since protogen is intelligent about including imports as necessary. * Always generate a default variable or constant for explicit empty strings. The practical effect of this is the addition of new declarations in some cases. However, it simplifies our logic such that it matches the protobuf data model. * Generate the registration statements in a consistent order. Change-Id: I627bb72589432bb65d53b50965ea88e5f7983977 Reviewed-on: https://go-review.googlesource.com/c/152778 Reviewed-by: Damien Neil <dneil@google.com>
2018-12-05 15:42:52 -08:00
type Message_M struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
func (x *Message_M) Reset() {
*x = Message_M{}
}
func (x *Message_M) String() string {
return protoimpl.X.MessageStringOf(x)
}
func (*Message_M) ProtoMessage() {}
func (x *Message_M) ProtoReflect() protoreflect.Message {
return xxx_File_extensions_ext_ext_proto_messageTypes[6].MessageOf(x)
cmd/protoc-gen-go: reduce technical debt The following TODOs were addressed: * Consistently collect all enums, messages, and extensions in a breadth-first order. The practical affect of this is that the declaration order in a Go file may change. This simplifies reflection generation, which relies on consistent ordering. * Removal of placeholder declarations (e.g., "var _ = proto.Marshal") since protogen is intelligent about including imports as necessary. * Always generate a default variable or constant for explicit empty strings. The practical effect of this is the addition of new declarations in some cases. However, it simplifies our logic such that it matches the protobuf data model. * Generate the registration statements in a consistent order. Change-Id: I627bb72589432bb65d53b50965ea88e5f7983977 Reviewed-on: https://go-review.googlesource.com/c/152778 Reviewed-by: Damien Neil <dneil@google.com>
2018-12-05 15:42:52 -08:00
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
proto, runtime/protoiface: add support for fast-path marshaling Allow message implementations to provide optimized versions of standard operations. Generated messages now include a ProtoReflectMethods method, returning a protoiface.Methods struct containing pointers to assorted optional functions. The Methods struct also includes a Flags field indicating support for optional features such as deterministic marshaling. Implementation of the fast paths (and tests) will come in later CLs. Change-Id: Idd1beed0ecf43ec5e5e7b8da2ee1e08d3ce32213 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170340 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-04-01 13:31:55 -07:00
func (m *Message_M) XXX_Methods() *protoiface.Methods {
return xxx_File_extensions_ext_ext_proto_messageTypes[6].Methods()
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
// Deprecated: Use Message_M.ProtoReflect.Type instead.
cmd/protoc-gen-go: reduce technical debt The following TODOs were addressed: * Consistently collect all enums, messages, and extensions in a breadth-first order. The practical affect of this is that the declaration order in a Go file may change. This simplifies reflection generation, which relies on consistent ordering. * Removal of placeholder declarations (e.g., "var _ = proto.Marshal") since protogen is intelligent about including imports as necessary. * Always generate a default variable or constant for explicit empty strings. The practical effect of this is the addition of new declarations in some cases. However, it simplifies our logic such that it matches the protobuf data model. * Generate the registration statements in a consistent order. Change-Id: I627bb72589432bb65d53b50965ea88e5f7983977 Reviewed-on: https://go-review.googlesource.com/c/152778 Reviewed-by: Damien Neil <dneil@google.com>
2018-12-05 15:42:52 -08:00
func (*Message_M) Descriptor() ([]byte, []int) {
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
return xxx_File_extensions_ext_ext_proto_rawDescGZIP(), []int{0, 0}
cmd/protoc-gen-go: reduce technical debt The following TODOs were addressed: * Consistently collect all enums, messages, and extensions in a breadth-first order. The practical affect of this is that the declaration order in a Go file may change. This simplifies reflection generation, which relies on consistent ordering. * Removal of placeholder declarations (e.g., "var _ = proto.Marshal") since protogen is intelligent about including imports as necessary. * Always generate a default variable or constant for explicit empty strings. The practical effect of this is the addition of new declarations in some cases. However, it simplifies our logic such that it matches the protobuf data model. * Generate the registration statements in a consistent order. Change-Id: I627bb72589432bb65d53b50965ea88e5f7983977 Reviewed-on: https://go-review.googlesource.com/c/152778 Reviewed-by: Damien Neil <dneil@google.com>
2018-12-05 15:42:52 -08:00
}
type ExtendingMessage_ExtendingMessageSubmessage struct {
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
func (x *ExtendingMessage_ExtendingMessageSubmessage) Reset() {
*x = ExtendingMessage_ExtendingMessageSubmessage{}
cmd/protoc-gen-go: reduce technical debt The following TODOs were addressed: * Consistently collect all enums, messages, and extensions in a breadth-first order. The practical affect of this is that the declaration order in a Go file may change. This simplifies reflection generation, which relies on consistent ordering. * Removal of placeholder declarations (e.g., "var _ = proto.Marshal") since protogen is intelligent about including imports as necessary. * Always generate a default variable or constant for explicit empty strings. The practical effect of this is the addition of new declarations in some cases. However, it simplifies our logic such that it matches the protobuf data model. * Generate the registration statements in a consistent order. Change-Id: I627bb72589432bb65d53b50965ea88e5f7983977 Reviewed-on: https://go-review.googlesource.com/c/152778 Reviewed-by: Damien Neil <dneil@google.com>
2018-12-05 15:42:52 -08:00
}
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
func (x *ExtendingMessage_ExtendingMessageSubmessage) String() string {
return protoimpl.X.MessageStringOf(x)
cmd/protoc-gen-go: reduce technical debt The following TODOs were addressed: * Consistently collect all enums, messages, and extensions in a breadth-first order. The practical affect of this is that the declaration order in a Go file may change. This simplifies reflection generation, which relies on consistent ordering. * Removal of placeholder declarations (e.g., "var _ = proto.Marshal") since protogen is intelligent about including imports as necessary. * Always generate a default variable or constant for explicit empty strings. The practical effect of this is the addition of new declarations in some cases. However, it simplifies our logic such that it matches the protobuf data model. * Generate the registration statements in a consistent order. Change-Id: I627bb72589432bb65d53b50965ea88e5f7983977 Reviewed-on: https://go-review.googlesource.com/c/152778 Reviewed-by: Damien Neil <dneil@google.com>
2018-12-05 15:42:52 -08:00
}
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
cmd/protoc-gen-go: reduce technical debt The following TODOs were addressed: * Consistently collect all enums, messages, and extensions in a breadth-first order. The practical affect of this is that the declaration order in a Go file may change. This simplifies reflection generation, which relies on consistent ordering. * Removal of placeholder declarations (e.g., "var _ = proto.Marshal") since protogen is intelligent about including imports as necessary. * Always generate a default variable or constant for explicit empty strings. The practical effect of this is the addition of new declarations in some cases. However, it simplifies our logic such that it matches the protobuf data model. * Generate the registration statements in a consistent order. Change-Id: I627bb72589432bb65d53b50965ea88e5f7983977 Reviewed-on: https://go-review.googlesource.com/c/152778 Reviewed-by: Damien Neil <dneil@google.com>
2018-12-05 15:42:52 -08:00
func (*ExtendingMessage_ExtendingMessageSubmessage) ProtoMessage() {}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
cmd/protoc-gen-go: perform some code cleanup Minor changes: * Use x as the receiver since "e" and "m" are meaningless in the presence of user-defined enum and message names. * Consistently keep enum methods together, rather awkwardly split apart by the value maps. Change-Id: I68e5666efb56ac7a4d062fb223b9f826dc72aba9 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170357 Reviewed-by: Herbie Ong <herbie@google.com>
2019-04-01 12:59:24 -07:00
func (x *ExtendingMessage_ExtendingMessageSubmessage) ProtoReflect() protoreflect.Message {
return xxx_File_extensions_ext_ext_proto_messageTypes[7].MessageOf(x)
}
proto, runtime/protoiface: add support for fast-path marshaling Allow message implementations to provide optimized versions of standard operations. Generated messages now include a ProtoReflectMethods method, returning a protoiface.Methods struct containing pointers to assorted optional functions. The Methods struct also includes a Flags field indicating support for optional features such as deterministic marshaling. Implementation of the fast paths (and tests) will come in later CLs. Change-Id: Idd1beed0ecf43ec5e5e7b8da2ee1e08d3ce32213 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/170340 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-04-01 13:31:55 -07:00
func (m *ExtendingMessage_ExtendingMessageSubmessage) XXX_Methods() *protoiface.Methods {
return xxx_File_extensions_ext_ext_proto_messageTypes[7].Methods()
}
cmd/protoc-gen-go: rely on protoimpl for basic helpers The EnumName, UnmarshalJSONEnum, and CompressGZIP helpers currently live in v1 protoapi, which would cause all generated messages to depend on v1. In an effort to break the dependency of v2 on v1, we move these helper functions to v2 (and re-written to take advantage of protobuf reflection). These helpers are unfortunate, but we cannot eliminate the functionality that they implement since they are exposed in the publicly generated API. Since EnumName does not rely on the enum maps, it removes another dependency on those variables. Eventually, we can get to the point where these variables (though declared) are not linked into the binary if the user does not use them. Also, we rely on the v1 proto package for registration instead of v1 protoapi. This may re-introduce a cyclic dependency on descriptor proto again in the future, but the better approach is to just start registering with v2. Change-Id: Id755585a7a1df14e4a6a2dfa650df221a3c153fb Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167921 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-16 00:05:34 -07:00
// Deprecated: Use ExtendingMessage_ExtendingMessageSubmessage.ProtoReflect.Type instead.
cmd/protoc-gen-go: reduce technical debt The following TODOs were addressed: * Consistently collect all enums, messages, and extensions in a breadth-first order. The practical affect of this is that the declaration order in a Go file may change. This simplifies reflection generation, which relies on consistent ordering. * Removal of placeholder declarations (e.g., "var _ = proto.Marshal") since protogen is intelligent about including imports as necessary. * Always generate a default variable or constant for explicit empty strings. The practical effect of this is the addition of new declarations in some cases. However, it simplifies our logic such that it matches the protobuf data model. * Generate the registration statements in a consistent order. Change-Id: I627bb72589432bb65d53b50965ea88e5f7983977 Reviewed-on: https://go-review.googlesource.com/c/152778 Reviewed-by: Damien Neil <dneil@google.com>
2018-12-05 15:42:52 -08:00
func (*ExtendingMessage_ExtendingMessageSubmessage) Descriptor() ([]byte, []int) {
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
return xxx_File_extensions_ext_ext_proto_rawDescGZIP(), []int{2, 0}
cmd/protoc-gen-go: reduce technical debt The following TODOs were addressed: * Consistently collect all enums, messages, and extensions in a breadth-first order. The practical affect of this is that the declaration order in a Go file may change. This simplifies reflection generation, which relies on consistent ordering. * Removal of placeholder declarations (e.g., "var _ = proto.Marshal") since protogen is intelligent about including imports as necessary. * Always generate a default variable or constant for explicit empty strings. The practical effect of this is the addition of new declarations in some cases. However, it simplifies our logic such that it matches the protobuf data model. * Generate the registration statements in a consistent order. Change-Id: I627bb72589432bb65d53b50965ea88e5f7983977 Reviewed-on: https://go-review.googlesource.com/c/152778 Reviewed-by: Damien Neil <dneil@google.com>
2018-12-05 15:42:52 -08:00
}
all: move v1 types over to the v2 repository As a goal, v2 should not depend on v1. As another step towards that end, we move all the types that used to be in the v1 protoapi package over to v2. For now, we place MessageV1, ExtensionRangeV1, and ExtensionDescV1 in runtime/protoiface since these are types that generated messages will probably have to reference forever. An alternative location could be reflect/protoreflect, but it seems unfortunate to have to dirty the namespace of that package with these types. We move ExtensionFieldV1, ExtensionFieldsV1, and ExtensionFieldsOf to internal/impl, since these are related to the implementation of a generated message. Since moving these types from v1 to v2 implies that the v1 protoapi package is useless, we update all usages of v1 protoapi in the v2 repository to point to the relevant v2 type or functionality. CL/168538 is the corresponding change to alter v1. There will be a temporary build failure as it is not possible to submit CL/168519 and CL/168538 atomically. Change-Id: Ide4025c1b6af5b7f0696f4b65b988b4d10a50f0b Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/168519 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-20 18:29:32 -07:00
var xxx_File_extensions_ext_ext_proto_extDescs = []protoiface.ExtensionDescV1{
cmd/protoc-gen-go: correlate v1 ExtensionDesc with v2 ExtensionType Unfortunately a good amount of code uses pointer comparisons on the v1 ExtensionDesc to determine exactly which extension field is set, rather than checking whether the extension descriptor semantically describes the field that they are interested in. To preserve this behavior in v1, we need a 1:1 mapping between a v2 ExtensionType and a specific v1 ExtensionDesc. Change-Id: I852b3cefb4585bd656e48e5adad6cc28795d02df Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167759 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-14 16:08:22 -07:00
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*bool)(nil),
Field: 101,
Name: "goproto.protoc.extension.ext.extension_bool",
Tag: "varint,101,opt,name=extension_bool",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*Enum)(nil),
Field: 102,
Name: "goproto.protoc.extension.ext.extension_enum",
Tag: "varint,102,opt,name=extension_enum,enum=goproto.protoc.extension.ext.Enum",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*int32)(nil),
Field: 103,
Name: "goproto.protoc.extension.ext.extension_int32",
Tag: "varint,103,opt,name=extension_int32",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*int32)(nil),
Field: 104,
Name: "goproto.protoc.extension.ext.extension_sint32",
Tag: "zigzag32,104,opt,name=extension_sint32",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*uint32)(nil),
Field: 105,
Name: "goproto.protoc.extension.ext.extension_uint32",
Tag: "varint,105,opt,name=extension_uint32",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*int64)(nil),
Field: 106,
Name: "goproto.protoc.extension.ext.extension_int64",
Tag: "varint,106,opt,name=extension_int64",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*int64)(nil),
Field: 107,
Name: "goproto.protoc.extension.ext.extension_sint64",
Tag: "zigzag64,107,opt,name=extension_sint64",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*uint64)(nil),
Field: 108,
Name: "goproto.protoc.extension.ext.extension_uint64",
Tag: "varint,108,opt,name=extension_uint64",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*int32)(nil),
Field: 109,
Name: "goproto.protoc.extension.ext.extension_sfixed32",
Tag: "fixed32,109,opt,name=extension_sfixed32",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*uint32)(nil),
Field: 110,
Name: "goproto.protoc.extension.ext.extension_fixed32",
Tag: "fixed32,110,opt,name=extension_fixed32",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*float32)(nil),
Field: 111,
Name: "goproto.protoc.extension.ext.extension_float",
Tag: "fixed32,111,opt,name=extension_float",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*int64)(nil),
Field: 112,
Name: "goproto.protoc.extension.ext.extension_sfixed64",
Tag: "fixed64,112,opt,name=extension_sfixed64",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*uint64)(nil),
Field: 113,
Name: "goproto.protoc.extension.ext.extension_fixed64",
Tag: "fixed64,113,opt,name=extension_fixed64",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*float64)(nil),
Field: 114,
Name: "goproto.protoc.extension.ext.extension_double",
Tag: "fixed64,114,opt,name=extension_double",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*string)(nil),
Field: 115,
Name: "goproto.protoc.extension.ext.extension_string",
Tag: "bytes,115,opt,name=extension_string",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]byte)(nil),
Field: 116,
Name: "goproto.protoc.extension.ext.extension_bytes",
Tag: "bytes,116,opt,name=extension_bytes",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*Message)(nil),
Field: 117,
Name: "goproto.protoc.extension.ext.extension_Message",
Tag: "bytes,117,opt,name=extension_Message",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*Message_M)(nil),
Field: 118,
Name: "goproto.protoc.extension.ext.extension_MessageM",
Tag: "bytes,118,opt,name=extension_MessageM",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*ExtensionGroup)(nil),
Field: 119,
Name: "goproto.protoc.extension.ext.extensiongroup",
Tag: "group,119,opt,name=ExtensionGroup",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*extra.ExtraMessage)(nil),
Field: 9,
Name: "goproto.protoc.extension.ext.extra_message",
Tag: "bytes,9,opt,name=extra_message",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]bool)(nil),
Field: 301,
Name: "goproto.protoc.extension.ext.repeated_x_bool",
Tag: "varint,301,rep,name=repeated_x_bool",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]Enum)(nil),
Field: 302,
Name: "goproto.protoc.extension.ext.repeated_x_enum",
Tag: "varint,302,rep,name=repeated_x_enum,enum=goproto.protoc.extension.ext.Enum",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]int32)(nil),
Field: 303,
Name: "goproto.protoc.extension.ext.repeated_x_int32",
Tag: "varint,303,rep,name=repeated_x_int32",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]int32)(nil),
Field: 304,
Name: "goproto.protoc.extension.ext.repeated_x_sint32",
Tag: "zigzag32,304,rep,name=repeated_x_sint32",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]uint32)(nil),
Field: 305,
Name: "goproto.protoc.extension.ext.repeated_x_uint32",
Tag: "varint,305,rep,name=repeated_x_uint32",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]int64)(nil),
Field: 306,
Name: "goproto.protoc.extension.ext.repeated_x_int64",
Tag: "varint,306,rep,name=repeated_x_int64",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]int64)(nil),
Field: 307,
Name: "goproto.protoc.extension.ext.repeated_x_sint64",
Tag: "zigzag64,307,rep,name=repeated_x_sint64",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]uint64)(nil),
Field: 308,
Name: "goproto.protoc.extension.ext.repeated_x_uint64",
Tag: "varint,308,rep,name=repeated_x_uint64",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]int32)(nil),
Field: 309,
Name: "goproto.protoc.extension.ext.repeated_x_sfixed32",
Tag: "fixed32,309,rep,name=repeated_x_sfixed32",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]uint32)(nil),
Field: 310,
Name: "goproto.protoc.extension.ext.repeated_x_fixed32",
Tag: "fixed32,310,rep,name=repeated_x_fixed32",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]float32)(nil),
Field: 311,
Name: "goproto.protoc.extension.ext.repeated_x_float",
Tag: "fixed32,311,rep,name=repeated_x_float",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]int64)(nil),
Field: 312,
Name: "goproto.protoc.extension.ext.repeated_x_sfixed64",
Tag: "fixed64,312,rep,name=repeated_x_sfixed64",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]uint64)(nil),
Field: 313,
Name: "goproto.protoc.extension.ext.repeated_x_fixed64",
Tag: "fixed64,313,rep,name=repeated_x_fixed64",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]float64)(nil),
Field: 314,
Name: "goproto.protoc.extension.ext.repeated_x_double",
Tag: "fixed64,314,rep,name=repeated_x_double",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]string)(nil),
Field: 315,
Name: "goproto.protoc.extension.ext.repeated_x_string",
Tag: "bytes,315,rep,name=repeated_x_string",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([][]byte)(nil),
Field: 316,
Name: "goproto.protoc.extension.ext.repeated_x_bytes",
Tag: "bytes,316,rep,name=repeated_x_bytes",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]*Message)(nil),
Field: 317,
Name: "goproto.protoc.extension.ext.repeated_x_Message",
Tag: "bytes,317,rep,name=repeated_x_Message",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: ([]*RepeatedGroup)(nil),
Field: 318,
Name: "goproto.protoc.extension.ext.repeatedgroup",
Tag: "group,318,rep,name=RepeatedGroup",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*Extendable)(nil),
Field: 400,
Name: "goproto.protoc.extension.ext.extendable_field",
Tag: "bytes,400,opt,name=extendable_field",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*Extendable)(nil),
ExtensionType: (*string)(nil),
Field: 1,
Name: "goproto.protoc.extension.ext.extendable_string_field",
Tag: "bytes,1,opt,name=extendable_string_field",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.MessageSetWireFormatMessage)(nil),
ExtensionType: (*MessageSetWireFormatExtension)(nil),
Field: 101,
Name: "goproto.protoc.extension.ext.",
Tag: "bytes,101,opt,name=message_set_extension",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*string)(nil),
Field: 200,
Name: "goproto.protoc.extension.ext.ExtendingMessage.extending_message_string",
Tag: "bytes,200,opt,name=extending_message_string",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.BaseMessage)(nil),
ExtensionType: (*ExtendingMessage_ExtendingMessageSubmessage)(nil),
Field: 201,
Name: "goproto.protoc.extension.ext.ExtendingMessage.extending_message_submessage",
Tag: "bytes,201,opt,name=extending_message_submessage",
Filename: "extensions/ext/ext.proto",
},
{
ExtendedType: (*base.MessageSetWireFormatMessage)(nil),
ExtensionType: (*MessageSetWireFormatExtension)(nil),
Field: 100,
Name: "goproto.protoc.extension.ext.MessageSetWireFormatExtension",
Tag: "bytes,100,opt,name=message_set_extension",
Filename: "extensions/ext/ext.proto",
},
}
var (
// extend goproto.protoc.extension.base.BaseMessage { optional bool extension_bool = 101; }
E_ExtensionBool = &xxx_File_extensions_ext_ext_proto_extDescs[0]
// extend goproto.protoc.extension.base.BaseMessage { optional goproto.protoc.extension.ext.Enum extension_enum = 102; }
E_ExtensionEnum = &xxx_File_extensions_ext_ext_proto_extDescs[1]
// extend goproto.protoc.extension.base.BaseMessage { optional int32 extension_int32 = 103; }
E_ExtensionInt32 = &xxx_File_extensions_ext_ext_proto_extDescs[2]
// extend goproto.protoc.extension.base.BaseMessage { optional sint32 extension_sint32 = 104; }
E_ExtensionSint32 = &xxx_File_extensions_ext_ext_proto_extDescs[3]
// extend goproto.protoc.extension.base.BaseMessage { optional uint32 extension_uint32 = 105; }
E_ExtensionUint32 = &xxx_File_extensions_ext_ext_proto_extDescs[4]
// extend goproto.protoc.extension.base.BaseMessage { optional int64 extension_int64 = 106; }
E_ExtensionInt64 = &xxx_File_extensions_ext_ext_proto_extDescs[5]
// extend goproto.protoc.extension.base.BaseMessage { optional sint64 extension_sint64 = 107; }
E_ExtensionSint64 = &xxx_File_extensions_ext_ext_proto_extDescs[6]
// extend goproto.protoc.extension.base.BaseMessage { optional uint64 extension_uint64 = 108; }
E_ExtensionUint64 = &xxx_File_extensions_ext_ext_proto_extDescs[7]
// extend goproto.protoc.extension.base.BaseMessage { optional sfixed32 extension_sfixed32 = 109; }
E_ExtensionSfixed32 = &xxx_File_extensions_ext_ext_proto_extDescs[8]
// extend goproto.protoc.extension.base.BaseMessage { optional fixed32 extension_fixed32 = 110; }
E_ExtensionFixed32 = &xxx_File_extensions_ext_ext_proto_extDescs[9]
// extend goproto.protoc.extension.base.BaseMessage { optional float extension_float = 111; }
E_ExtensionFloat = &xxx_File_extensions_ext_ext_proto_extDescs[10]
// extend goproto.protoc.extension.base.BaseMessage { optional sfixed64 extension_sfixed64 = 112; }
E_ExtensionSfixed64 = &xxx_File_extensions_ext_ext_proto_extDescs[11]
// extend goproto.protoc.extension.base.BaseMessage { optional fixed64 extension_fixed64 = 113; }
E_ExtensionFixed64 = &xxx_File_extensions_ext_ext_proto_extDescs[12]
// extend goproto.protoc.extension.base.BaseMessage { optional double extension_double = 114; }
E_ExtensionDouble = &xxx_File_extensions_ext_ext_proto_extDescs[13]
// extend goproto.protoc.extension.base.BaseMessage { optional string extension_string = 115; }
E_ExtensionString = &xxx_File_extensions_ext_ext_proto_extDescs[14]
// extend goproto.protoc.extension.base.BaseMessage { optional bytes extension_bytes = 116; }
E_ExtensionBytes = &xxx_File_extensions_ext_ext_proto_extDescs[15]
// extend goproto.protoc.extension.base.BaseMessage { optional goproto.protoc.extension.ext.Message extension_Message = 117; }
E_Extension_Message = &xxx_File_extensions_ext_ext_proto_extDescs[16]
// extend goproto.protoc.extension.base.BaseMessage { optional goproto.protoc.extension.ext.Message.M extension_MessageM = 118; }
E_Extension_MessageM = &xxx_File_extensions_ext_ext_proto_extDescs[17]
// extend goproto.protoc.extension.base.BaseMessage { optional goproto.protoc.extension.ext.ExtensionGroup extensiongroup = 119; }
E_Extensiongroup = &xxx_File_extensions_ext_ext_proto_extDescs[18]
// extend goproto.protoc.extension.base.BaseMessage { optional goproto.protoc.extension.extra.ExtraMessage extra_message = 9; }
E_ExtraMessage = &xxx_File_extensions_ext_ext_proto_extDescs[19]
// extend goproto.protoc.extension.base.BaseMessage { repeated bool repeated_x_bool = 301; }
E_RepeatedXBool = &xxx_File_extensions_ext_ext_proto_extDescs[20]
// extend goproto.protoc.extension.base.BaseMessage { repeated goproto.protoc.extension.ext.Enum repeated_x_enum = 302; }
E_RepeatedXEnum = &xxx_File_extensions_ext_ext_proto_extDescs[21]
// extend goproto.protoc.extension.base.BaseMessage { repeated int32 repeated_x_int32 = 303; }
E_RepeatedXInt32 = &xxx_File_extensions_ext_ext_proto_extDescs[22]
// extend goproto.protoc.extension.base.BaseMessage { repeated sint32 repeated_x_sint32 = 304; }
E_RepeatedXSint32 = &xxx_File_extensions_ext_ext_proto_extDescs[23]
// extend goproto.protoc.extension.base.BaseMessage { repeated uint32 repeated_x_uint32 = 305; }
E_RepeatedXUint32 = &xxx_File_extensions_ext_ext_proto_extDescs[24]
// extend goproto.protoc.extension.base.BaseMessage { repeated int64 repeated_x_int64 = 306; }
E_RepeatedXInt64 = &xxx_File_extensions_ext_ext_proto_extDescs[25]
// extend goproto.protoc.extension.base.BaseMessage { repeated sint64 repeated_x_sint64 = 307; }
E_RepeatedXSint64 = &xxx_File_extensions_ext_ext_proto_extDescs[26]
// extend goproto.protoc.extension.base.BaseMessage { repeated uint64 repeated_x_uint64 = 308; }
E_RepeatedXUint64 = &xxx_File_extensions_ext_ext_proto_extDescs[27]
// extend goproto.protoc.extension.base.BaseMessage { repeated sfixed32 repeated_x_sfixed32 = 309; }
E_RepeatedXSfixed32 = &xxx_File_extensions_ext_ext_proto_extDescs[28]
// extend goproto.protoc.extension.base.BaseMessage { repeated fixed32 repeated_x_fixed32 = 310; }
E_RepeatedXFixed32 = &xxx_File_extensions_ext_ext_proto_extDescs[29]
// extend goproto.protoc.extension.base.BaseMessage { repeated float repeated_x_float = 311; }
E_RepeatedXFloat = &xxx_File_extensions_ext_ext_proto_extDescs[30]
// extend goproto.protoc.extension.base.BaseMessage { repeated sfixed64 repeated_x_sfixed64 = 312; }
E_RepeatedXSfixed64 = &xxx_File_extensions_ext_ext_proto_extDescs[31]
// extend goproto.protoc.extension.base.BaseMessage { repeated fixed64 repeated_x_fixed64 = 313; }
E_RepeatedXFixed64 = &xxx_File_extensions_ext_ext_proto_extDescs[32]
// extend goproto.protoc.extension.base.BaseMessage { repeated double repeated_x_double = 314; }
E_RepeatedXDouble = &xxx_File_extensions_ext_ext_proto_extDescs[33]
// extend goproto.protoc.extension.base.BaseMessage { repeated string repeated_x_string = 315; }
E_RepeatedXString = &xxx_File_extensions_ext_ext_proto_extDescs[34]
// extend goproto.protoc.extension.base.BaseMessage { repeated bytes repeated_x_bytes = 316; }
E_RepeatedXBytes = &xxx_File_extensions_ext_ext_proto_extDescs[35]
// extend goproto.protoc.extension.base.BaseMessage { repeated goproto.protoc.extension.ext.Message repeated_x_Message = 317; }
E_RepeatedX_Message = &xxx_File_extensions_ext_ext_proto_extDescs[36]
// extend goproto.protoc.extension.base.BaseMessage { repeated goproto.protoc.extension.ext.RepeatedGroup repeatedgroup = 318; }
E_Repeatedgroup = &xxx_File_extensions_ext_ext_proto_extDescs[37]
// extend goproto.protoc.extension.base.BaseMessage { optional goproto.protoc.extension.ext.Extendable extendable_field = 400; }
E_ExtendableField = &xxx_File_extensions_ext_ext_proto_extDescs[38]
// extend goproto.protoc.extension.ext.Extendable { optional string extendable_string_field = 1; }
E_ExtendableStringField = &xxx_File_extensions_ext_ext_proto_extDescs[39]
// extend goproto.protoc.extension.base.MessageSetWireFormatMessage { optional goproto.protoc.extension.ext.MessageSetWireFormatExtension message_set_extension = 101; }
E_MessageSetExtension = &xxx_File_extensions_ext_ext_proto_extDescs[40]
// extend goproto.protoc.extension.base.BaseMessage { optional string extending_message_string = 200; }
E_ExtendingMessage_ExtendingMessageString = &xxx_File_extensions_ext_ext_proto_extDescs[41]
// extend goproto.protoc.extension.base.BaseMessage { optional goproto.protoc.extension.ext.ExtendingMessage.ExtendingMessageSubmessage extending_message_submessage = 201; }
E_ExtendingMessage_ExtendingMessageSubmessage = &xxx_File_extensions_ext_ext_proto_extDescs[42]
// extend goproto.protoc.extension.base.MessageSetWireFormatMessage { optional goproto.protoc.extension.ext.MessageSetWireFormatExtension message_set_extension = 100; }
E_MessageSetWireFormatExtension_MessageSetExtension = &xxx_File_extensions_ext_ext_proto_extDescs[43]
)
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
var File_extensions_ext_ext_proto protoreflect.FileDescriptor
var xxx_File_extensions_ext_ext_proto_rawDesc = []byte{
internal/fileinit: generate reflect data structures from raw descriptors This CL takes a significantly different approach to generating support for protobuf reflection. The previous approach involved generating a large number of Go literals to represent the reflection information. While that approach was correct, it resulted in too much binary bloat. The approach taken here initializes the reflection information from the raw descriptor proto, which is a relatively dense representation of the protobuf reflection information. In order to keep initialization cost low, several measures were taken: * At program init, the bare minimum is parsed in order to initialize naming information for enums, messages, extensions, and services declared in the file. This is done because those top-level declarations are often relevant for registration. * Only upon first are most of the other data structures for protobuf reflection actually initialized. * Instead of using proto.Unmarshal, a hand-written unmarshaler is used. This allows us to avoid a dependendency on the descriptor proto and also because the API for the descriptor proto is fundamentally non-performant since it requires an allocation for every primitive field. At a high-level, the new implementation lives in internal/fileinit. Several changes were made to other parts of the repository: * cmd/protoc-gen-go: * Stop compressing the raw descriptors. While compression does reduce the size of the descriptors by approximately 2x, it is a pre-mature optimization since the descriptors themselves are around 1% of the total binary bloat that is due to generated protobufs. * Seeding protobuf reflection from the raw descriptor significantly simplifies the generator implementation since it is no longer responsible for constructing a tree of Go literals to represent the same information. * We remove the generation of the shadow types and instead call protoimpl.MessageType.MessageOf. Unfortunately, this incurs an allocation for every call to ProtoReflect since we need to allocate a tuple that wraps a pointer to the message value, and a pointer to message type. * internal/impl: * We add a MessageType.GoType field and make it required that it is set prior to first use. This is done so that we can avoid calling MessageType.init except for when it is actually needed. The allows code to call (*FooMessage)(nil).ProtoReflect().Type() without fearing that the init code will run, possibly triggering a recursive deadlock (where the init code depends on getting the Type of some dependency which may be declared within the same file). * internal/cmd/generate-types: * The code to generate reflect/prototype/protofile_list_gen.go was copied and altered to generated internal/fileinit.desc_list_gen.go. At a high-level this CL adds significant technical complexity. However, this is offset by several possible future changes: * The prototype package can be drastically simplified. We can probably reimplement internal/legacy to use internal/fileinit instead, allowing us to drop another dependency on the prototype package. As a result, we can probably delete most of the constructor types in that package. * With the prototype package significantly pruned, and the fact that generated code no longer depend on depends on that package, we can consider merging what's left of prototype into protodesc. Change-Id: I6090f023f2e1b6afaf62bd3ae883566242e30715 Reviewed-on: https://go-review.googlesource.com/c/158539 Reviewed-by: Herbie Ong <herbie@google.com> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-01-18 09:32:24 -08:00
0x0a, 0x18, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x73, 0x2f, 0x65, 0x78, 0x74,
0x2f, 0x65, 0x78, 0x74, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x12, 0x1c, 0x67, 0x6f, 0x70, 0x72,
0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e,
0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x65, 0x78, 0x74, 0x1a, 0x1a, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73,
0x69, 0x6f, 0x6e, 0x73, 0x2f, 0x62, 0x61, 0x73, 0x65, 0x2f, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x70,
0x72, 0x6f, 0x74, 0x6f, 0x1a, 0x1c, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x73,
0x2f, 0x65, 0x78, 0x74, 0x72, 0x61, 0x2f, 0x65, 0x78, 0x74, 0x72, 0x61, 0x2e, 0x70, 0x72, 0x6f,
0x74, 0x6f, 0x22, 0x22, 0x0a, 0x07, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x12, 0x12, 0x0a,
0x04, 0x64, 0x61, 0x74, 0x61, 0x18, 0x01, 0x20, 0x01, 0x28, 0x0c, 0x52, 0x04, 0x64, 0x61, 0x74,
0x61, 0x1a, 0x03, 0x0a, 0x01, 0x4d, 0x22, 0x39, 0x0a, 0x0e, 0x45, 0x78, 0x74, 0x65, 0x6e, 0x73,
0x69, 0x6f, 0x6e, 0x47, 0x72, 0x6f, 0x75, 0x70, 0x12, 0x27, 0x0a, 0x0f, 0x65, 0x78, 0x74, 0x65,
0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x67, 0x72, 0x6f, 0x75, 0x70, 0x18, 0x78, 0x20, 0x01, 0x28,
0x09, 0x52, 0x0e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x47, 0x72, 0x6f, 0x75,
0x70, 0x22, 0xd2, 0x02, 0x0a, 0x10, 0x45, 0x78, 0x74, 0x65, 0x6e, 0x64, 0x69, 0x6e, 0x67, 0x4d,
0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x1a, 0x1c, 0x0a, 0x1a, 0x45, 0x78, 0x74, 0x65, 0x6e, 0x64,
0x69, 0x6e, 0x67, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x53, 0x75, 0x62, 0x6d, 0x65, 0x73,
0x73, 0x61, 0x67, 0x65, 0x32, 0x65, 0x0a, 0x18, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x64, 0x69, 0x6e,
0x67, 0x5f, 0x6d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x5f, 0x73, 0x74, 0x72, 0x69, 0x6e, 0x67,
0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f,
0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65,
0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0xc8, 0x01, 0x20,
0x01, 0x28, 0x09, 0x52, 0x16, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x64, 0x69, 0x6e, 0x67, 0x4d, 0x65,
0x73, 0x73, 0x61, 0x67, 0x65, 0x53, 0x74, 0x72, 0x69, 0x6e, 0x67, 0x32, 0xb8, 0x01, 0x0a, 0x1c,
0x65, 0x78, 0x74, 0x65, 0x6e, 0x64, 0x69, 0x6e, 0x67, 0x5f, 0x6d, 0x65, 0x73, 0x73, 0x61, 0x67,
0x65, 0x5f, 0x73, 0x75, 0x62, 0x6d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x12, 0x2a, 0x2e, 0x67,
0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78,
0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73,
0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0xc9, 0x01, 0x20, 0x01, 0x28, 0x0b, 0x32,
0x49, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63,
0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x65, 0x78, 0x74, 0x2e, 0x45,
0x78, 0x74, 0x65, 0x6e, 0x64, 0x69, 0x6e, 0x67, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x2e,
0x45, 0x78, 0x74, 0x65, 0x6e, 0x64, 0x69, 0x6e, 0x67, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65,
0x53, 0x75, 0x62, 0x6d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x52, 0x1a, 0x65, 0x78, 0x74, 0x65,
0x6e, 0x64, 0x69, 0x6e, 0x67, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x53, 0x75, 0x62, 0x6d,
0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x22, 0x3a, 0x0a, 0x0d, 0x52, 0x65, 0x70, 0x65, 0x61, 0x74,
0x65, 0x64, 0x47, 0x72, 0x6f, 0x75, 0x70, 0x12, 0x29, 0x0a, 0x10, 0x72, 0x65, 0x70, 0x65, 0x61,
0x74, 0x65, 0x64, 0x5f, 0x78, 0x5f, 0x67, 0x72, 0x6f, 0x75, 0x70, 0x18, 0xbf, 0x02, 0x20, 0x03,
0x28, 0x09, 0x52, 0x0e, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x58, 0x47, 0x72, 0x6f,
0x75, 0x70, 0x22, 0x16, 0x0a, 0x0a, 0x45, 0x78, 0x74, 0x65, 0x6e, 0x64, 0x61, 0x62, 0x6c, 0x65,
0x2a, 0x08, 0x08, 0x01, 0x10, 0x80, 0x80, 0x80, 0x80, 0x02, 0x22, 0xcd, 0x01, 0x0a, 0x1d, 0x4d,
0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x53, 0x65, 0x74, 0x57, 0x69, 0x72, 0x65, 0x46, 0x6f, 0x72,
0x6d, 0x61, 0x74, 0x45, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x32, 0xab, 0x01, 0x0a,
0x15, 0x6d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x5f, 0x73, 0x65, 0x74, 0x5f, 0x65, 0x78, 0x74,
0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x12, 0x3a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f,
0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f,
0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x53, 0x65,
0x74, 0x57, 0x69, 0x72, 0x65, 0x46, 0x6f, 0x72, 0x6d, 0x61, 0x74, 0x4d, 0x65, 0x73, 0x73, 0x61,
0x67, 0x65, 0x18, 0x64, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x3b, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f,
0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73,
0x69, 0x6f, 0x6e, 0x2e, 0x65, 0x78, 0x74, 0x2e, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x53,
0x65, 0x74, 0x57, 0x69, 0x72, 0x65, 0x46, 0x6f, 0x72, 0x6d, 0x61, 0x74, 0x45, 0x78, 0x74, 0x65,
0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x52, 0x13, 0x6d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x53, 0x65,
0x74, 0x45, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2a, 0x10, 0x0a, 0x04, 0x45, 0x6e,
0x75, 0x6d, 0x12, 0x08, 0x0a, 0x04, 0x5a, 0x45, 0x52, 0x4f, 0x10, 0x00, 0x3a, 0x51, 0x0a, 0x0e,
0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x62, 0x6f, 0x6f, 0x6c, 0x12, 0x2a,
0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e,
0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42,
0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0x65, 0x20, 0x01, 0x28, 0x08,
0x52, 0x0d, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x42, 0x6f, 0x6f, 0x6c, 0x3a,
0x75, 0x0a, 0x0e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x65, 0x6e, 0x75,
0x6d, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74,
0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73,
0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0x66, 0x20,
0x01, 0x28, 0x0e, 0x32, 0x22, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72,
0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x65,
0x78, 0x74, 0x2e, 0x45, 0x6e, 0x75, 0x6d, 0x52, 0x0d, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69,
0x6f, 0x6e, 0x45, 0x6e, 0x75, 0x6d, 0x3a, 0x53, 0x0a, 0x0f, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73,
0x69, 0x6f, 0x6e, 0x5f, 0x69, 0x6e, 0x74, 0x33, 0x32, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72,
0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e,
0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65,
0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0x67, 0x20, 0x01, 0x28, 0x05, 0x52, 0x0e, 0x65, 0x78, 0x74,
0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x49, 0x6e, 0x74, 0x33, 0x32, 0x3a, 0x55, 0x0a, 0x10, 0x65,
0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x73, 0x69, 0x6e, 0x74, 0x33, 0x32, 0x12,
0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63,
0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e,
0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0x68, 0x20, 0x01, 0x28,
0x11, 0x52, 0x0f, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x53, 0x69, 0x6e, 0x74,
0x33, 0x32, 0x3a, 0x55, 0x0a, 0x10, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x5f,
0x75, 0x69, 0x6e, 0x74, 0x33, 0x32, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f,
0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f,
0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61,
0x67, 0x65, 0x18, 0x69, 0x20, 0x01, 0x28, 0x0d, 0x52, 0x0f, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73,
0x69, 0x6f, 0x6e, 0x55, 0x69, 0x6e, 0x74, 0x33, 0x32, 0x3a, 0x53, 0x0a, 0x0f, 0x65, 0x78, 0x74,
0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x69, 0x6e, 0x74, 0x36, 0x34, 0x12, 0x2a, 0x2e, 0x67,
0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78,
0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73,
0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0x6a, 0x20, 0x01, 0x28, 0x03, 0x52, 0x0e,
0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x49, 0x6e, 0x74, 0x36, 0x34, 0x3a, 0x55,
0x0a, 0x10, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x73, 0x69, 0x6e, 0x74,
0x36, 0x34, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f,
0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61,
0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0x6b,
0x20, 0x01, 0x28, 0x12, 0x52, 0x0f, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x53,
0x69, 0x6e, 0x74, 0x36, 0x34, 0x3a, 0x55, 0x0a, 0x10, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69,
0x6f, 0x6e, 0x5f, 0x75, 0x69, 0x6e, 0x74, 0x36, 0x34, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72,
0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e,
0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65,
0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0x6c, 0x20, 0x01, 0x28, 0x04, 0x52, 0x0f, 0x65, 0x78, 0x74,
0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x55, 0x69, 0x6e, 0x74, 0x36, 0x34, 0x3a, 0x59, 0x0a, 0x12,
0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x73, 0x66, 0x69, 0x78, 0x65, 0x64,
0x33, 0x32, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f,
0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61,
0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0x6d,
0x20, 0x01, 0x28, 0x0f, 0x52, 0x11, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x53,
0x66, 0x69, 0x78, 0x65, 0x64, 0x33, 0x32, 0x3a, 0x57, 0x0a, 0x11, 0x65, 0x78, 0x74, 0x65, 0x6e,
0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x66, 0x69, 0x78, 0x65, 0x64, 0x33, 0x32, 0x12, 0x2a, 0x2e, 0x67,
0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78,
0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73,
0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0x6e, 0x20, 0x01, 0x28, 0x07, 0x52, 0x10,
0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x46, 0x69, 0x78, 0x65, 0x64, 0x33, 0x32,
0x3a, 0x53, 0x0a, 0x0f, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x66, 0x6c,
0x6f, 0x61, 0x74, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72,
0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62,
0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18,
0x6f, 0x20, 0x01, 0x28, 0x02, 0x52, 0x0e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e,
0x46, 0x6c, 0x6f, 0x61, 0x74, 0x3a, 0x59, 0x0a, 0x12, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69,
0x6f, 0x6e, 0x5f, 0x73, 0x66, 0x69, 0x78, 0x65, 0x64, 0x36, 0x34, 0x12, 0x2a, 0x2e, 0x67, 0x6f,
0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74,
0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65,
0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0x70, 0x20, 0x01, 0x28, 0x10, 0x52, 0x11, 0x65,
0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x53, 0x66, 0x69, 0x78, 0x65, 0x64, 0x36, 0x34,
0x3a, 0x57, 0x0a, 0x11, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x66, 0x69,
0x78, 0x65, 0x64, 0x36, 0x34, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e,
0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e,
0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67,
0x65, 0x18, 0x71, 0x20, 0x01, 0x28, 0x06, 0x52, 0x10, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69,
0x6f, 0x6e, 0x46, 0x69, 0x78, 0x65, 0x64, 0x36, 0x34, 0x3a, 0x55, 0x0a, 0x10, 0x65, 0x78, 0x74,
0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x64, 0x6f, 0x75, 0x62, 0x6c, 0x65, 0x12, 0x2a, 0x2e,
0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65,
0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61,
0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0x72, 0x20, 0x01, 0x28, 0x01, 0x52,
0x0f, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x44, 0x6f, 0x75, 0x62, 0x6c, 0x65,
0x3a, 0x55, 0x0a, 0x10, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x73, 0x74,
0x72, 0x69, 0x6e, 0x67, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70,
0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e,
0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65,
0x18, 0x73, 0x20, 0x01, 0x28, 0x09, 0x52, 0x0f, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f,
0x6e, 0x53, 0x74, 0x72, 0x69, 0x6e, 0x67, 0x3a, 0x53, 0x0a, 0x0f, 0x65, 0x78, 0x74, 0x65, 0x6e,
0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x62, 0x79, 0x74, 0x65, 0x73, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70,
0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65,
0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d,
0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0x74, 0x20, 0x01, 0x28, 0x0c, 0x52, 0x0e, 0x65, 0x78,
0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x42, 0x79, 0x74, 0x65, 0x73, 0x3a, 0x7e, 0x0a, 0x11,
0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67,
0x65, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74,
0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73,
0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0x75, 0x20,
0x01, 0x28, 0x0b, 0x32, 0x25, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72,
0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x65,
0x78, 0x74, 0x2e, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x52, 0x10, 0x65, 0x78, 0x74, 0x65,
0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x3a, 0x82, 0x01, 0x0a,
0x12, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x5f, 0x4d, 0x65, 0x73, 0x73, 0x61,
0x67, 0x65, 0x4d, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72,
0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62,
0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18,
0x76, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x27, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e,
0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e,
0x2e, 0x65, 0x78, 0x74, 0x2e, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x2e, 0x4d, 0x52, 0x11,
0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65,
0x4d, 0x3a, 0x80, 0x01, 0x0a, 0x0e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x67,
0x72, 0x6f, 0x75, 0x70, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70,
0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e,
0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65,
0x18, 0x77, 0x20, 0x01, 0x28, 0x0a, 0x32, 0x2c, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f,
0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f,
0x6e, 0x2e, 0x65, 0x78, 0x74, 0x2e, 0x45, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x47,
0x72, 0x6f, 0x75, 0x70, 0x52, 0x0e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x67,
0x72, 0x6f, 0x75, 0x70, 0x3a, 0x7d, 0x0a, 0x0d, 0x65, 0x78, 0x74, 0x72, 0x61, 0x5f, 0x6d, 0x65,
0x73, 0x73, 0x61, 0x67, 0x65, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e,
0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e,
0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67,
0x65, 0x18, 0x09, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x2c, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74,
0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69,
0x6f, 0x6e, 0x2e, 0x65, 0x78, 0x74, 0x72, 0x61, 0x2e, 0x45, 0x78, 0x74, 0x72, 0x61, 0x4d, 0x65,
0x73, 0x73, 0x61, 0x67, 0x65, 0x52, 0x0c, 0x65, 0x78, 0x74, 0x72, 0x61, 0x4d, 0x65, 0x73, 0x73,
0x61, 0x67, 0x65, 0x3a, 0x53, 0x0a, 0x0f, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x5f,
0x78, 0x5f, 0x62, 0x6f, 0x6f, 0x6c, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f,
0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f,
0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61,
0x67, 0x65, 0x18, 0xad, 0x02, 0x20, 0x03, 0x28, 0x08, 0x52, 0x0d, 0x72, 0x65, 0x70, 0x65, 0x61,
0x74, 0x65, 0x64, 0x58, 0x42, 0x6f, 0x6f, 0x6c, 0x3a, 0x77, 0x0a, 0x0f, 0x72, 0x65, 0x70, 0x65,
0x61, 0x74, 0x65, 0x64, 0x5f, 0x78, 0x5f, 0x65, 0x6e, 0x75, 0x6d, 0x12, 0x2a, 0x2e, 0x67, 0x6f,
0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74,
0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65,
0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0xae, 0x02, 0x20, 0x03, 0x28, 0x0e, 0x32, 0x22,
0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e,
0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x65, 0x78, 0x74, 0x2e, 0x45, 0x6e,
0x75, 0x6d, 0x52, 0x0d, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x58, 0x45, 0x6e, 0x75,
0x6d, 0x3a, 0x55, 0x0a, 0x10, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x5f, 0x78, 0x5f,
0x69, 0x6e, 0x74, 0x33, 0x32, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e,
0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e,
0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67,
0x65, 0x18, 0xaf, 0x02, 0x20, 0x03, 0x28, 0x05, 0x52, 0x0e, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74,
0x65, 0x64, 0x58, 0x49, 0x6e, 0x74, 0x33, 0x32, 0x3a, 0x57, 0x0a, 0x11, 0x72, 0x65, 0x70, 0x65,
0x61, 0x74, 0x65, 0x64, 0x5f, 0x78, 0x5f, 0x73, 0x69, 0x6e, 0x74, 0x33, 0x32, 0x12, 0x2a, 0x2e,
0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65,
0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61,
0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0xb0, 0x02, 0x20, 0x03, 0x28, 0x11,
0x52, 0x0f, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x58, 0x53, 0x69, 0x6e, 0x74, 0x33,
0x32, 0x3a, 0x57, 0x0a, 0x11, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x5f, 0x78, 0x5f,
0x75, 0x69, 0x6e, 0x74, 0x33, 0x32, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f,
0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f,
0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61,
0x67, 0x65, 0x18, 0xb1, 0x02, 0x20, 0x03, 0x28, 0x0d, 0x52, 0x0f, 0x72, 0x65, 0x70, 0x65, 0x61,
0x74, 0x65, 0x64, 0x58, 0x55, 0x69, 0x6e, 0x74, 0x33, 0x32, 0x3a, 0x55, 0x0a, 0x10, 0x72, 0x65,
0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x5f, 0x78, 0x5f, 0x69, 0x6e, 0x74, 0x36, 0x34, 0x12, 0x2a,
0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e,
0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42,
0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0xb2, 0x02, 0x20, 0x03, 0x28,
0x03, 0x52, 0x0e, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x58, 0x49, 0x6e, 0x74, 0x36,
0x34, 0x3a, 0x57, 0x0a, 0x11, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x5f, 0x78, 0x5f,
0x73, 0x69, 0x6e, 0x74, 0x36, 0x34, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f,
0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f,
0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61,
0x67, 0x65, 0x18, 0xb3, 0x02, 0x20, 0x03, 0x28, 0x12, 0x52, 0x0f, 0x72, 0x65, 0x70, 0x65, 0x61,
0x74, 0x65, 0x64, 0x58, 0x53, 0x69, 0x6e, 0x74, 0x36, 0x34, 0x3a, 0x57, 0x0a, 0x11, 0x72, 0x65,
0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x5f, 0x78, 0x5f, 0x75, 0x69, 0x6e, 0x74, 0x36, 0x34, 0x12,
0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63,
0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e,
0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0xb4, 0x02, 0x20, 0x03,
0x28, 0x04, 0x52, 0x0f, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x58, 0x55, 0x69, 0x6e,
0x74, 0x36, 0x34, 0x3a, 0x5b, 0x0a, 0x13, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x5f,
0x78, 0x5f, 0x73, 0x66, 0x69, 0x78, 0x65, 0x64, 0x33, 0x32, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70,
0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65,
0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d,
0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0xb5, 0x02, 0x20, 0x03, 0x28, 0x0f, 0x52, 0x11, 0x72,
0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x58, 0x53, 0x66, 0x69, 0x78, 0x65, 0x64, 0x33, 0x32,
0x3a, 0x59, 0x0a, 0x12, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x5f, 0x78, 0x5f, 0x66,
0x69, 0x78, 0x65, 0x64, 0x33, 0x32, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f,
0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f,
0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61,
0x67, 0x65, 0x18, 0xb6, 0x02, 0x20, 0x03, 0x28, 0x07, 0x52, 0x10, 0x72, 0x65, 0x70, 0x65, 0x61,
0x74, 0x65, 0x64, 0x58, 0x46, 0x69, 0x78, 0x65, 0x64, 0x33, 0x32, 0x3a, 0x55, 0x0a, 0x10, 0x72,
0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x5f, 0x78, 0x5f, 0x66, 0x6c, 0x6f, 0x61, 0x74, 0x12,
0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63,
0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e,
0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0xb7, 0x02, 0x20, 0x03,
0x28, 0x02, 0x52, 0x0e, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x58, 0x46, 0x6c, 0x6f,
0x61, 0x74, 0x3a, 0x5b, 0x0a, 0x13, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x5f, 0x78,
0x5f, 0x73, 0x66, 0x69, 0x78, 0x65, 0x64, 0x36, 0x34, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72,
0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e,
0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65,
0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0xb8, 0x02, 0x20, 0x03, 0x28, 0x10, 0x52, 0x11, 0x72, 0x65,
0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x58, 0x53, 0x66, 0x69, 0x78, 0x65, 0x64, 0x36, 0x34, 0x3a,
0x59, 0x0a, 0x12, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x5f, 0x78, 0x5f, 0x66, 0x69,
0x78, 0x65, 0x64, 0x36, 0x34, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e,
0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e,
0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67,
0x65, 0x18, 0xb9, 0x02, 0x20, 0x03, 0x28, 0x06, 0x52, 0x10, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74,
0x65, 0x64, 0x58, 0x46, 0x69, 0x78, 0x65, 0x64, 0x36, 0x34, 0x3a, 0x57, 0x0a, 0x11, 0x72, 0x65,
0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x5f, 0x78, 0x5f, 0x64, 0x6f, 0x75, 0x62, 0x6c, 0x65, 0x12,
0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63,
0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e,
0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0xba, 0x02, 0x20, 0x03,
0x28, 0x01, 0x52, 0x0f, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x58, 0x44, 0x6f, 0x75,
0x62, 0x6c, 0x65, 0x3a, 0x57, 0x0a, 0x11, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x5f,
0x78, 0x5f, 0x73, 0x74, 0x72, 0x69, 0x6e, 0x67, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f,
0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73,
0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73,
0x73, 0x61, 0x67, 0x65, 0x18, 0xbb, 0x02, 0x20, 0x03, 0x28, 0x09, 0x52, 0x0f, 0x72, 0x65, 0x70,
0x65, 0x61, 0x74, 0x65, 0x64, 0x58, 0x53, 0x74, 0x72, 0x69, 0x6e, 0x67, 0x3a, 0x55, 0x0a, 0x10,
0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x5f, 0x78, 0x5f, 0x62, 0x79, 0x74, 0x65, 0x73,
0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f,
0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65,
0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0xbc, 0x02, 0x20,
0x03, 0x28, 0x0c, 0x52, 0x0e, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x58, 0x42, 0x79,
0x74, 0x65, 0x73, 0x3a, 0x80, 0x01, 0x0a, 0x12, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64,
0x5f, 0x78, 0x5f, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70,
0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65,
0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d,
0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0xbd, 0x02, 0x20, 0x03, 0x28, 0x0b, 0x32, 0x25, 0x2e,
0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65,
0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x65, 0x78, 0x74, 0x2e, 0x4d, 0x65, 0x73,
0x73, 0x61, 0x67, 0x65, 0x52, 0x10, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65, 0x64, 0x58, 0x4d,
0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x3a, 0x7e, 0x0a, 0x0d, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74,
0x65, 0x64, 0x67, 0x72, 0x6f, 0x75, 0x70, 0x12, 0x2a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74,
0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69,
0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65, 0x4d, 0x65, 0x73, 0x73,
0x61, 0x67, 0x65, 0x18, 0xbe, 0x02, 0x20, 0x03, 0x28, 0x0a, 0x32, 0x2b, 0x2e, 0x67, 0x6f, 0x70,
0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65,
0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x65, 0x78, 0x74, 0x2e, 0x52, 0x65, 0x70, 0x65, 0x61, 0x74,
0x65, 0x64, 0x47, 0x72, 0x6f, 0x75, 0x70, 0x52, 0x0d, 0x72, 0x65, 0x70, 0x65, 0x61, 0x74, 0x65,
0x64, 0x67, 0x72, 0x6f, 0x75, 0x70, 0x3a, 0x80, 0x01, 0x0a, 0x10, 0x65, 0x78, 0x74, 0x65, 0x6e,
0x64, 0x61, 0x62, 0x6c, 0x65, 0x5f, 0x66, 0x69, 0x65, 0x6c, 0x64, 0x12, 0x2a, 0x2e, 0x67, 0x6f,
0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74,
0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x42, 0x61, 0x73, 0x65,
0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x18, 0x90, 0x03, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x28,
0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e,
0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e, 0x65, 0x78, 0x74, 0x2e, 0x45, 0x78,
0x74, 0x65, 0x6e, 0x64, 0x61, 0x62, 0x6c, 0x65, 0x52, 0x0f, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x64,
0x61, 0x62, 0x6c, 0x65, 0x46, 0x69, 0x65, 0x6c, 0x64, 0x3a, 0x60, 0x0a, 0x17, 0x65, 0x78, 0x74,
0x65, 0x6e, 0x64, 0x61, 0x62, 0x6c, 0x65, 0x5f, 0x73, 0x74, 0x72, 0x69, 0x6e, 0x67, 0x5f, 0x66,
0x69, 0x65, 0x6c, 0x64, 0x12, 0x28, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e, 0x70,
0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x2e,
0x65, 0x78, 0x74, 0x2e, 0x45, 0x78, 0x74, 0x65, 0x6e, 0x64, 0x61, 0x62, 0x6c, 0x65, 0x18, 0x01,
0x20, 0x01, 0x28, 0x09, 0x52, 0x15, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x64, 0x61, 0x62, 0x6c, 0x65,
0x53, 0x74, 0x72, 0x69, 0x6e, 0x67, 0x46, 0x69, 0x65, 0x6c, 0x64, 0x3a, 0xab, 0x01, 0x0a, 0x15,
0x6d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x5f, 0x73, 0x65, 0x74, 0x5f, 0x65, 0x78, 0x74, 0x65,
0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x12, 0x3a, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x2e,
0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e,
0x2e, 0x62, 0x61, 0x73, 0x65, 0x2e, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x53, 0x65, 0x74,
0x57, 0x69, 0x72, 0x65, 0x46, 0x6f, 0x72, 0x6d, 0x61, 0x74, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67,
0x65, 0x18, 0x65, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x3b, 0x2e, 0x67, 0x6f, 0x70, 0x72, 0x6f, 0x74,
0x6f, 0x2e, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2e, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69,
0x6f, 0x6e, 0x2e, 0x65, 0x78, 0x74, 0x2e, 0x4d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x53, 0x65,
0x74, 0x57, 0x69, 0x72, 0x65, 0x46, 0x6f, 0x72, 0x6d, 0x61, 0x74, 0x45, 0x78, 0x74, 0x65, 0x6e,
0x73, 0x69, 0x6f, 0x6e, 0x52, 0x13, 0x6d, 0x65, 0x73, 0x73, 0x61, 0x67, 0x65, 0x53, 0x65, 0x74,
0x45, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x42, 0x49, 0x5a, 0x47, 0x67, 0x69, 0x74,
0x68, 0x75, 0x62, 0x2e, 0x63, 0x6f, 0x6d, 0x2f, 0x67, 0x6f, 0x6c, 0x61, 0x6e, 0x67, 0x2f, 0x70,
0x72, 0x6f, 0x74, 0x6f, 0x62, 0x75, 0x66, 0x2f, 0x76, 0x32, 0x2f, 0x63, 0x6d, 0x64, 0x2f, 0x70,
0x72, 0x6f, 0x74, 0x6f, 0x63, 0x2d, 0x67, 0x65, 0x6e, 0x2d, 0x67, 0x6f, 0x2f, 0x74, 0x65, 0x73,
0x74, 0x64, 0x61, 0x74, 0x61, 0x2f, 0x65, 0x78, 0x74, 0x65, 0x6e, 0x73, 0x69, 0x6f, 0x6e, 0x73,
0x2f, 0x65, 0x78, 0x74,
}
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
var (
xxx_File_extensions_ext_ext_proto_rawDesc_once sync.Once
xxx_File_extensions_ext_ext_proto_rawDesc_data = xxx_File_extensions_ext_ext_proto_rawDesc
)
cmd/protoc-gen-go: add support for protobuf reflection Implement support in protoc-gen-go for generating messages and enums that satisfy the v2 protobuf reflection interfaces. Specifically, the following are added: * top-level variable representing the file descriptor * ProtoReflect method on enums (to implement protoV2.Enum) * ProtoReflect method on messages (to implement protoV2.Message) The following are not supported yet: * resolving transitive dependencies for file imports * Extension descriptors * Service descriptors The implementation approach creates a single array for all the message and enum declarations and references sections of that array to complete dependencies. Since protobuf declarations can form a graph (a message may depend on itself), it is difficult to construct a graph as a single literal. One way is to use placeholder descriptors, but that is not efficient as it requires encoding the full name of each dependent enum and message and then later resolving it; thus, both expanding the binary size and also increasing initialization cost. Instead, we add a prototype.{Enum,Message}.Reference method to obtain a descriptor reference for the purposes for satisfying dependencies. As such, nested declarations and dependencies are populated in an init function. Other changes to support the implementation: * Added a protoimpl package to expose the MessageType type and also the MessageTypeOf and EnumTypeOf helper functions. * Added a protogen.File.GoIdent field to provide a suggested variable name for the file descriptor. * Added prototype.{Enum,Message}.Reference that provides a descriptor reference for the purposes for satisfying cyclic dependencies. * Added protoreflect.{Syntax,Cardinality,Kind}.GoString to obtain a Go source identifier that represents the given constant. Change-Id: I9455764882dee6ad10f251901e7d419091e8bf1d Reviewed-on: https://go-review.googlesource.com/c/150074 Reviewed-by: Damien Neil <dneil@google.com>
2018-11-15 14:44:37 -08:00
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
func xxx_File_extensions_ext_ext_proto_rawDescGZIP() []byte {
xxx_File_extensions_ext_ext_proto_rawDesc_once.Do(func() {
xxx_File_extensions_ext_ext_proto_rawDesc_data = protoimpl.X.CompressGZIP(xxx_File_extensions_ext_ext_proto_rawDesc_data)
})
return xxx_File_extensions_ext_ext_proto_rawDesc_data
}
cmd/protoc-gen-go: add support for protobuf reflection Implement support in protoc-gen-go for generating messages and enums that satisfy the v2 protobuf reflection interfaces. Specifically, the following are added: * top-level variable representing the file descriptor * ProtoReflect method on enums (to implement protoV2.Enum) * ProtoReflect method on messages (to implement protoV2.Message) The following are not supported yet: * resolving transitive dependencies for file imports * Extension descriptors * Service descriptors The implementation approach creates a single array for all the message and enum declarations and references sections of that array to complete dependencies. Since protobuf declarations can form a graph (a message may depend on itself), it is difficult to construct a graph as a single literal. One way is to use placeholder descriptors, but that is not efficient as it requires encoding the full name of each dependent enum and message and then later resolving it; thus, both expanding the binary size and also increasing initialization cost. Instead, we add a prototype.{Enum,Message}.Reference method to obtain a descriptor reference for the purposes for satisfying dependencies. As such, nested declarations and dependencies are populated in an init function. Other changes to support the implementation: * Added a protoimpl package to expose the MessageType type and also the MessageTypeOf and EnumTypeOf helper functions. * Added a protogen.File.GoIdent field to provide a suggested variable name for the file descriptor. * Added prototype.{Enum,Message}.Reference that provides a descriptor reference for the purposes for satisfying cyclic dependencies. * Added protoreflect.{Syntax,Cardinality,Kind}.GoString to obtain a Go source identifier that represents the given constant. Change-Id: I9455764882dee6ad10f251901e7d419091e8bf1d Reviewed-on: https://go-review.googlesource.com/c/150074 Reviewed-by: Damien Neil <dneil@google.com>
2018-11-15 14:44:37 -08:00
cmd/protoc-gen-go: change some arrays to slices to save bytes Using arrays in the generated reflection information adds unnecessary eq and hash functions being added to the package. Change to slices to reduce bloat. Change-Id: I1a4f6d59021644d93dd6c24679b9233141e89a75 Reviewed-on: https://go-review.googlesource.com/c/164640 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-03-01 13:22:30 -08:00
var xxx_File_extensions_ext_ext_proto_enumTypes = make([]protoreflect.EnumType, 1)
var xxx_File_extensions_ext_ext_proto_messageTypes = make([]protoimpl.MessageType, 8)
protogen: use full path for generated file variable name Use the full path (including the extension) for the generation of the per-file variable name. Several reasons for this: * The current logic is buggy in the case where pathType == pathTypeImport since the prefix variable will be mangled with the Go import path. * The extension is technically part of the path. Thus, "path/to/foo.proto" and "path/to/foo.protodevel" are two distinctly different imports. * Style-wise, it subjectively looks better. Rather than being a mixture of camelCase and snake_case, it is all snake_case for the common case: before: ProtoFile_google_protobuf_any after: File_google_protobuf_any_proto * Since the extension is almost always ".proto", this results in a suffix of "_proto", which provides an additional layer of protection against possible name conflicts. The previous approach could possibly have a conflict between "Foo.proto" and a message named ProtoFile with a sub-message called Foo. Also, use the per-file variable name for the raw descriptor variables instead of the hashed version. Change-Id: Ic91e326b7593e5985cee6ececc60539c27fe32fe Reviewed-on: https://go-review.googlesource.com/c/164379 Reviewed-by: Damien Neil <dneil@google.com>
2019-02-27 20:25:51 -08:00
var xxx_File_extensions_ext_ext_proto_goTypes = []interface{}{
internal/fileinit: generate reflect data structures from raw descriptors This CL takes a significantly different approach to generating support for protobuf reflection. The previous approach involved generating a large number of Go literals to represent the reflection information. While that approach was correct, it resulted in too much binary bloat. The approach taken here initializes the reflection information from the raw descriptor proto, which is a relatively dense representation of the protobuf reflection information. In order to keep initialization cost low, several measures were taken: * At program init, the bare minimum is parsed in order to initialize naming information for enums, messages, extensions, and services declared in the file. This is done because those top-level declarations are often relevant for registration. * Only upon first are most of the other data structures for protobuf reflection actually initialized. * Instead of using proto.Unmarshal, a hand-written unmarshaler is used. This allows us to avoid a dependendency on the descriptor proto and also because the API for the descriptor proto is fundamentally non-performant since it requires an allocation for every primitive field. At a high-level, the new implementation lives in internal/fileinit. Several changes were made to other parts of the repository: * cmd/protoc-gen-go: * Stop compressing the raw descriptors. While compression does reduce the size of the descriptors by approximately 2x, it is a pre-mature optimization since the descriptors themselves are around 1% of the total binary bloat that is due to generated protobufs. * Seeding protobuf reflection from the raw descriptor significantly simplifies the generator implementation since it is no longer responsible for constructing a tree of Go literals to represent the same information. * We remove the generation of the shadow types and instead call protoimpl.MessageType.MessageOf. Unfortunately, this incurs an allocation for every call to ProtoReflect since we need to allocate a tuple that wraps a pointer to the message value, and a pointer to message type. * internal/impl: * We add a MessageType.GoType field and make it required that it is set prior to first use. This is done so that we can avoid calling MessageType.init except for when it is actually needed. The allows code to call (*FooMessage)(nil).ProtoReflect().Type() without fearing that the init code will run, possibly triggering a recursive deadlock (where the init code depends on getting the Type of some dependency which may be declared within the same file). * internal/cmd/generate-types: * The code to generate reflect/prototype/protofile_list_gen.go was copied and altered to generated internal/fileinit.desc_list_gen.go. At a high-level this CL adds significant technical complexity. However, this is offset by several possible future changes: * The prototype package can be drastically simplified. We can probably reimplement internal/legacy to use internal/fileinit instead, allowing us to drop another dependency on the prototype package. As a result, we can probably delete most of the constructor types in that package. * With the prototype package significantly pruned, and the fact that generated code no longer depend on depends on that package, we can consider merging what's left of prototype into protodesc. Change-Id: I6090f023f2e1b6afaf62bd3ae883566242e30715 Reviewed-on: https://go-review.googlesource.com/c/158539 Reviewed-by: Herbie Ong <herbie@google.com> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-01-18 09:32:24 -08:00
(Enum)(0), // 0: goproto.protoc.extension.ext.Enum
(*Message)(nil), // 1: goproto.protoc.extension.ext.Message
(*ExtensionGroup)(nil), // 2: goproto.protoc.extension.ext.ExtensionGroup
(*ExtendingMessage)(nil), // 3: goproto.protoc.extension.ext.ExtendingMessage
(*RepeatedGroup)(nil), // 4: goproto.protoc.extension.ext.RepeatedGroup
(*Extendable)(nil), // 5: goproto.protoc.extension.ext.Extendable
(*MessageSetWireFormatExtension)(nil), // 6: goproto.protoc.extension.ext.MessageSetWireFormatExtension
(*Message_M)(nil), // 7: goproto.protoc.extension.ext.Message.M
(*ExtendingMessage_ExtendingMessageSubmessage)(nil), // 8: goproto.protoc.extension.ext.ExtendingMessage.ExtendingMessageSubmessage
(*base.BaseMessage)(nil), // 9: goproto.protoc.extension.base.BaseMessage
(*base.MessageSetWireFormatMessage)(nil), // 10: goproto.protoc.extension.base.MessageSetWireFormatMessage
(*extra.ExtraMessage)(nil), // 11: goproto.protoc.extension.extra.ExtraMessage
}
protogen: use full path for generated file variable name Use the full path (including the extension) for the generation of the per-file variable name. Several reasons for this: * The current logic is buggy in the case where pathType == pathTypeImport since the prefix variable will be mangled with the Go import path. * The extension is technically part of the path. Thus, "path/to/foo.proto" and "path/to/foo.protodevel" are two distinctly different imports. * Style-wise, it subjectively looks better. Rather than being a mixture of camelCase and snake_case, it is all snake_case for the common case: before: ProtoFile_google_protobuf_any after: File_google_protobuf_any_proto * Since the extension is almost always ".proto", this results in a suffix of "_proto", which provides an additional layer of protection against possible name conflicts. The previous approach could possibly have a conflict between "Foo.proto" and a message named ProtoFile with a sub-message called Foo. Also, use the per-file variable name for the raw descriptor variables instead of the hashed version. Change-Id: Ic91e326b7593e5985cee6ececc60539c27fe32fe Reviewed-on: https://go-review.googlesource.com/c/164379 Reviewed-by: Damien Neil <dneil@google.com>
2019-02-27 20:25:51 -08:00
var xxx_File_extensions_ext_ext_proto_depIdxs = []int32{
internal/fileinit: generate reflect data structures from raw descriptors This CL takes a significantly different approach to generating support for protobuf reflection. The previous approach involved generating a large number of Go literals to represent the reflection information. While that approach was correct, it resulted in too much binary bloat. The approach taken here initializes the reflection information from the raw descriptor proto, which is a relatively dense representation of the protobuf reflection information. In order to keep initialization cost low, several measures were taken: * At program init, the bare minimum is parsed in order to initialize naming information for enums, messages, extensions, and services declared in the file. This is done because those top-level declarations are often relevant for registration. * Only upon first are most of the other data structures for protobuf reflection actually initialized. * Instead of using proto.Unmarshal, a hand-written unmarshaler is used. This allows us to avoid a dependendency on the descriptor proto and also because the API for the descriptor proto is fundamentally non-performant since it requires an allocation for every primitive field. At a high-level, the new implementation lives in internal/fileinit. Several changes were made to other parts of the repository: * cmd/protoc-gen-go: * Stop compressing the raw descriptors. While compression does reduce the size of the descriptors by approximately 2x, it is a pre-mature optimization since the descriptors themselves are around 1% of the total binary bloat that is due to generated protobufs. * Seeding protobuf reflection from the raw descriptor significantly simplifies the generator implementation since it is no longer responsible for constructing a tree of Go literals to represent the same information. * We remove the generation of the shadow types and instead call protoimpl.MessageType.MessageOf. Unfortunately, this incurs an allocation for every call to ProtoReflect since we need to allocate a tuple that wraps a pointer to the message value, and a pointer to message type. * internal/impl: * We add a MessageType.GoType field and make it required that it is set prior to first use. This is done so that we can avoid calling MessageType.init except for when it is actually needed. The allows code to call (*FooMessage)(nil).ProtoReflect().Type() without fearing that the init code will run, possibly triggering a recursive deadlock (where the init code depends on getting the Type of some dependency which may be declared within the same file). * internal/cmd/generate-types: * The code to generate reflect/prototype/protofile_list_gen.go was copied and altered to generated internal/fileinit.desc_list_gen.go. At a high-level this CL adds significant technical complexity. However, this is offset by several possible future changes: * The prototype package can be drastically simplified. We can probably reimplement internal/legacy to use internal/fileinit instead, allowing us to drop another dependency on the prototype package. As a result, we can probably delete most of the constructor types in that package. * With the prototype package significantly pruned, and the fact that generated code no longer depend on depends on that package, we can consider merging what's left of prototype into protodesc. Change-Id: I6090f023f2e1b6afaf62bd3ae883566242e30715 Reviewed-on: https://go-review.googlesource.com/c/158539 Reviewed-by: Herbie Ong <herbie@google.com> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-01-18 09:32:24 -08:00
9, // goproto.protoc.extension.ext.extension_bool:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_enum:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_int32:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_sint32:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_uint32:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_int64:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_sint64:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_uint64:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_sfixed32:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_fixed32:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_float:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_sfixed64:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_fixed64:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_double:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_string:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_bytes:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_Message:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extension_MessageM:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extensiongroup:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extra_message:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_bool:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_enum:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_int32:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_sint32:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_uint32:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_int64:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_sint64:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_uint64:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_sfixed32:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_fixed32:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_float:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_sfixed64:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_fixed64:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_double:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_string:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_bytes:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeated_x_Message:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.repeatedgroup:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.extendable_field:extendee -> goproto.protoc.extension.base.BaseMessage
5, // goproto.protoc.extension.ext.extendable_string_field:extendee -> goproto.protoc.extension.ext.Extendable
10, // goproto.protoc.extension.ext.message_set_extension:extendee -> goproto.protoc.extension.base.MessageSetWireFormatMessage
9, // goproto.protoc.extension.ext.ExtendingMessage.extending_message_string:extendee -> goproto.protoc.extension.base.BaseMessage
9, // goproto.protoc.extension.ext.ExtendingMessage.extending_message_submessage:extendee -> goproto.protoc.extension.base.BaseMessage
10, // goproto.protoc.extension.ext.MessageSetWireFormatExtension.message_set_extension:extendee -> goproto.protoc.extension.base.MessageSetWireFormatMessage
0, // goproto.protoc.extension.ext.extension_enum:type_name -> goproto.protoc.extension.ext.Enum
1, // goproto.protoc.extension.ext.extension_Message:type_name -> goproto.protoc.extension.ext.Message
7, // goproto.protoc.extension.ext.extension_MessageM:type_name -> goproto.protoc.extension.ext.Message.M
2, // goproto.protoc.extension.ext.extensiongroup:type_name -> goproto.protoc.extension.ext.ExtensionGroup
11, // goproto.protoc.extension.ext.extra_message:type_name -> goproto.protoc.extension.extra.ExtraMessage
0, // goproto.protoc.extension.ext.repeated_x_enum:type_name -> goproto.protoc.extension.ext.Enum
1, // goproto.protoc.extension.ext.repeated_x_Message:type_name -> goproto.protoc.extension.ext.Message
4, // goproto.protoc.extension.ext.repeatedgroup:type_name -> goproto.protoc.extension.ext.RepeatedGroup
5, // goproto.protoc.extension.ext.extendable_field:type_name -> goproto.protoc.extension.ext.Extendable
6, // goproto.protoc.extension.ext.message_set_extension:type_name -> goproto.protoc.extension.ext.MessageSetWireFormatExtension
8, // goproto.protoc.extension.ext.ExtendingMessage.extending_message_submessage:type_name -> goproto.protoc.extension.ext.ExtendingMessage.ExtendingMessageSubmessage
6, // goproto.protoc.extension.ext.MessageSetWireFormatExtension.message_set_extension:type_name -> goproto.protoc.extension.ext.MessageSetWireFormatExtension
}
cmd/protoc-gen-go: enforce init order within packages Ensure that the init funcs for files within a Go package run in the dependency order of the source .proto files. That is, if a.proto and b.proto are part of the same Go package, and a.proto imports b.proto, then b.pb.go's init funcs must run before a.pb.go's. Change-Id: I0e86ff22e5c4cab9df7a73fe4805390fadd34b0d Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/166419 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-08 17:18:11 -08:00
func init() { xxx_File_extensions_ext_ext_proto_init() }
func xxx_File_extensions_ext_ext_proto_init() {
if File_extensions_ext_ext_proto != nil {
return
}
cmd/protoc-gen-go: change some arrays to slices to save bytes Using arrays in the generated reflection information adds unnecessary eq and hash functions being added to the package. Change to slices to reduce bloat. Change-Id: I1a4f6d59021644d93dd6c24679b9233141e89a75 Reviewed-on: https://go-review.googlesource.com/c/164640 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-03-01 13:22:30 -08:00
extensionTypes := make([]protoreflect.ExtensionType, 44)
protogen: use full path for generated file variable name Use the full path (including the extension) for the generation of the per-file variable name. Several reasons for this: * The current logic is buggy in the case where pathType == pathTypeImport since the prefix variable will be mangled with the Go import path. * The extension is technically part of the path. Thus, "path/to/foo.proto" and "path/to/foo.protodevel" are two distinctly different imports. * Style-wise, it subjectively looks better. Rather than being a mixture of camelCase and snake_case, it is all snake_case for the common case: before: ProtoFile_google_protobuf_any after: File_google_protobuf_any_proto * Since the extension is almost always ".proto", this results in a suffix of "_proto", which provides an additional layer of protection against possible name conflicts. The previous approach could possibly have a conflict between "Foo.proto" and a message named ProtoFile with a sub-message called Foo. Also, use the per-file variable name for the raw descriptor variables instead of the hashed version. Change-Id: Ic91e326b7593e5985cee6ececc60539c27fe32fe Reviewed-on: https://go-review.googlesource.com/c/164379 Reviewed-by: Damien Neil <dneil@google.com>
2019-02-27 20:25:51 -08:00
File_extensions_ext_ext_proto = protoimpl.FileBuilder{
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
RawDescriptor: xxx_File_extensions_ext_ext_proto_rawDesc,
protogen: use full path for generated file variable name Use the full path (including the extension) for the generation of the per-file variable name. Several reasons for this: * The current logic is buggy in the case where pathType == pathTypeImport since the prefix variable will be mangled with the Go import path. * The extension is technically part of the path. Thus, "path/to/foo.proto" and "path/to/foo.protodevel" are two distinctly different imports. * Style-wise, it subjectively looks better. Rather than being a mixture of camelCase and snake_case, it is all snake_case for the common case: before: ProtoFile_google_protobuf_any after: File_google_protobuf_any_proto * Since the extension is almost always ".proto", this results in a suffix of "_proto", which provides an additional layer of protection against possible name conflicts. The previous approach could possibly have a conflict between "Foo.proto" and a message named ProtoFile with a sub-message called Foo. Also, use the per-file variable name for the raw descriptor variables instead of the hashed version. Change-Id: Ic91e326b7593e5985cee6ececc60539c27fe32fe Reviewed-on: https://go-review.googlesource.com/c/164379 Reviewed-by: Damien Neil <dneil@google.com>
2019-02-27 20:25:51 -08:00
GoTypes: xxx_File_extensions_ext_ext_proto_goTypes,
DependencyIndexes: xxx_File_extensions_ext_ext_proto_depIdxs,
cmd/protoc-gen-go: correlate v1 ExtensionDesc with v2 ExtensionType Unfortunately a good amount of code uses pointer comparisons on the v1 ExtensionDesc to determine exactly which extension field is set, rather than checking whether the extension descriptor semantically describes the field that they are interested in. To preserve this behavior in v1, we need a 1:1 mapping between a v2 ExtensionType and a specific v1 ExtensionDesc. Change-Id: I852b3cefb4585bd656e48e5adad6cc28795d02df Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/167759 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-14 16:08:22 -07:00
LegacyExtensions: xxx_File_extensions_ext_ext_proto_extDescs,
cmd/protoc-gen-go: change some arrays to slices to save bytes Using arrays in the generated reflection information adds unnecessary eq and hash functions being added to the package. Change to slices to reduce bloat. Change-Id: I1a4f6d59021644d93dd6c24679b9233141e89a75 Reviewed-on: https://go-review.googlesource.com/c/164640 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-03-01 13:22:30 -08:00
EnumOutputTypes: xxx_File_extensions_ext_ext_proto_enumTypes,
cmd/protoc-gen-go: generate for v2-only dependencies This removes yet another set of dependencies of v2 on v1. The only remaining dependency are in the _test.go files, primarily for proto.Equal. Changes made: * cmd/protoc-gen-go no longer generates any functionality that depends on the v1 package, and instead only depends on v2. * internal/fileinit.FileBuilder.MessageOutputTypes is switched from protoreflect.MessageType to protoimpl.MessageType since the implementation must be fully inialized before registration occurs. * The test for internal/legacy/file_test.go is switched to a legacy_test package to avoid a cyclic dependency. This requires Load{Enum,Message,File}Desc to be exported. Change-Id: I43e2fe64cff4eea204258ce11e791aca5eb6e569 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169298 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-25 14:41:32 -07:00
MessageOutputTypes: xxx_File_extensions_ext_ext_proto_messageTypes,
cmd/protoc-gen-go: change some arrays to slices to save bytes Using arrays in the generated reflection information adds unnecessary eq and hash functions being added to the package. Change to slices to reduce bloat. Change-Id: I1a4f6d59021644d93dd6c24679b9233141e89a75 Reviewed-on: https://go-review.googlesource.com/c/164640 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-03-01 13:22:30 -08:00
ExtensionOutputTypes: extensionTypes,
cmd/protoc-gen-go: generate for v2-only dependencies This removes yet another set of dependencies of v2 on v1. The only remaining dependency are in the _test.go files, primarily for proto.Equal. Changes made: * cmd/protoc-gen-go no longer generates any functionality that depends on the v1 package, and instead only depends on v2. * internal/fileinit.FileBuilder.MessageOutputTypes is switched from protoreflect.MessageType to protoimpl.MessageType since the implementation must be fully inialized before registration occurs. * The test for internal/legacy/file_test.go is switched to a legacy_test package to avoid a cyclic dependency. This requires Load{Enum,Message,File}Desc to be exported. Change-Id: I43e2fe64cff4eea204258ce11e791aca5eb6e569 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169298 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-25 14:41:32 -07:00
FilesRegistry: protoregistry.GlobalFiles,
TypesRegistry: protoregistry.GlobalTypes,
internal/fileinit: generate reflect data structures from raw descriptors This CL takes a significantly different approach to generating support for protobuf reflection. The previous approach involved generating a large number of Go literals to represent the reflection information. While that approach was correct, it resulted in too much binary bloat. The approach taken here initializes the reflection information from the raw descriptor proto, which is a relatively dense representation of the protobuf reflection information. In order to keep initialization cost low, several measures were taken: * At program init, the bare minimum is parsed in order to initialize naming information for enums, messages, extensions, and services declared in the file. This is done because those top-level declarations are often relevant for registration. * Only upon first are most of the other data structures for protobuf reflection actually initialized. * Instead of using proto.Unmarshal, a hand-written unmarshaler is used. This allows us to avoid a dependendency on the descriptor proto and also because the API for the descriptor proto is fundamentally non-performant since it requires an allocation for every primitive field. At a high-level, the new implementation lives in internal/fileinit. Several changes were made to other parts of the repository: * cmd/protoc-gen-go: * Stop compressing the raw descriptors. While compression does reduce the size of the descriptors by approximately 2x, it is a pre-mature optimization since the descriptors themselves are around 1% of the total binary bloat that is due to generated protobufs. * Seeding protobuf reflection from the raw descriptor significantly simplifies the generator implementation since it is no longer responsible for constructing a tree of Go literals to represent the same information. * We remove the generation of the shadow types and instead call protoimpl.MessageType.MessageOf. Unfortunately, this incurs an allocation for every call to ProtoReflect since we need to allocate a tuple that wraps a pointer to the message value, and a pointer to message type. * internal/impl: * We add a MessageType.GoType field and make it required that it is set prior to first use. This is done so that we can avoid calling MessageType.init except for when it is actually needed. The allows code to call (*FooMessage)(nil).ProtoReflect().Type() without fearing that the init code will run, possibly triggering a recursive deadlock (where the init code depends on getting the Type of some dependency which may be declared within the same file). * internal/cmd/generate-types: * The code to generate reflect/prototype/protofile_list_gen.go was copied and altered to generated internal/fileinit.desc_list_gen.go. At a high-level this CL adds significant technical complexity. However, this is offset by several possible future changes: * The prototype package can be drastically simplified. We can probably reimplement internal/legacy to use internal/fileinit instead, allowing us to drop another dependency on the prototype package. As a result, we can probably delete most of the constructor types in that package. * With the prototype package significantly pruned, and the fact that generated code no longer depend on depends on that package, we can consider merging what's left of prototype into protodesc. Change-Id: I6090f023f2e1b6afaf62bd3ae883566242e30715 Reviewed-on: https://go-review.googlesource.com/c/158539 Reviewed-by: Herbie Ong <herbie@google.com> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2019-01-18 09:32:24 -08:00
}.Init()
cmd/protoc-gen-go: lazily GZIP-encode the raw descriptor This reduces the init-time cost slightly since the GZIP'd raw descriptor is constructed lazily on demand. Change-Id: I482c6a2201b8786e425d7dee5612fdfd60ab1500 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/169917 Reviewed-by: Herbie Ong <herbie@google.com>
2019-03-28 01:13:26 -07:00
xxx_File_extensions_ext_ext_proto_rawDesc = nil
protogen: use full path for generated file variable name Use the full path (including the extension) for the generation of the per-file variable name. Several reasons for this: * The current logic is buggy in the case where pathType == pathTypeImport since the prefix variable will be mangled with the Go import path. * The extension is technically part of the path. Thus, "path/to/foo.proto" and "path/to/foo.protodevel" are two distinctly different imports. * Style-wise, it subjectively looks better. Rather than being a mixture of camelCase and snake_case, it is all snake_case for the common case: before: ProtoFile_google_protobuf_any after: File_google_protobuf_any_proto * Since the extension is almost always ".proto", this results in a suffix of "_proto", which provides an additional layer of protection against possible name conflicts. The previous approach could possibly have a conflict between "Foo.proto" and a message named ProtoFile with a sub-message called Foo. Also, use the per-file variable name for the raw descriptor variables instead of the hashed version. Change-Id: Ic91e326b7593e5985cee6ececc60539c27fe32fe Reviewed-on: https://go-review.googlesource.com/c/164379 Reviewed-by: Damien Neil <dneil@google.com>
2019-02-27 20:25:51 -08:00
xxx_File_extensions_ext_ext_proto_goTypes = nil
xxx_File_extensions_ext_ext_proto_depIdxs = nil
cmd/protoc-gen-go: add support for protobuf reflection Implement support in protoc-gen-go for generating messages and enums that satisfy the v2 protobuf reflection interfaces. Specifically, the following are added: * top-level variable representing the file descriptor * ProtoReflect method on enums (to implement protoV2.Enum) * ProtoReflect method on messages (to implement protoV2.Message) The following are not supported yet: * resolving transitive dependencies for file imports * Extension descriptors * Service descriptors The implementation approach creates a single array for all the message and enum declarations and references sections of that array to complete dependencies. Since protobuf declarations can form a graph (a message may depend on itself), it is difficult to construct a graph as a single literal. One way is to use placeholder descriptors, but that is not efficient as it requires encoding the full name of each dependent enum and message and then later resolving it; thus, both expanding the binary size and also increasing initialization cost. Instead, we add a prototype.{Enum,Message}.Reference method to obtain a descriptor reference for the purposes for satisfying dependencies. As such, nested declarations and dependencies are populated in an init function. Other changes to support the implementation: * Added a protoimpl package to expose the MessageType type and also the MessageTypeOf and EnumTypeOf helper functions. * Added a protogen.File.GoIdent field to provide a suggested variable name for the file descriptor. * Added prototype.{Enum,Message}.Reference that provides a descriptor reference for the purposes for satisfying cyclic dependencies. * Added protoreflect.{Syntax,Cardinality,Kind}.GoString to obtain a Go source identifier that represents the given constant. Change-Id: I9455764882dee6ad10f251901e7d419091e8bf1d Reviewed-on: https://go-review.googlesource.com/c/150074 Reviewed-by: Damien Neil <dneil@google.com>
2018-11-15 14:44:37 -08:00
}
Reference in New Issue Copy Permalink