You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Yuxuan Wang (Jira)" <ji...@apache.org> on 2022/06/30 22:00:00 UTC

[jira] [Updated] (THRIFT-5601) Typedef after first use causes incorrect go code

     [ https://issues.apache.org/jira/browse/THRIFT-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yuxuan Wang updated THRIFT-5601:
--------------------------------
    Description: 
Currently if a typedef happens after it's first used, the compiler will generate incorrect (uncompilable) go code.

For example, for this thrift file:

 
{code:java}
struct Bar {
  1: optional Foo foo,
}

typedef i32 Foo {code}
The generated go code would be:

 

 
{code:java}
...

type Foo int32

...

type Bar struct {
  Foo *int32 `thrift:"foo,1" db:"foo" json:"foo,omitempty"`
}

...

func (p *Bar)  ReadField1(ctx context.Context, iprot thrift.TProtocol) error {
  if v, err := iprot.ReadI32(ctx); err != nil {
  return thrift.PrependError("error reading field 1: ", err)
} else {          
  temp := Foo(v)
  p.Foo = &temp                     
}
  return nil
}{code}
If we move the typedef to be before it's used, then generated go code would be:

 

 
{code:java}
...
type Bar struct {
  Foo *Foo `thrift:"foo,1" db:"foo" json:"foo,omitempty"`
}
...{code}
instead.

Interestingly the compiler knows that the field should be of type int32 (if we change the typedef to string it would be string instead), so it's not like the compiler don't know about the typedef at all, it's just not using the correct typedef in the go code.

 

  was:
Currently if a typedef happens after it's first used, the compiler will generate incorrect (uncompilable) go code.

For example, for this thrift file:

 
{code:java}
struct Bar {
  1: optional Foo foo,
}typedef i32 Foo {code}
The generated go code would be:

 

 
{code:java}
...

type Foo int32

...

type Bar struct {
  Foo *int32 `thrift:"foo,1" db:"foo" json:"foo,omitempty"`
}

...

func (p *Bar)  ReadField1(ctx context.Context, iprot thrift.TProtocol) error {
  if v, err := iprot.ReadI32(ctx); err != nil {
  return thrift.PrependError("error reading field 1: ", err)
} else {          
  temp := Foo(v)
  p.Foo = &temp                     
}
  return nil
}{code}
If we move the typedef to be before it's used, then generated go code would be:

 

 
{code:java}
...
type Bar struct {
  Foo *Foo `thrift:"foo,1" db:"foo" json:"foo,omitempty"`
}
...{code}
instead.

Interestingly the compiler knows that the field should be of type int32 (if we change the typedef to string it would be string instead), so it's not like the compiler don't know about the typedef at all, it's just not using the correct typedef in the go code.

 


> Typedef after first use causes incorrect go code
> ------------------------------------------------
>
>                 Key: THRIFT-5601
>                 URL: https://issues.apache.org/jira/browse/THRIFT-5601
>             Project: Thrift
>          Issue Type: Bug
>          Components: Go - Compiler
>            Reporter: Yuxuan Wang
>            Priority: Major
>
> Currently if a typedef happens after it's first used, the compiler will generate incorrect (uncompilable) go code.
> For example, for this thrift file:
>  
> {code:java}
> struct Bar {
>   1: optional Foo foo,
> }
> typedef i32 Foo {code}
> The generated go code would be:
>  
>  
> {code:java}
> ...
> type Foo int32
> ...
> type Bar struct {
>   Foo *int32 `thrift:"foo,1" db:"foo" json:"foo,omitempty"`
> }
> ...
> func (p *Bar)  ReadField1(ctx context.Context, iprot thrift.TProtocol) error {
>   if v, err := iprot.ReadI32(ctx); err != nil {
>   return thrift.PrependError("error reading field 1: ", err)
> } else {          
>   temp := Foo(v)
>   p.Foo = &temp                     
> }
>   return nil
> }{code}
> If we move the typedef to be before it's used, then generated go code would be:
>  
>  
> {code:java}
> ...
> type Bar struct {
>   Foo *Foo `thrift:"foo,1" db:"foo" json:"foo,omitempty"`
> }
> ...{code}
> instead.
> Interestingly the compiler knows that the field should be of type int32 (if we change the typedef to string it would be string instead), so it's not like the compiler don't know about the typedef at all, it's just not using the correct typedef in the go code.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)