[
https://issues.apache.org/jira/browse/THRIFT-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18112591#comment-18112591
]
Sylwester Lachiewicz commented on THRIFT-5489:
----------------------------------------------
THRIFT-6197 tracks this together with THRIFT-3037, THRIFT-3491, THRIFT-4901,
THRIFT-5489 and THRIFT-5601. All of them come from the Go generator deciding a
field's type from the typedef instead of from the type it resolves to, and
emitting a typedef of a struct as {{type Alias *Inner}} - a defined type that
carries none of the struct's methods, so the generated package does not compile.
The forward-typedef half reported here is fixed by unwrapping forward typedefs
in a loop that stops at the first declared type, so the field keeps the name
the IDL gave it.
The fix generates a Go type alias ({{type Alias = Inner}}) instead, and is up
for review at https://github.com/apache/thrift/pull/3812
_This comment was created with AI assistance._
> Generated Go Struct Fields Use Underlying Type Instead of Defined Type If
> thrift Typedef Comes After
> ----------------------------------------------------------------------------------------------------
>
> Key: THRIFT-5489
> URL: https://issues.apache.org/jira/browse/THRIFT-5489
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
> Affects Versions: 0.12.0, 0.13.0, 0.14.0, 0.15.0
> Reporter: Das Shuvomay
> Priority: Minor
>
> When a thrift typedef is placed after a struct in which that typedef is used
> for a field, the generated Golang code does not assign the defined type but
> rather the underlying type in its field definition.
>
> Example:
>
> {code:java}
> struct MyFirstStruct {
> 1: required MyTypedef my_typedef;
> }
> typedef i32 MyTypedef;
> struct MySecondStruct {
> 1: required MyTypedef my_typedef;
> } {code}
> Generates the code (with elided parts):
> {code:java}
> type MyTypedef int32
> ...
> // Attributes:
> // - MyTypedef
> type MyFirstStruct struct {
> MyTypedef int32 `thrift:"my_typedef,1,required" db:"my_typedef"
> json:"my_typedef"`
> }
> ...
> // Attributes:
> // - MyTypedef
> type MySecondStruct struct {
> MyTypedef MyTypedef `thrift:"my_typedef,1,required" db:"my_typedef"
> json:"my_typedef"`
> } {code}
> Note how the second struct uses the defined type but the first struct uses
> the underlying type. Since the first struct is able to define the underlying
> type as the type of the field, it's clearly resolving the typedef but not
> using it for some reason.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
