maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/SemaCXX/cxx11-ast-print.cpp

51 lines
1.6 KiB
C++
Raw Normal View History

AST representation for user-defined literals, plus just enough of semantic analysis to make the AST representation testable. They are represented by a new UserDefinedLiteral AST node, which is a sugared CallExpr. All semantic properties, including full CodeGen support, are achieved for free by this representation. UserDefinedLiterals can never be dependent, so no custom instantiation behavior is required. They are mangled as if they were direct calls to the underlying literal operator. This matches g++'s apparent behavior (but not its actual mangling, which is broken for literal-operator-ids). User-defined *string* literals are now fully-operational, but the semantic analysis is quite hacky and needs more work. No other forms of user-defined literal are created yet, but the AST support for them is present. This patch committed after midnight because we had already hit the quota for new kinds of literal yesterday. llvm-svn: 152211
2012-03-07 16:35:16 +08:00
// RUN: %clang_cc1 -std=c++11 -ast-print %s | FileCheck %s
Teach -ast-print how to print trailing-return-types. llvm-svn: 175864
2013-02-22 13:54:51 +08:00
// CHECK: auto operator "" _foo(const char *p, decltype(sizeof(int))) -> decltype(nullptr);
AST representation for user-defined literals, plus just enough of semantic analysis to make the AST representation testable. They are represented by a new UserDefinedLiteral AST node, which is a sugared CallExpr. All semantic properties, including full CodeGen support, are achieved for free by this representation. UserDefinedLiterals can never be dependent, so no custom instantiation behavior is required. They are mangled as if they were direct calls to the underlying literal operator. This matches g++'s apparent behavior (but not its actual mangling, which is broken for literal-operator-ids). User-defined *string* literals are now fully-operational, but the semantic analysis is quite hacky and needs more work. No other forms of user-defined literal are created yet, but the AST support for them is present. This patch committed after midnight because we had already hit the quota for new kinds of literal yesterday. llvm-svn: 152211
2012-03-07 16:35:16 +08:00
auto operator"" _foo(const char *p, decltype(sizeof(int))) -> decltype(nullptr);
Ensure we don't print 123ULL_foo when printing a user-defined integer literal. llvm-svn: 152303
2012-03-08 17:02:38 +08:00
// CHECK: decltype(""_foo) operator "" _bar(unsigned long long);
decltype(""_foo) operator"" _bar(unsigned long long);
// CHECK: decltype(42_bar) operator "" _baz(long double);
decltype(42_bar) operator"" _baz(long double);
Fix statement printing for raw and template user-defined literals. llvm-svn: 152401
2012-03-09 18:10:02 +08:00
// CHECK: decltype(4.5_baz) operator "" _baz(char);
decltype(4.5_baz) operator"" _baz(char);
// CHECK: const char *operator "" _quux(const char *);
const char *operator"" _quux(const char *);
When pretty-printing a declaration of a pack, put the ellipsis before the name being declared, not at the end. When pretty-printing a non-type template parameter, put the name of the parameter in the middle of the type, not at the end. llvm-svn: 213718
2014-07-23 11:17:06 +08:00
// CHECK: template <char ...> const char *operator "" _fritz();
Fix statement printing for raw and template user-defined literals. llvm-svn: 152401
2012-03-09 18:10:02 +08:00
template<char...> const char *operator"" _fritz();
AST representation for user-defined literals, plus just enough of semantic analysis to make the AST representation testable. They are represented by a new UserDefinedLiteral AST node, which is a sugared CallExpr. All semantic properties, including full CodeGen support, are achieved for free by this representation. UserDefinedLiterals can never be dependent, so no custom instantiation behavior is required. They are mangled as if they were direct calls to the underlying literal operator. This matches g++'s apparent behavior (but not its actual mangling, which is broken for literal-operator-ids). User-defined *string* literals are now fully-operational, but the semantic analysis is quite hacky and needs more work. No other forms of user-defined literal are created yet, but the AST support for them is present. This patch committed after midnight because we had already hit the quota for new kinds of literal yesterday. llvm-svn: 152211
2012-03-07 16:35:16 +08:00
// CHECK: const char *p1 = "bar1"_foo;
const char *p1 = "bar1"_foo;
// CHECK: const char *p2 = "bar2"_foo;
const char *p2 = R"x(bar2)x"_foo;
// CHECK: const char *p3 = u8"bar3"_foo;
const char *p3 = u8"bar3"_foo;
Ensure we don't print 123ULL_foo when printing a user-defined integer literal. llvm-svn: 152303
2012-03-08 17:02:38 +08:00
// CHECK: const char *p4 = 297_bar;
const char *p4 = 0x129_bar;
// CHECK: const char *p5 = 1.0E+12_baz;
const char *p5 = 1e12_baz;
Fix statement printing for raw and template user-defined literals. llvm-svn: 152401
2012-03-09 18:10:02 +08:00
// CHECK: const char *p6 = 'x'_baz;
const char *p6 = 'x'_baz;
// CHECK: const char *p7 = 123_quux;
const char *p7 = 123_quux;
// CHECK: const char *p8 = 4.9_quux;
const char *p8 = 4.9_quux;
// CHECK: const char *p9 = 0x42e3F_fritz;
const char *p9 = 0x42e3F_fritz;
// CHECK: const char *p10 = 3.300e+15_fritz;
const char *p10 = 3.300e+15_fritz;
[AST] String literal operator templates have two template args, not one StmtPrinter assumed that the first template arg was the pack and attempted to iterate it. However, the GNU extension (which is really just N3599), has two template arguments. In this case, the second argument is the pack containing the string contents. Handle this by desugaring the call to the explicit operator. For example: "qux" _zombocom will be shown as operator "" _zombocom<char, 'q', 'u', 'x'>() in diagnostics and AST dumps. N.B. It is actually impossible to render the arguments back to the source form without storing more information in the AST. For example, we cannot tell if the user wrote u8"qux" or "qux". We also lose fidelity when it comes to non-char types for this exact reason (e.g. it is hard to render a list of wchar_t back to something that can be printed to the screen even if you don't have to consider surrogate pairs). This fixes PR23120. llvm-svn: 234110
2015-04-05 13:32:54 +08:00
template <class C, C...> const char *operator"" _suffix();
Switch test from wchar_t to char32_t Windows has a 16-bit wchar_t, most Unix platforms have a 32-bit wchar_t. Use a char32_t to keep the test's output stable. llvm-svn: 234111
2015-04-05 13:42:02 +08:00
// CHECK: const char *PR23120 = operator "" _suffix<char32_t, 66615>();
const char *PR23120 = U"𐐷"_suffix;
[AST] String literal operator templates have two template args, not one StmtPrinter assumed that the first template arg was the pack and attempted to iterate it. However, the GNU extension (which is really just N3599), has two template arguments. In this case, the second argument is the pack containing the string contents. Handle this by desugaring the call to the explicit operator. For example: "qux" _zombocom will be shown as operator "" _zombocom<char, 'q', 'u', 'x'>() in diagnostics and AST dumps. N.B. It is actually impossible to render the arguments back to the source form without storing more information in the AST. For example, we cannot tell if the user wrote u8"qux" or "qux". We also lose fidelity when it comes to non-char types for this exact reason (e.g. it is hard to render a list of wchar_t back to something that can be printed to the screen even if you don't have to consider surrogate pairs). This fixes PR23120. llvm-svn: 234110
2015-04-05 13:32:54 +08:00
[Sema] Semantic analysis for empty-declaration and attribute-declaration. Introduce a new AST Decl node "EmptyDecl" to model empty-declaration. Have attributes from attribute-declaration appertain to the EmptyDecl node by creating the AST representations of these attributes and attach them to the EmptyDecl node so these attributes can be sema checked just as attributes attached to "normal" declarations. llvm-svn: 175900
2013-02-23 01:15:32 +08:00
// CHECK: ;
;
Fix empty declaration printing. Don't print the semicolon when visiting an empty declaration because the semicolon will be printed as a terminator later. llvm-svn: 176035
2013-02-26 02:40:11 +08:00
// CHECK-NOT: ;
In VarDecl nodes, store the thread storage class specifier as written. llvm-svn: 181113
2013-05-04 16:27:07 +08:00