mirror/protobuf-go
1
0
Fork 0
mirror of https://github.com/protocolbuffers/protobuf-go.git synced 2025-01-01 11:58:21 +00:00
Code Issues Packages Projects Releases Wiki Activity
559d47f1da
protobuf-go/cmd/protoc-gen-go/testdata/issue780_oneof_conflict/test.pb.go

127 lines
4.4 KiB
Go
Raw Normal View History

protogen: fix oneof name mangling regression The generator currently uses an unintuitive and stateful algorithm for name generation where it "fixes" name conflicts by appending "_" to the end of the new name. PR#657 refactored the generator code and noticed that the above algorithm was not properly taking into account that a Get method is generated for parent oneofs, fixing it in the same PR. While this is more correct, this breaks users (see #780) since it means that the generation of names can change. This PR changes the name mangling logic to be as it was previously. This does mean that some new proto files may be unbuildable, but that is arguably better than breaking existing proto files Change-Id: I2e354f4bb5d9c2b562fa2faa9149e949e2d86a0f Reviewed-on: https://go-review.googlesource.com/c/156877 Reviewed-by: Damien Neil <dneil@google.com>
2019-01-08 18:59:34 +00:00
// Code generated by protoc-gen-go. DO NOT EDIT.
// source: issue780_oneof_conflict/test.proto
package oneoftest
import (
proto "github.com/golang/protobuf/proto"
protoreflect "github.com/golang/protobuf/v2/reflect/protoreflect"
protoimpl "github.com/golang/protobuf/v2/runtime/protoimpl"
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 17:32:24 +00:00
reflect "reflect"
protogen: fix oneof name mangling regression The generator currently uses an unintuitive and stateful algorithm for name generation where it "fixes" name conflicts by appending "_" to the end of the new name. PR#657 refactored the generator code and noticed that the above algorithm was not properly taking into account that a Get method is generated for parent oneofs, fixing it in the same PR. While this is more correct, this breaks users (see #780) since it means that the generation of names can change. This PR changes the name mangling logic to be as it was previously. This does mean that some new proto files may be unbuildable, but that is arguably better than breaking existing proto files Change-Id: I2e354f4bb5d9c2b562fa2faa9149e949e2d86a0f Reviewed-on: https://go-review.googlesource.com/c/156877 Reviewed-by: Damien Neil <dneil@google.com>
2019-01-08 18:59:34 +00:00
)
type Foo struct {
// Types that are valid to be assigned to Bar:
// *Foo_GetBar
Bar isFoo_Bar `protobuf_oneof:"bar"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_unrecognized []byte `json:"-"`
XXX_sizecache int32 `json:"-"`
}
func (m *Foo) ProtoReflect() protoreflect.Message {
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-28 04:25:51 +00:00
return xxx_File_issue780_oneof_conflict_test_proto_messageTypes[0].MessageOf(m)
protogen: fix oneof name mangling regression The generator currently uses an unintuitive and stateful algorithm for name generation where it "fixes" name conflicts by appending "_" to the end of the new name. PR#657 refactored the generator code and noticed that the above algorithm was not properly taking into account that a Get method is generated for parent oneofs, fixing it in the same PR. While this is more correct, this breaks users (see #780) since it means that the generation of names can change. This PR changes the name mangling logic to be as it was previously. This does mean that some new proto files may be unbuildable, but that is arguably better than breaking existing proto files Change-Id: I2e354f4bb5d9c2b562fa2faa9149e949e2d86a0f Reviewed-on: https://go-review.googlesource.com/c/156877 Reviewed-by: Damien Neil <dneil@google.com>
2019-01-08 18:59:34 +00:00
}
func (m *Foo) Reset() { *m = Foo{} }
func (m *Foo) String() string { return proto.CompactTextString(m) }
func (*Foo) 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 07:05:34 +00:00
// Deprecated: Use Foo.ProtoReflect.Type instead.
protogen: fix oneof name mangling regression The generator currently uses an unintuitive and stateful algorithm for name generation where it "fixes" name conflicts by appending "_" to the end of the new name. PR#657 refactored the generator code and noticed that the above algorithm was not properly taking into account that a Get method is generated for parent oneofs, fixing it in the same PR. While this is more correct, this breaks users (see #780) since it means that the generation of names can change. This PR changes the name mangling logic to be as it was previously. This does mean that some new proto files may be unbuildable, but that is arguably better than breaking existing proto files Change-Id: I2e354f4bb5d9c2b562fa2faa9149e949e2d86a0f Reviewed-on: https://go-review.googlesource.com/c/156877 Reviewed-by: Damien Neil <dneil@google.com>
2019-01-08 18:59:34 +00:00
func (*Foo) Descriptor() ([]byte, []int) {
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-28 04:25:51 +00:00
return xxx_File_issue780_oneof_conflict_test_proto_rawdesc_gzipped, []int{0}
protogen: fix oneof name mangling regression The generator currently uses an unintuitive and stateful algorithm for name generation where it "fixes" name conflicts by appending "_" to the end of the new name. PR#657 refactored the generator code and noticed that the above algorithm was not properly taking into account that a Get method is generated for parent oneofs, fixing it in the same PR. While this is more correct, this breaks users (see #780) since it means that the generation of names can change. This PR changes the name mangling logic to be as it was previously. This does mean that some new proto files may be unbuildable, but that is arguably better than breaking existing proto files Change-Id: I2e354f4bb5d9c2b562fa2faa9149e949e2d86a0f Reviewed-on: https://go-review.googlesource.com/c/156877 Reviewed-by: Damien Neil <dneil@google.com>
2019-01-08 18:59:34 +00:00
}
func (m *Foo) XXX_Unmarshal(b []byte) error {
return xxx_messageInfo_Foo.Unmarshal(m, b)
}
func (m *Foo) XXX_Marshal(b []byte, deterministic bool) ([]byte, error) {
return xxx_messageInfo_Foo.Marshal(b, m, deterministic)
}
func (m *Foo) XXX_Merge(src proto.Message) {
xxx_messageInfo_Foo.Merge(m, src)
}
func (m *Foo) XXX_Size() int {
return xxx_messageInfo_Foo.Size(m)
}
func (m *Foo) XXX_DiscardUnknown() {
xxx_messageInfo_Foo.DiscardUnknown(m)
}
var xxx_messageInfo_Foo proto.InternalMessageInfo
type isFoo_Bar interface {
isFoo_Bar()
}
type Foo_GetBar struct {
GetBar string `protobuf:"bytes,1,opt,name=get_bar,json=getBar,oneof"`
}
func (*Foo_GetBar) isFoo_Bar() {}
func (m *Foo) GetBar() isFoo_Bar {
if m != nil {
return m.Bar
}
return nil
}
func (m *Foo) GetGetBar() string {
if x, ok := m.GetBar().(*Foo_GetBar); ok {
return x.GetBar
}
return ""
}
// XXX_OneofWrappers is for the internal use of the proto package.
func (*Foo) XXX_OneofWrappers() []interface{} {
return []interface{}{
(*Foo_GetBar)(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-28 04:25:51 +00:00
var xxx_File_issue780_oneof_conflict_test_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 17:32:24 +00:00
// 88 bytes of the wire-encoded FileDescriptorProto
0x0a, 0x22, 0x69, 0x73, 0x73, 0x75, 0x65, 0x37, 0x38, 0x30, 0x5f, 0x6f, 0x6e, 0x65, 0x6f, 0x66,
0x5f, 0x63, 0x6f, 0x6e, 0x66, 0x6c, 0x69, 0x63, 0x74, 0x2f, 0x74, 0x65, 0x73, 0x74, 0x2e, 0x70,
0x72, 0x6f, 0x74, 0x6f, 0x12, 0x09, 0x6f, 0x6e, 0x65, 0x6f, 0x66, 0x74, 0x65, 0x73, 0x74, 0x22,
0x27, 0x0a, 0x03, 0x46, 0x6f, 0x6f, 0x12, 0x19, 0x0a, 0x07, 0x67, 0x65, 0x74, 0x5f, 0x62, 0x61,
0x72, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x48, 0x00, 0x52, 0x06, 0x67, 0x65, 0x74, 0x42, 0x61,
0x72, 0x42, 0x05, 0x0a, 0x03, 0x62, 0x61, 0x72,
}
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 07:05:34 +00:00
var xxx_File_issue780_oneof_conflict_test_proto_rawdesc_gzipped = protoimpl.X.CompressGZIP(xxx_File_issue780_oneof_conflict_test_proto_rawdesc)
protogen: fix oneof name mangling regression The generator currently uses an unintuitive and stateful algorithm for name generation where it "fixes" name conflicts by appending "_" to the end of the new name. PR#657 refactored the generator code and noticed that the above algorithm was not properly taking into account that a Get method is generated for parent oneofs, fixing it in the same PR. While this is more correct, this breaks users (see #780) since it means that the generation of names can change. This PR changes the name mangling logic to be as it was previously. This does mean that some new proto files may be unbuildable, but that is arguably better than breaking existing proto files Change-Id: I2e354f4bb5d9c2b562fa2faa9149e949e2d86a0f Reviewed-on: https://go-review.googlesource.com/c/156877 Reviewed-by: Damien Neil <dneil@google.com>
2019-01-08 18:59:34 +00:00
const _ = protoimpl.EnforceVersion(protoimpl.Version - 0)
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-28 04:25:51 +00:00
var File_issue780_oneof_conflict_test_proto protoreflect.FileDescriptor
protogen: fix oneof name mangling regression The generator currently uses an unintuitive and stateful algorithm for name generation where it "fixes" name conflicts by appending "_" to the end of the new name. PR#657 refactored the generator code and noticed that the above algorithm was not properly taking into account that a Get method is generated for parent oneofs, fixing it in the same PR. While this is more correct, this breaks users (see #780) since it means that the generation of names can change. This PR changes the name mangling logic to be as it was previously. This does mean that some new proto files may be unbuildable, but that is arguably better than breaking existing proto files Change-Id: I2e354f4bb5d9c2b562fa2faa9149e949e2d86a0f Reviewed-on: https://go-review.googlesource.com/c/156877 Reviewed-by: Damien Neil <dneil@google.com>
2019-01-08 18:59:34 +00: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 21:22:30 +00:00
var xxx_File_issue780_oneof_conflict_test_proto_messageTypes = make([]protoimpl.MessageType, 1)
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-28 04:25:51 +00:00
var xxx_File_issue780_oneof_conflict_test_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 17:32:24 +00:00
(*Foo)(nil), // 0: oneoftest.Foo
}
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-28 04:25:51 +00:00
var xxx_File_issue780_oneof_conflict_test_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 17:32:24 +00:00
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-09 01:18:11 +00:00
func init() { xxx_File_issue780_oneof_conflict_test_proto_init() }
func xxx_File_issue780_oneof_conflict_test_proto_init() {
if File_issue780_oneof_conflict_test_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 21:22:30 +00:00
messageTypes := make([]protoreflect.MessageType, 1)
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-28 04:25:51 +00:00
File_issue780_oneof_conflict_test_proto = protoimpl.FileBuilder{
RawDescriptor: xxx_File_issue780_oneof_conflict_test_proto_rawdesc,
GoTypes: xxx_File_issue780_oneof_conflict_test_proto_goTypes,
DependencyIndexes: xxx_File_issue780_oneof_conflict_test_proto_depIdxs,
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 21:22:30 +00:00
MessageOutputTypes: messageTypes,
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 17:32:24 +00:00
}.Init()
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-28 04:25:51 +00:00
messageGoTypes := xxx_File_issue780_oneof_conflict_test_proto_goTypes[0:][:1]
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 21:22:30 +00:00
for i, mt := range messageTypes {
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-28 04:25:51 +00:00
xxx_File_issue780_oneof_conflict_test_proto_messageTypes[i].GoType = reflect.TypeOf(messageGoTypes[i])
xxx_File_issue780_oneof_conflict_test_proto_messageTypes[i].PBType = mt
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 17:32:24 +00:00
}
cmd/protoc-gen-go: fix init order for v1 registration The v1 registration leaks the message types out to the proto package. When doing that, it must ensure that the reflection data structures for those types are properly initialized first. We achieve that by doing v1 registration at the end of the reflection init function. Change-Id: If6df18df59d05bad50ff39c2eff6beb19e7466cc Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/168348 Reviewed-by: Damien Neil <dneil@google.com>
2019-03-20 01:21:47 +00:00
proto.RegisterFile("issue780_oneof_conflict/test.proto", xxx_File_issue780_oneof_conflict_test_proto_rawdesc_gzipped)
proto.RegisterType((*Foo)(nil), "oneoftest.Foo")
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-28 04:25:51 +00:00
xxx_File_issue780_oneof_conflict_test_proto_goTypes = nil
xxx_File_issue780_oneof_conflict_test_proto_depIdxs = nil
protogen: fix oneof name mangling regression The generator currently uses an unintuitive and stateful algorithm for name generation where it "fixes" name conflicts by appending "_" to the end of the new name. PR#657 refactored the generator code and noticed that the above algorithm was not properly taking into account that a Get method is generated for parent oneofs, fixing it in the same PR. While this is more correct, this breaks users (see #780) since it means that the generation of names can change. This PR changes the name mangling logic to be as it was previously. This does mean that some new proto files may be unbuildable, but that is arguably better than breaking existing proto files Change-Id: I2e354f4bb5d9c2b562fa2faa9149e949e2d86a0f Reviewed-on: https://go-review.googlesource.com/c/156877 Reviewed-by: Damien Neil <dneil@google.com>
2019-01-08 18:59:34 +00:00
}
Reference in New Issue Copy Permalink