namespace resolution different from protoc behavior

[eyalpost]

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]

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

[bufdev]

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

[bufdev]

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]

This should be fixed now in 0.43.2.