Sylwester Lachiewicz created THRIFT-6337:
--------------------------------------------

             Summary: A typedef cycle makes the compiler loop forever instead 
of reporting an error
                 Key: THRIFT-6337
                 URL: https://issues.apache.org/jira/browse/THRIFT-6337
             Project: Thrift
          Issue Type: Bug
          Components: Compiler (General)
    Affects Versions: 0.25.0
            Reporter: Sylwester Lachiewicz


Two typedefs that name each other, both declared before their target is known, 
are accepted by the parser and hang the compiler in 
[t_type::get_true_type|https://github.com/apache/thrift/blob/master/compiler/cpp/src/thrift/parse/parse.cc#L29],
 which follows typedefs until it reaches a non-typedef and never does.

{code}
typedef B A
typedef A B
{code}
{noformat}
$ thrift --gen json repro.thrift
(runs until killed)
{noformat}

Every generator is affected, since all of them call {{get_true_type()}}; a 
struct field using either name is enough to reach it and the two-line file 
above hangs even without one. The parser only catches the case where the first 
name is already defined ({{Type "A" is already defined.}}); a forward reference 
goes through 
[t_typedef::get_type|https://github.com/apache/thrift/blob/master/compiler/cpp/src/thrift/parse/t_typedef.cc#L27],
 which resolves lazily and has no cycle check. The Go front end on the same 
input reports the cycle.

Reproduced on master at 3af0cfff1. Related: 
[THRIFT-6333|https://issues.apache.org/jira/browse/THRIFT-6333] resolves 
forward typedefs at the end of parsing, which is where the cycle can be 
detected.



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

Reply via email to