protobuf: compiler/protogen: Go name conflicts can occur for non-style compliant protobuf names

What version of protobuf and what language are you using? // protoc-gen-go v1.25.0-devel // protoc v3.12.4

What did you do?

Tried to generate this file.

syntax = "proto3";
package hello;
option go_package=".;hello";


message myMessage {
  string myField = 1;
}

message my_Message {
  string my_Field = 1;
}

message my_message {
  string my_field = 1;
}

message MyMessage {
  string MyField = 1;
}

message My_Message {
  string My_Field = 1;
}

message My_message {
  string My_field = 1;
}

What did you expect to see? Some solution on how protoc-gen-go resolves/avoids conflict in name conversion.

What did you see instead?

proto message name	go struct name
myMessage	MyMessage
MyMessage	MyMessage
my_message	MyMessage
My_message	MyMessage
my_Message	My_Message
My_Message	My_Message

Anything else we should know about your project / environment?

Twirp is trying to resolve naming convention issues in go. Specifically, how to handle service and method names that begin with a lower case letter. What should they do if it happens to conflict with another method or service. https://github.com/twitchtv/twirp/pull/269

I figured this project would’ve probably solved this issue with message names. Sadly. it does not.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 17 (7 by maintainers)

Most upvoted comments

Codebases with multiple languages usually have a centralised step to generate code in multiple languages from proto files.

Right now, the code gen succeeds and breaks during import. Failing at build time will prevent such code from being released at all.

As an example, think of places where services are in other languages but also have generated go clients etc. They would release a new service before ever realising that the generated code will break in go.

The most common case I can think of is when people are switching from non-compliant code to compliant one.

Can you explain how that’s better UX

Failing at build time and printing the error with a documentation link which explains this gotcha is much better than leaving people in the dark to discover on their own.

The crux is that a build time error would avoid a lot of work later.

ofpiyush on Sep 23, 2020

That’s 100LOC to maintain for slightly better UX

I figured a better 2 LOC check.

conf := &types.Config{Importer: importer.Default()}
_, err = conf.Check("", fset, []*ast.File{fileAST}, nil)

Is it worth it now?

ofpiyush on Sep 23, 2020

The world already breaks when those failures happen. It just breaks when the program compiles instead of code generation.

The code breaks if you add another non-compliant name that results in a conflict. That’s very different from breaking the code the moment if any non-style compliant name is used.

I should also note that style enforcement is not the responsibility of protoc-gen-go. Personally, I support such a notion, but this is something that should be discussed at the main protocol buffer project and be implemented in protoc.

dsnet on Sep 22, 2020