mirror of
https://github.com/llvm/llvm-project.git
synced 2025-04-17 07:06:42 +00:00
3132e9cd7c
After this, NUMERIC_CONSTANT and strings should parse only one way. There are 8 types of literals, and 24 valid (literal, TokenKind) pairs. This means adding 8 new named guards (or 24, if we want to assert the token). It seems fairly clear to me at this point that the guard names are unneccesary indirection: the guards are in fact coupled to the rule signature. (Also add the zero guard I forgot in the previous patch.) Differential Revision: https://reviews.llvm.org/D130066
28 lines
1.3 KiB
C++
28 lines
1.3 KiB
C++
// RUN: clang-pseudo -grammar=cxx -source=%s --print-forest | FileCheck %s
|
|
// FIXME: tighten CHECK to CHECK-NEXT once numeric literals are unambiguous.
|
|
auto x = { 1, .f = 2, [c]{3} };
|
|
// CHECK: initializer-clause~braced-init-list
|
|
// CHECK-NEXT: ├─{ := tok[3]
|
|
// CHECK-NEXT: ├─initializer-list
|
|
// CHECK-NEXT: │ ├─initializer-list
|
|
// CHECK-NEXT: │ │ ├─initializer-list~NUMERIC_CONSTANT
|
|
// CHECK-NEXT: │ │ ├─, := tok[5]
|
|
// CHECK-NEXT: │ │ └─initializer-list-item
|
|
// CHECK-NEXT: │ │ ├─designator
|
|
// CHECK-NEXT: │ │ │ ├─. := tok[6]
|
|
// CHECK-NEXT: │ │ │ └─IDENTIFIER := tok[7]
|
|
// CHECK-NEXT: │ │ └─brace-or-equal-initializer
|
|
// CHECK-NEXT: │ │ ├─= := tok[8]
|
|
// CHECK-NEXT: │ │ └─initializer-clause~NUMERIC_CONSTANT
|
|
// CHECK-NEXT: │ ├─, := tok[10]
|
|
// CHECK-NEXT: │ └─initializer-list-item
|
|
// CHECK-NEXT: │ ├─designator
|
|
// CHECK-NEXT: │ │ ├─[ := tok[11]
|
|
// CHECK-NEXT: │ │ ├─expression~IDENTIFIER := tok[12]
|
|
// CHECK-NEXT: │ │ └─] := tok[13]
|
|
// CHECK-NEXT: │ └─brace-or-equal-initializer~braced-init-list
|
|
// CHECK-NEXT: │ ├─{ := tok[14]
|
|
// CHECK-NEXT: │ ├─initializer-list~NUMERIC_CONSTANT
|
|
// CHECK: │ └─} := tok[16]
|
|
// CHECK-NEXT: └─} := tok[17]
|