Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

namespace resolution different from protoc behavior #314

Closed
eyalpost opened this issue May 2, 2021 · 4 comments · Fixed by jhump/protoreflect#393, #327 or #333
Closed

namespace resolution different from protoc behavior #314

eyalpost opened this issue May 2, 2021 · 4 comments · Fixed by jhump/protoreflect#393, #327 or #333
Labels
Bug Something isn't working

Comments

@eyalpost
Copy link

eyalpost commented May 2, 2021

Consider the following proto:

syntax = "proto3";

package com.google;

import "google/protobuf/wrappers.proto";

message Msg {
  google.protobuf.StringValue str = 1;
}

Note that this proto package is com.google and the imported package is google.protobuf.
When using the type google.protobuf.StringValue, according to protobuf namespace resolution rules, it should look for the StringValue type inside com.google.protobuf. This means the above proto file should fail in protoc and indeed it fails with the following message:

protoc service.proto -o /dev/null
service.proto:8:3: "google.protobuf.StringValue" is resolved to "com.google.protobuf.StringValue", 
  which is not defined.
The innermost scope is searched first in name resolution. 
Consider using a leading '.'(i.e., ".google.protobuf.StringValue") to start from the outermost scope

)
In order to fix this, I need to use .google.protobuf.StringValue str = 1; (notice that dot prefix)

The problem is that buf, on the other hand, considers the above to be correct in both cases (with or without a leading .):

buf protoc service.proto -o -#format=json
{"file":[{"name":"service.proto","package":"com.google","dependency":["google/protobuf/wrappers.proto"],"messageType":[{"name":"Msg","field":[{"name":"str","number":1,"label":"LABEL_OPTIONAL","type":"TYPE_MESSAGE","typeName":".google.protobuf.StringValue","jsonName":"str"}]}],"syntax":"proto3"}]}

(notice how the typename is resolved to .google.protobuf.StringValue)

Important: This is not an edge case caused by the usage of google in package com.google.
It's an issue with namespace resolution that could occur also if the file was in com.xyz and there was another file with package xyz.something.else

@bufdev bufdev added Bug Something isn't working P1 labels May 6, 2021
@bufdev
Copy link
Member

bufdev commented May 6, 2021

Just an update: we're working on it :-)

@bufdev
Copy link
Member

bufdev commented May 27, 2021

This is fixed and will go out in the next release. Thanks for reporting the issue!

@bufdev bufdev reopened this May 28, 2021
@bufdev
Copy link
Member

bufdev commented May 28, 2021

We had to revert the fix for this as it caused a different bug - we'll get that fixed, and then re-add this in a new release, our apologies.

@bufdev
Copy link
Member

bufdev commented May 31, 2021

This should be fixed now in 0.43.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working
2 participants