-
Notifications
You must be signed in to change notification settings - Fork 15
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
fix field/method conflict #50
Comments
Getting these warnings now:
7 instances. Is this enough to merit finding another work-around? |
Plus a bunch of errors:
|
Let's reopen this. I think it would be good to do the painful thing and not have to have the warning about fields getting renamed |
If there is a type with a field method conflict, we should do codegen using a struct for the fast refletion wrapper instead of an alias to avoid the field method conflict. Currently we're generating a fast reflection wrapper like this cosmos-proto/testpb/1.pulsar.go Line 263 in 213b768
This causes a field method conflict because type fastReflection_A struct {
a A
} We should only use a struct when there is a conflict, because an alias is more performant otherwise. |
Solve the clashes by introducing a level of indirection, replacing type fastReflection_A A with type fastReflection_A struct { x *A } Updates cosmos#50
Now that fast reflection has struct wrappers, field/method name clashes are no longer possible. Fixes cosmos#50
Given the following proto message type:
We will produce a
Foo.Type
field and aFoo.Type() protoreflect.MessageType
method, this causes code conflicts.If a message uses a reserved name, for the sake of simplicity, we should suffix the field with an underscore
_
.I would also output a warning message that this is bad, and we might break it in the future (reason for breaking is that we are incompatible with protoc field codegen which I do not think is good).
The text was updated successfully, but these errors were encountered: