[
https://issues.apache.org/jira/browse/THRIFT-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18112230#comment-18112230
]
Sylwester Lachiewicz commented on THRIFT-5489:
----------------------------------------------
Still reproducible with the 0.24.0 compiler. THRIFT-6197 collects this and four
sibling reports under the one root cause in the Go generator, with the IDL and
the exact compiler errors for a typedef declared after use, a typedef of a
struct, and a typedef of a struct from an included file. Leaving this issue
open; a fix for THRIFT-6197 should close it.
> 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)
