Closed Sivys closed 9 months ago
This looks like a bug in "github.com/bufbuild/protocompile/parser"
.
If I parse your .proto
file with protoc
, I get:
name: "test.proto"
package: "test"
message_type: {
name: "Foo"
field: {
name: "Bar"
number: 1
label: LABEL_REPEATED
type: TYPE_MESSAGE
type_name: ".test.Foo.BarEntry"
json_name: "Bar"
}
nested_type: {
name: "BarEntry"
field: {
name: "key"
number: 1
label: LABEL_OPTIONAL
type: TYPE_INT32
json_name: "key"
}
field: {
name: "value"
number: 2
label: LABEL_OPTIONAL
type: TYPE_MESSAGE
type_name: ".test.Bar"
json_name: "value"
}
options: {
map_entry: true
}
}
}
message_type: {
name: "Bar"
field: {
name: "integer"
number: 1
label: LABEL_OPTIONAL
type: TYPE_INT32
json_name: "integer"
}
}
syntax: "proto3"
If I parse it with the bufbuild parser:
name: "test.proto"
package: "test"
message_type: {
name: "Foo"
field: {
name: "Bar"
number: 1
label: LABEL_REPEATED
type_name: "BarEntry"
json_name: "Bar"
}
nested_type: {
name: "BarEntry"
field: {
name: "key"
number: 1
label: LABEL_OPTIONAL
type: TYPE_INT32
json_name: "key"
}
field: {
name: "value"
number: 2
label: LABEL_OPTIONAL
type_name: "Bar"
json_name: "value"
}
options: {
map_entry: true
}
}
}
message_type: {
name: "Bar"
field: {
name: "integer"
number: 1
label: LABEL_OPTIONAL
type: TYPE_INT32
json_name: "integer"
}
}
syntax: "proto3"
The message-valued fields are missing type: TYPE_MESSAGE
, and (the source of your error) do not use fully qualified names in the type_name
field.
This looks like a bug in
"github.com/bufbuild/protocompile/parser"
.If I parse your
.proto
file withprotoc
, I get:name: "test.proto" package: "test" message_type: { name: "Foo" field: { name: "Bar" number: 1 label: LABEL_REPEATED type: TYPE_MESSAGE type_name: ".test.Foo.BarEntry" json_name: "Bar" } nested_type: { name: "BarEntry" field: { name: "key" number: 1 label: LABEL_OPTIONAL type: TYPE_INT32 json_name: "key" } field: { name: "value" number: 2 label: LABEL_OPTIONAL type: TYPE_MESSAGE type_name: ".test.Bar" json_name: "value" } options: { map_entry: true } } } message_type: { name: "Bar" field: { name: "integer" number: 1 label: LABEL_OPTIONAL type: TYPE_INT32 json_name: "integer" } } syntax: "proto3"
If I parse it with the bufbuild parser:
name: "test.proto" package: "test" message_type: { name: "Foo" field: { name: "Bar" number: 1 label: LABEL_REPEATED type_name: "BarEntry" json_name: "Bar" } nested_type: { name: "BarEntry" field: { name: "key" number: 1 label: LABEL_OPTIONAL type: TYPE_INT32 json_name: "key" } field: { name: "value" number: 2 label: LABEL_OPTIONAL type_name: "Bar" json_name: "value" } options: { map_entry: true } } } message_type: { name: "Bar" field: { name: "integer" number: 1 label: LABEL_OPTIONAL type: TYPE_INT32 json_name: "integer" } } syntax: "proto3"
The message-valued fields are missing
type: TYPE_MESSAGE
, and (the source of your error) do not use fully qualified names in thetype_name
field.
my bad, i thought github.com/bufbuild/protocompile/parser
is a official package
What version of protobuf and what language are you using? Version: protobuf version:
google.golang.org/protobuf@v1.31.0
golang version: all versionWhat did you do? Here is my code, I want directly compile and register protobuf from a proto file to protoregistry
but the
NewFile
returns an errorso I try to find out what's going on, finally find out that at [HERE](https://github.com/protocolbuffers/protobuf-go/blob/8088bf85b8fc5a6c0d7e2a39743e237cae8bef99/reflect/protodesc/desc_resolve.go#L126)
the type of
d
isfiledesc.Field
which I think it should befiledesc.Message
so I printed out all descriptors that registered into
descsByName
at [HERE](https://github.com/protocolbuffers/protobuf-go/blob/8088bf85b8fc5a6c0d7e2a39743e237cae8bef99/reflect/protodesc/desc_init.go#L236), it showsthe [function](https://github.com/protocolbuffers/protobuf-go/blob/8088bf85b8fc5a6c0d7e2a39743e237cae8bef99/reflect/protodesc/desc_resolve.go#L161)
findDescriptor
will search descriptors from bottom to top, in this case it will stop attest.Foo.Bar
nottest.Bar
which caused the error aboveWhat did you expect to see?
I know it's bad to name a field like that, since my syntax is valid in proto file and the file can be processed by protoc correctly and generated the right pb code, so I think the
protobuf
lib should performance the same too?What did you see instead?
It can not process the file correctly and returns me an error
Anything else we should know about your project / environment?
no