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)