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/lambda-expressions.cpp

79 lines
2.2 KiB
C++
Raw Normal View History

Add a coverage test for lambda expression IRGen. llvm-svn: 150458
2012-02-14 11:07:59 +08:00
// RUN: %clang_cc1 -triple x86_64-apple-darwin10.0.0 -emit-llvm -o - %s -fexceptions -std=c++11 | FileCheck %s
When we resolve the type of an 'auto' variable, clear out the linkage of that variable; it will need to be recomputed with the resolved type. llvm-svn: 150984
2012-02-21 04:05:29 +08:00
// CHECK: @var = internal global
auto var = [](int i) { return i+1; };
Make sure that we set up the right declaration contexts when creating and introducing the lambda closure type and its function call operator. Previously, we assumed that the lambda closure type would land directly in the current context, and not some parent context (as occurs with linkage specifications). Thanks to Richard for the test case. llvm-svn: 150987
2012-02-21 04:47:06 +08:00
// CHECK: @cvar = global
extern "C" auto cvar = []{};
Add a coverage test for lambda expression IRGen. llvm-svn: 150458
2012-02-14 11:07:59 +08:00
int a() { return []{ return 1; }(); }
// CHECK: define i32 @_Z1av
Basic support for name mangling of C++11 lambda expressions. Because name mangling in the Itanium C++ ABI for lambda expressions is so dependent on context, we encode the number used to encode each lambda as part of the lambda closure type, and maintain this value within Sema. Note that there are a several pieces still missing: - We still get the linkage of lambda expressions wrong - We aren't properly numbering or mangling lambda expressions that occur in default function arguments or in data member initializers. - We aren't (de-)serializing the lambda numbering tables llvm-svn: 150982
2012-02-21 03:44:39 +08:00
// CHECK: call i32 @_ZZ1avENKUlvE_clEv
// CHECK: define internal i32 @_ZZ1avENKUlvE_clEv
Add a coverage test for lambda expression IRGen. llvm-svn: 150458
2012-02-14 11:07:59 +08:00
// CHECK: ret i32 1
int b(int x) { return [x]{return x;}(); }
// CHECK: define i32 @_Z1bi
// CHECK: store i32
// CHECK: load i32*
// CHECK: store i32
Basic support for name mangling of C++11 lambda expressions. Because name mangling in the Itanium C++ ABI for lambda expressions is so dependent on context, we encode the number used to encode each lambda as part of the lambda closure type, and maintain this value within Sema. Note that there are a several pieces still missing: - We still get the linkage of lambda expressions wrong - We aren't properly numbering or mangling lambda expressions that occur in default function arguments or in data member initializers. - We aren't (de-)serializing the lambda numbering tables llvm-svn: 150982
2012-02-21 03:44:39 +08:00
// CHECK: call i32 @_ZZ1biENKUlvE_clEv
// CHECK: define internal i32 @_ZZ1biENKUlvE_clEv
Add a coverage test for lambda expression IRGen. llvm-svn: 150458
2012-02-14 11:07:59 +08:00
// CHECK: load i32*
// CHECK: ret i32
int c(int x) { return [&x]{return x;}(); }
// CHECK: define i32 @_Z1ci
// CHECK: store i32
// CHECK: store i32*
Basic support for name mangling of C++11 lambda expressions. Because name mangling in the Itanium C++ ABI for lambda expressions is so dependent on context, we encode the number used to encode each lambda as part of the lambda closure type, and maintain this value within Sema. Note that there are a several pieces still missing: - We still get the linkage of lambda expressions wrong - We aren't properly numbering or mangling lambda expressions that occur in default function arguments or in data member initializers. - We aren't (de-)serializing the lambda numbering tables llvm-svn: 150982
2012-02-21 03:44:39 +08:00
// CHECK: call i32 @_ZZ1ciENKUlvE_clEv
// CHECK: define internal i32 @_ZZ1ciENKUlvE_clEv
Add a coverage test for lambda expression IRGen. llvm-svn: 150458
2012-02-14 11:07:59 +08:00
// CHECK: load i32**
// CHECK: load i32*
// CHECK: ret i32
struct D { D(); D(const D&); int x; };
int d(int x) { D y[10]; [x,y] { return y[x].x; }(); }
// CHECK: define i32 @_Z1di
// CHECK: call void @_ZN1DC1Ev
// CHECK: icmp ult i64 %{{.*}}, 10
// CHECK: call void @_ZN1DC1ERKS_
Basic support for name mangling of C++11 lambda expressions. Because name mangling in the Itanium C++ ABI for lambda expressions is so dependent on context, we encode the number used to encode each lambda as part of the lambda closure type, and maintain this value within Sema. Note that there are a several pieces still missing: - We still get the linkage of lambda expressions wrong - We aren't properly numbering or mangling lambda expressions that occur in default function arguments or in data member initializers. - We aren't (de-)serializing the lambda numbering tables llvm-svn: 150982
2012-02-21 03:44:39 +08:00
// CHECK: call i32 @_ZZ1diENKUlvE_clEv
// CHECK: define internal i32 @_ZZ1diENKUlvE_clEv
Add a coverage test for lambda expression IRGen. llvm-svn: 150458
2012-02-14 11:07:59 +08:00
// CHECK: load i32*
// CHECK: load i32*
// CHECK: ret i32
struct E { E(); E(const E&); ~E(); int x; };
int e(E a, E b, bool cond) { [a,b,cond](){ return (cond ? a : b).x; }(); }
// CHECK: define i32 @_Z1e1ES_b
// CHECK: call void @_ZN1EC1ERKS_
// CHECK: invoke void @_ZN1EC1ERKS_
Basic support for name mangling of C++11 lambda expressions. Because name mangling in the Itanium C++ ABI for lambda expressions is so dependent on context, we encode the number used to encode each lambda as part of the lambda closure type, and maintain this value within Sema. Note that there are a several pieces still missing: - We still get the linkage of lambda expressions wrong - We aren't properly numbering or mangling lambda expressions that occur in default function arguments or in data member initializers. - We aren't (de-)serializing the lambda numbering tables llvm-svn: 150982
2012-02-21 03:44:39 +08:00
// CHECK: invoke i32 @_ZZ1e1ES_bENKUlvE_clEv
// CHECK: call void @_ZZ1e1ES_bENUlvE_D1Ev
// CHECK: call void @_ZZ1e1ES_bENUlvE_D1Ev
Rework the Sema/AST/IRgen dance for the lambda closure type's conversion to function pointer. Rather than having IRgen synthesize the body of this function, we instead introduce a static member function "__invoke" with the same signature as the lambda's operator() in the AST. Sema then generates a body for the conversion to function pointer which simply returns the address of __invoke. This approach makes it easier to evaluate a call to the conversion function as a constant, makes the linkage of the __invoke function follow the normal rules for member functions, and may make life easier down the road if we ever want to constexpr'ify some of lambdas. Note that IR generation is responsible for filling in the body of __invoke (Sema just adds a dummy body), because the body can't generally be expressed in C++. Eli, please review! llvm-svn: 150783
2012-02-17 11:02:34 +08:00
Basic support for name mangling of C++11 lambda expressions. Because name mangling in the Itanium C++ ABI for lambda expressions is so dependent on context, we encode the number used to encode each lambda as part of the lambda closure type, and maintain this value within Sema. Note that there are a several pieces still missing: - We still get the linkage of lambda expressions wrong - We aren't properly numbering or mangling lambda expressions that occur in default function arguments or in data member initializers. - We aren't (de-)serializing the lambda numbering tables llvm-svn: 150982
2012-02-21 03:44:39 +08:00
// CHECK: define internal i32 @_ZZ1e1ES_bENKUlvE_clEv
Add a coverage test for lambda expression IRGen. llvm-svn: 150458
2012-02-14 11:07:59 +08:00
// CHECK: trunc i8
// CHECK: load i32*
// CHECK: ret i32
Rework the Sema/AST/IRgen dance for the lambda closure type's conversion to function pointer. Rather than having IRgen synthesize the body of this function, we instead introduce a static member function "__invoke" with the same signature as the lambda's operator() in the AST. Sema then generates a body for the conversion to function pointer which simply returns the address of __invoke. This approach makes it easier to evaluate a call to the conversion function as a constant, makes the linkage of the __invoke function follow the normal rules for member functions, and may make life easier down the road if we ever want to constexpr'ify some of lambdas. Note that IR generation is responsible for filling in the body of __invoke (Sema just adds a dummy body), because the body can't generally be expressed in C++. Eli, please review! llvm-svn: 150783
2012-02-17 11:02:34 +08:00
void f() {
// CHECK: define void @_Z1fv()
Basic support for name mangling of C++11 lambda expressions. Because name mangling in the Itanium C++ ABI for lambda expressions is so dependent on context, we encode the number used to encode each lambda as part of the lambda closure type, and maintain this value within Sema. Note that there are a several pieces still missing: - We still get the linkage of lambda expressions wrong - We aren't properly numbering or mangling lambda expressions that occur in default function arguments or in data member initializers. - We aren't (de-)serializing the lambda numbering tables llvm-svn: 150982
2012-02-21 03:44:39 +08:00
// CHECK: {{call.*@_ZZ1fvENKUliiE_cvPFiiiEEv}}
Rework the Sema/AST/IRgen dance for the lambda closure type's conversion to function pointer. Rather than having IRgen synthesize the body of this function, we instead introduce a static member function "__invoke" with the same signature as the lambda's operator() in the AST. Sema then generates a body for the conversion to function pointer which simply returns the address of __invoke. This approach makes it easier to evaluate a call to the conversion function as a constant, makes the linkage of the __invoke function follow the normal rules for member functions, and may make life easier down the road if we ever want to constexpr'ify some of lambdas. Note that IR generation is responsible for filling in the body of __invoke (Sema just adds a dummy body), because the body can't generally be expressed in C++. Eli, please review! llvm-svn: 150783
2012-02-17 11:02:34 +08:00
// CHECK-NEXT: store i32 (i32, i32)*
// CHECK-NEXT: ret void
int (*fp)(int, int) = [](int x, int y){ return x + y; };
}
Basic support for name mangling of C++11 lambda expressions. Because name mangling in the Itanium C++ ABI for lambda expressions is so dependent on context, we encode the number used to encode each lambda as part of the lambda closure type, and maintain this value within Sema. Note that there are a several pieces still missing: - We still get the linkage of lambda expressions wrong - We aren't properly numbering or mangling lambda expressions that occur in default function arguments or in data member initializers. - We aren't (de-)serializing the lambda numbering tables llvm-svn: 150982
2012-02-21 03:44:39 +08:00
// CHECK: define internal i32 @_ZZ1fvENUliiE_8__invokeEii
Rework the Sema/AST/IRgen dance for the lambda closure type's conversion to function pointer. Rather than having IRgen synthesize the body of this function, we instead introduce a static member function "__invoke" with the same signature as the lambda's operator() in the AST. Sema then generates a body for the conversion to function pointer which simply returns the address of __invoke. This approach makes it easier to evaluate a call to the conversion function as a constant, makes the linkage of the __invoke function follow the normal rules for member functions, and may make life easier down the road if we ever want to constexpr'ify some of lambdas. Note that IR generation is responsible for filling in the body of __invoke (Sema just adds a dummy body), because the body can't generally be expressed in C++. Eli, please review! llvm-svn: 150783
2012-02-17 11:02:34 +08:00
// CHECK: store i32
// CHECK-NEXT: store i32
// CHECK-NEXT: load i32*
// CHECK-NEXT: load i32*
Basic support for name mangling of C++11 lambda expressions. Because name mangling in the Itanium C++ ABI for lambda expressions is so dependent on context, we encode the number used to encode each lambda as part of the lambda closure type, and maintain this value within Sema. Note that there are a several pieces still missing: - We still get the linkage of lambda expressions wrong - We aren't properly numbering or mangling lambda expressions that occur in default function arguments or in data member initializers. - We aren't (de-)serializing the lambda numbering tables llvm-svn: 150982
2012-02-21 03:44:39 +08:00
// CHECK-NEXT: call i32 @_ZZ1fvENKUliiE_clEii
Rework the Sema/AST/IRgen dance for the lambda closure type's conversion to function pointer. Rather than having IRgen synthesize the body of this function, we instead introduce a static member function "__invoke" with the same signature as the lambda's operator() in the AST. Sema then generates a body for the conversion to function pointer which simply returns the address of __invoke. This approach makes it easier to evaluate a call to the conversion function as a constant, makes the linkage of the __invoke function follow the normal rules for member functions, and may make life easier down the road if we ever want to constexpr'ify some of lambdas. Note that IR generation is responsible for filling in the body of __invoke (Sema just adds a dummy body), because the body can't generally be expressed in C++. Eli, please review! llvm-svn: 150783
2012-02-17 11:02:34 +08:00
// CHECK-NEXT: ret i32
Basic support for name mangling of C++11 lambda expressions. Because name mangling in the Itanium C++ ABI for lambda expressions is so dependent on context, we encode the number used to encode each lambda as part of the lambda closure type, and maintain this value within Sema. Note that there are a several pieces still missing: - We still get the linkage of lambda expressions wrong - We aren't properly numbering or mangling lambda expressions that occur in default function arguments or in data member initializers. - We aren't (de-)serializing the lambda numbering tables llvm-svn: 150982
2012-02-21 03:44:39 +08:00
// CHECK: define internal void @_ZZ1e1ES_bENUlvE_D2Ev