[с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

llvm-project/clang/lib/AST/TextNodeDumper.cpp

Line 245 in b48ebad

OS << "<<<NULL>>>";

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.