[сlang] Representation of ellipsis in AST

[Endilll]

Consider the following snippet with different usages of ellipsis:

void foo() {
  try {}
  catch(...){} // #1
}

void bar(int, ...); // #2

clang -Xclang -ast-dump outputs the following (omitting built-in typedefs):

TranslationUnitDecl
|-FunctionDecl <line:1:1, line:4:1> line:1:6 foo 'void ()'
| `-CompoundStmt <col:12, line:4:1>
|   `-CXXTryStmt <line:2:3, line:3:14>
|     |-CompoundStmt <line:2:7, col:8>
|     `-CXXCatchStmt <line:3:3, col:14>
|       |-<<<NULL>>>
|       `-CompoundStmt <col:13, col:14>
`-FunctionDecl <line:6:1, col:18> col:6 bar 'void (int, ...)'
  `-ParmVarDecl <col:10> col:13 'int'

The first ellipsis (catch-all) is represented by <<<NULL>>> which comes from https://github.com/llvm/llvm-project/blob/b48ebad561dbbaddd989de3e9509253247dbf4b2/clang/lib/AST/TextNodeDumper.cpp#L245

The second ellipsis (vararg) is not represented at all. Are those representations (or lack of thereof) by design? Is this inconsistency intentional? https://godbolt.org/z/EafKE5KWs

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[AaronBallman]

I believe the null pointers are by design, but I don't think that design is a particularly good one. For example, having NULL pointer child nodes in the AST makes it harder to write a correct recursive AST visitor because you have to watch out for instances where NULL occurs with special meaning. I think it would be better to use a concrete AST node instead of an in-band indicator.

[shahidiqbal13]

Hi @Endilll, @AaronBallman Can anyone of you assign this task to me so that I could work

[Endilll]

@shahidiqbal13 Sure! But assignment is not formal or binding in any way: everyone can work on anything they want in LLVM project.