maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/cxx11-user-defined-literal.cpp

70 lines
3.1 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 -triple x86_64-linux-gnu -emit-llvm %s -o - | FileCheck %s
struct S { S(); ~S(); S(const S &); void operator()(int); };
using size_t = decltype(sizeof(int));
S operator"" _x(const char *, size_t);
User-defined literal support for character literals. llvm-svn: 152277
2012-03-08 09:34:56 +08:00
S operator"" _y(wchar_t);
Add support for cooked forms of user-defined-integer-literal and user-defined-floating-literal. Support for raw forms of these literals to follow. llvm-svn: 152302
2012-03-08 16:45:32 +08:00
S operator"" _z(unsigned long long);
S operator"" _f(long double);
Support for raw and template forms of numeric user-defined literals, and lots of tidying up. llvm-svn: 152392
2012-03-09 16:00:36 +08:00
S operator"" _r(const char *);
template<char...Cs> S operator"" _t() { return S(); }
// CHECK: @[[s_foo:.*]] = {{.*}} constant [4 x i8] c"foo\00"
// CHECK: @[[s_bar:.*]] = {{.*}} constant [4 x i8] c"bar\00"
// CHECK: @[[s_123:.*]] = {{.*}} constant [4 x i8] c"123\00"
// CHECK: @[[s_4_9:.*]] = {{.*}} constant [4 x i8] c"4.9\00"
// CHECK: @[[s_0xffffeeee:.*]] = {{.*}} constant [11 x i8] c"0xffffeeee\00"
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
void f() {
[opaque pointer types] Cleanup CGBuilder's Create*GEP. Some of these functions take some extraneous arguments, e.g. EltSize, Offset, which are computable from the Type and DataLayout. Add some asserts to ensure that the computed values are consistent with the passed-in values, in preparation for eliminating the extraneous arguments. This also asserts that the Type is an Array for the calls named "Array" and a Struct for the calls named "Struct". Then, correct a couple of errors: 1. Using CreateStructGEP on an array type. (this causes the majority of the test differences, as struct GEPs are created with i32 indices, while array GEPs are created with i64 indices) 2. Passing the wrong Offset to CreateStructGEP in TargetInfo.cpp on x86-64 NACL (which uses 32-bit pointers). Differential Revision: https://reviews.llvm.org/D57766 llvm-svn: 353529
2019-02-08 23:34:12 +08:00
// CHECK: call void @_Zli2_xPKcm({{.*}}, i8* getelementptr inbounds ([4 x i8], [4 x i8]* @[[s_foo]], i64 0, i64 0), i64 3)
// CHECK: call void @_Zli2_xPKcm({{.*}}, i8* getelementptr inbounds ([4 x i8], [4 x i8]* @[[s_bar]], i64 0, i64 0), i64 3)
User-defined literal support for character literals. llvm-svn: 152277
2012-03-08 09:34:56 +08:00
// CHECK: call void @_Zli2_yw({{.*}} 97)
Add support for cooked forms of user-defined-integer-literal and user-defined-floating-literal. Support for raw forms of these literals to follow. llvm-svn: 152302
2012-03-08 16:45:32 +08:00
// CHECK: call void @_Zli2_zy({{.*}} 42)
// CHECK: call void @_Zli2_fe({{.*}} x86_fp80 0xK3FFF8000000000000000)
Support for raw and template forms of numeric user-defined literals, and lots of tidying up. llvm-svn: 152392
2012-03-09 16:00:36 +08:00
// CHECK: call void @_ZN1SD1Ev({{.*}})
// CHECK: call void @_ZN1SD1Ev({{.*}})
// CHECK: call void @_ZN1SD1Ev({{.*}})
// CHECK: call void @_ZN1SD1Ev({{.*}})
// CHECK: call void @_ZN1SD1Ev({{.*}})
Add support for cooked forms of user-defined-integer-literal and user-defined-floating-literal. Support for raw forms of these literals to follow. llvm-svn: 152302
2012-03-08 16:45:32 +08:00
"foo"_x, "bar"_x, L'a'_y, 42_z, 1.0_f;
Support for raw and template forms of numeric user-defined literals, and lots of tidying up. llvm-svn: 152392
2012-03-09 16:00:36 +08:00
[opaque pointer types] Cleanup CGBuilder's Create*GEP. Some of these functions take some extraneous arguments, e.g. EltSize, Offset, which are computable from the Type and DataLayout. Add some asserts to ensure that the computed values are consistent with the passed-in values, in preparation for eliminating the extraneous arguments. This also asserts that the Type is an Array for the calls named "Array" and a Struct for the calls named "Struct". Then, correct a couple of errors: 1. Using CreateStructGEP on an array type. (this causes the majority of the test differences, as struct GEPs are created with i32 indices, while array GEPs are created with i64 indices) 2. Passing the wrong Offset to CreateStructGEP in TargetInfo.cpp on x86-64 NACL (which uses 32-bit pointers). Differential Revision: https://reviews.llvm.org/D57766 llvm-svn: 353529
2019-02-08 23:34:12 +08:00
// CHECK: call void @_Zli2_rPKc({{.*}}, i8* getelementptr inbounds ([4 x i8], [4 x i8]* @[[s_123]], i64 0, i64 0))
// CHECK: call void @_Zli2_rPKc({{.*}}, i8* getelementptr inbounds ([4 x i8], [4 x i8]* @[[s_4_9]], i64 0, i64 0))
// CHECK: call void @_Zli2_rPKc({{.*}}, i8* getelementptr inbounds ([11 x i8], [11 x i8]* @[[s_0xffffeeee]], i64 0, i64 0))
Support for raw and template forms of numeric user-defined literals, and lots of tidying up. llvm-svn: 152392
2012-03-09 16:00:36 +08:00
// CHECK: call void @_ZN1SD1Ev({{.*}})
// CHECK: call void @_ZN1SD1Ev({{.*}})
// CHECK: call void @_ZN1SD1Ev({{.*}})
123_r, 4.9_r, 0xffff\
eeee_r;
// FIXME: This mangling is insane. Maybe we should have a special case for
// char parameter packs?
// CHECK: call void @_Zli2_tIJLc48ELc120ELc49ELc50ELc51ELc52ELc53ELc54ELc55ELc56EEE1Sv({{.*}})
// CHECK: call void @_ZN1SD1Ev({{.*}})
0x12345678_t;
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
}
Support for raw and template forms of numeric user-defined literals, and lots of tidying up. llvm-svn: 152392
2012-03-09 16:00:36 +08:00
// CHECK: define {{.*}} @_Zli2_tIJLc48ELc120ELc49ELc50ELc51ELc52ELc53ELc54ELc55ELc56EEE1Sv(
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
template<typename T> auto g(T t) -> decltype("foo"_x(t)) { return "foo"_x(t); }
template<typename T> auto i(T t) -> decltype(operator"" _x("foo", 3)(t)) { return operator"" _x("foo", 3)(t); }
void h() {
g(42);
i(42);
}
// CHECK: define {{.*}} @_Z1hv()
// CHECK: call void @_Z1gIiEDTclclL_Zli2_xPKcmELA4_S0_ELm3EEfp_EET_(i32 42)
// CHECK: call void @_Z1iIiEDTclclL_Zli2_xPKcmELA4_S0_ELi3EEfp_EET_(i32 42)
// CHECK: define {{.*}} @_Z1gIiEDTclclL_Zli2_xPKcmELA4_S0_ELm3EEfp_EET_(i32
[opaque pointer types] Cleanup CGBuilder's Create*GEP. Some of these functions take some extraneous arguments, e.g. EltSize, Offset, which are computable from the Type and DataLayout. Add some asserts to ensure that the computed values are consistent with the passed-in values, in preparation for eliminating the extraneous arguments. This also asserts that the Type is an Array for the calls named "Array" and a Struct for the calls named "Struct". Then, correct a couple of errors: 1. Using CreateStructGEP on an array type. (this causes the majority of the test differences, as struct GEPs are created with i32 indices, while array GEPs are created with i64 indices) 2. Passing the wrong Offset to CreateStructGEP in TargetInfo.cpp on x86-64 NACL (which uses 32-bit pointers). Differential Revision: https://reviews.llvm.org/D57766 llvm-svn: 353529
2019-02-08 23:34:12 +08:00
// CHECK: call void @_Zli2_xPKcm({{.*}}, i8* getelementptr inbounds ([4 x i8], [4 x i8]* @{{.*}}, i64 0, i64 0), i64 3)
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: call void @_ZN1SclEi
// CHECK: call void @_ZN1SD1Ev
// CHECK: define {{.*}} @_Z1iIiEDTclclL_Zli2_xPKcmELA4_S0_ELi3EEfp_EET_(i32
[opaque pointer types] Cleanup CGBuilder's Create*GEP. Some of these functions take some extraneous arguments, e.g. EltSize, Offset, which are computable from the Type and DataLayout. Add some asserts to ensure that the computed values are consistent with the passed-in values, in preparation for eliminating the extraneous arguments. This also asserts that the Type is an Array for the calls named "Array" and a Struct for the calls named "Struct". Then, correct a couple of errors: 1. Using CreateStructGEP on an array type. (this causes the majority of the test differences, as struct GEPs are created with i32 indices, while array GEPs are created with i64 indices) 2. Passing the wrong Offset to CreateStructGEP in TargetInfo.cpp on x86-64 NACL (which uses 32-bit pointers). Differential Revision: https://reviews.llvm.org/D57766 llvm-svn: 353529
2019-02-08 23:34:12 +08:00
// CHECK: call void @_Zli2_xPKcm({{.*}}, i8* getelementptr inbounds ([4 x i8], [4 x i8]* @{{.*}}, i64 0, i64 0), i64 3)
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: call void @_ZN1SclEi
// CHECK: call void @_ZN1SD1Ev