maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Modules/cxx-templates.cpp

137 lines
6.3 KiB
C++
Raw Normal View History

Slightly improve cross-module merging for function templates. llvm-svn: 184689
2013-06-24 12:45:28 +08:00
// RUN: rm -rf %t
Add 'not' to commands that are expected to fail. This is at least good documentation, but also opens the possibility of using pipefail. llvm-svn: 185652
2013-07-05 00:16:58 +08:00
// RUN: not %clang_cc1 -x objective-c++ -fmodules -fmodules-cache-path=%t -I %S/Inputs %s -std=c++11 -ast-dump -ast-dump-lookups | FileCheck %s --check-prefix=CHECK-GLOBAL
// RUN: not %clang_cc1 -x objective-c++ -fmodules -fmodules-cache-path=%t -I %S/Inputs %s -std=c++11 -ast-dump -ast-dump-lookups -ast-dump-filter N | FileCheck %s --check-prefix=CHECK-NAMESPACE-N
AST dumper: if we have multiple implicit instantiations of the same class template specialization (from different modules), dump them all, so that every declaration is dumped somewhere. llvm-svn: 204100
2014-03-18 10:07:28 +08:00
// RUN: not %clang_cc1 -x objective-c++ -fmodules -fmodules-cache-path=%t -I %S/Inputs %s -std=c++11 -ast-dump | FileCheck %s --check-prefix=CHECK-DUMP
Slightly improve cross-module merging for function templates. llvm-svn: 184689
2013-06-24 12:45:28 +08:00
// RUN: %clang_cc1 -x objective-c++ -fmodules -fmodules-cache-path=%t -I %S/Inputs %s -verify -std=c++11
@import cxx_templates_a;
@import cxx_templates_b;
Test that we can merge together explicit and partial specializations from merged declarations of a class template. llvm-svn: 192746
2013-10-16 07:19:58 +08:00
@import cxx_templates_c;
C++ modules: merging for enumerations and enumerators with multiple definitions (eg through template instantiations in multiple modules). llvm-svn: 192740
2013-10-16 06:02:41 +08:00
@import cxx_templates_common;
Slightly improve cross-module merging for function templates. llvm-svn: 184689
2013-06-24 12:45:28 +08:00
Check for matching template-parameter-lists when merging template declarations. llvm-svn: 184791
2013-06-25 06:51:00 +08:00
template<typename, char> struct Tmpl_T_C {};
template<typename, int, int> struct Tmpl_T_I_I {};
template<typename A, typename B, A> struct Tmpl_T_T_A {};
template<typename A, typename B, B> struct Tmpl_T_T_B {};
C++ modules: merging for enumerations and enumerators with multiple definitions (eg through template instantiations in multiple modules). llvm-svn: 192740
2013-10-16 06:02:41 +08:00
template<int> struct UseInt {};
Slightly improve cross-module merging for function templates. llvm-svn: 184689
2013-06-24 12:45:28 +08:00
void g() {
f(0);
f<double>(1.0);
f<int>();
f(); // expected-error {{no matching function}}
Fix deserializing of class template partial specializations. Assign sequence numbers as we deserialize class template partial specializations. We can't assume that the old sequence numbers will work. The sequence numbers are still deterministic, but are now a lot less predictable for class template partial specializations in modules/PCH. llvm-svn: 184811
2013-06-25 09:25:15 +08:00
// expected-note@Inputs/cxx-templates-b.h:3 {{couldn't infer template argument}}
// expected-note@Inputs/cxx-templates-b.h:4 {{requires single argument}}
Slightly improve cross-module merging for function templates. llvm-svn: 184689
2013-06-24 12:45:28 +08:00
N::f(0);
N::f<double>(1.0);
N::f<int>();
N::f(); // expected-error {{no matching function}}
When we perform dependent name lookup during template instantiation, it's not sufficient to only consider names visible at the point of instantiation, because that may not include names that were visible when the template was defined. More generally, if the instantiation backtrace goes through a module M, then every declaration visible within M should be available to the instantiation. Any of those declarations might be part of the interface that M intended to export to a template that it instantiates. The fix here has two parts: 1) If we find a non-visible declaration during name lookup during template instantiation, check whether the declaration was visible from the defining module of all entities on the active template instantiation stack. The defining module is not the owning module in all cases: we look at the module in which a template was defined, not the module in which it was first instantiated. 2) Perform pending instantiations at the end of a module, not at the end of the translation unit. This is general goodness, since it significantly cuts down the amount of redundant work that is performed in every TU importing a module, and also implicitly adds the module containing the point of instantiation to the set of modules checked for declarations in a lookup within a template instantiation. There's a known issue here with template instantiations performed while building a module, if additional imports are added later on. I'll fix that in a subsequent commit. llvm-svn: 187167
2013-07-26 07:08:39 +08:00
// expected-note@Inputs/cxx-templates-b.h:6 {{couldn't infer template argument}}
// expected-note@Inputs/cxx-templates-b.h:7 {{requires single argument 't'}}
Check for matching template-parameter-lists when merging template declarations. llvm-svn: 184791
2013-06-25 06:51:00 +08:00
template_param_kinds_1<0>(); // ok, from cxx-templates-a.h
template_param_kinds_1<int>(); // ok, from cxx-templates-b.h
template_param_kinds_2<Tmpl_T_C>(); // expected-error {{no matching function}}
Fix deserializing of class template partial specializations. Assign sequence numbers as we deserialize class template partial specializations. We can't assume that the old sequence numbers will work. The sequence numbers are still deterministic, but are now a lot less predictable for class template partial specializations in modules/PCH. llvm-svn: 184811
2013-06-25 09:25:15 +08:00
// expected-note@Inputs/cxx-templates-a.h:11 {{invalid explicitly-specified argument}}
// expected-note@Inputs/cxx-templates-b.h:11 {{invalid explicitly-specified argument}}
Check for matching template-parameter-lists when merging template declarations. llvm-svn: 184791
2013-06-25 06:51:00 +08:00
template_param_kinds_2<Tmpl_T_I_I>(); // expected-error {{ambiguous}}
Fix deserializing of class template partial specializations. Assign sequence numbers as we deserialize class template partial specializations. We can't assume that the old sequence numbers will work. The sequence numbers are still deterministic, but are now a lot less predictable for class template partial specializations in modules/PCH. llvm-svn: 184811
2013-06-25 09:25:15 +08:00
// expected-note@Inputs/cxx-templates-a.h:11 {{candidate}}
// expected-note@Inputs/cxx-templates-b.h:11 {{candidate}}
Check for matching template-parameter-lists when merging template declarations. llvm-svn: 184791
2013-06-25 06:51:00 +08:00
// FIXME: This should be valid, but we incorrectly match the template template
// argument against both template template parameters.
template_param_kinds_3<Tmpl_T_T_A>(); // expected-error {{ambiguous}}
Fix deserializing of class template partial specializations. Assign sequence numbers as we deserialize class template partial specializations. We can't assume that the old sequence numbers will work. The sequence numbers are still deterministic, but are now a lot less predictable for class template partial specializations in modules/PCH. llvm-svn: 184811
2013-06-25 09:25:15 +08:00
// expected-note@Inputs/cxx-templates-a.h:12 {{candidate}}
// expected-note@Inputs/cxx-templates-b.h:12 {{candidate}}
Check for matching template-parameter-lists when merging template declarations. llvm-svn: 184791
2013-06-25 06:51:00 +08:00
template_param_kinds_3<Tmpl_T_T_B>(); // expected-error {{ambiguous}}
Fix deserializing of class template partial specializations. Assign sequence numbers as we deserialize class template partial specializations. We can't assume that the old sequence numbers will work. The sequence numbers are still deterministic, but are now a lot less predictable for class template partial specializations in modules/PCH. llvm-svn: 184811
2013-06-25 09:25:15 +08:00
// expected-note@Inputs/cxx-templates-a.h:12 {{candidate}}
// expected-note@Inputs/cxx-templates-b.h:12 {{candidate}}
When we perform dependent name lookup during template instantiation, it's not sufficient to only consider names visible at the point of instantiation, because that may not include names that were visible when the template was defined. More generally, if the instantiation backtrace goes through a module M, then every declaration visible within M should be available to the instantiation. Any of those declarations might be part of the interface that M intended to export to a template that it instantiates. The fix here has two parts: 1) If we find a non-visible declaration during name lookup during template instantiation, check whether the declaration was visible from the defining module of all entities on the active template instantiation stack. The defining module is not the owning module in all cases: we look at the module in which a template was defined, not the module in which it was first instantiated. 2) Perform pending instantiations at the end of a module, not at the end of the translation unit. This is general goodness, since it significantly cuts down the amount of redundant work that is performed in every TU importing a module, and also implicitly adds the module containing the point of instantiation to the set of modules checked for declarations in a lookup within a template instantiation. There's a known issue here with template instantiations performed while building a module, if additional imports are added later on. I'll fix that in a subsequent commit. llvm-svn: 187167
2013-07-26 07:08:39 +08:00
// Trigger the instantiation of a template in 'a' that uses a type defined in
// 'common'. That type is not visible here.
PerformDelayedLookup(defined_in_common);
Fix assert when instantiating a default argument of a template defined in a module. llvm-svn: 187556
2013-08-01 12:12:04 +08:00
// Likewise, but via a default argument.
PerformDelayedLookupInDefaultArgument(defined_in_common);
When we perform dependent name lookup during template instantiation, it's not sufficient to only consider names visible at the point of instantiation, because that may not include names that were visible when the template was defined. More generally, if the instantiation backtrace goes through a module M, then every declaration visible within M should be available to the instantiation. Any of those declarations might be part of the interface that M intended to export to a template that it instantiates. The fix here has two parts: 1) If we find a non-visible declaration during name lookup during template instantiation, check whether the declaration was visible from the defining module of all entities on the active template instantiation stack. The defining module is not the owning module in all cases: we look at the module in which a template was defined, not the module in which it was first instantiated. 2) Perform pending instantiations at the end of a module, not at the end of the translation unit. This is general goodness, since it significantly cuts down the amount of redundant work that is performed in every TU importing a module, and also implicitly adds the module containing the point of instantiation to the set of modules checked for declarations in a lookup within a template instantiation. There's a known issue here with template instantiations performed while building a module, if additional imports are added later on. I'll fix that in a subsequent commit. llvm-svn: 187167
2013-07-26 07:08:39 +08:00
// Trigger the instantiation of a template in 'b' that uses a type defined in
// 'b_impl'. That type is not visible here.
UseDefinedInBImpl<int>();
// Trigger the instantiation of a template in 'a' that uses a type defined in
// 'b_impl', via a template defined in 'b'. Since the type is visible from
// within 'b', the instantiation succeeds.
UseDefinedInBImplIndirectly(defined_in_b_impl);
// Trigger the instantiation of a template in 'a' that uses a type defined in
// 'b_impl'. That type is not visible here, nor in 'a'. This fails; there is
// no reason why DefinedInBImpl should be visible here.
// expected-error@Inputs/cxx-templates-a.h:19 {{definition of 'DefinedInBImpl' must be imported}}
// expected-note@Inputs/cxx-templates-b-impl.h:1 {{definition is here}}
PerformDelayedLookup(defined_in_b_impl); // expected-note {{in instantiation of}}
Merge common pointers for redeclarations of the same template across modules. llvm-svn: 192560
2013-10-14 07:50:45 +08:00
merge_templates_a = merge_templates_b; // ok, same type
C++ modules: merging for enumerations and enumerators with multiple definitions (eg through template instantiations in multiple modules). llvm-svn: 192740
2013-10-16 06:02:41 +08:00
using T = decltype(enum_a_from_a);
using T = decltype(enum_b_from_b);
T e = true ? enum_a_from_a : enum_b_from_b;
UseRedeclaredEnum<int>(UseInt<1>());
// FIXME: Reintroduce this once we merge function template specializations.
//static_assert(UseRedeclaredEnumA == UseRedeclaredEnumB, "");
//static_assert(UseRedeclaredEnumA == UseRedeclaredEnum<int>, "");
//static_assert(UseRedeclaredEnumB == UseRedeclaredEnum<int>, "");
static_assert(enum_c_from_a == enum_c_from_b, "");
CommonTemplate<int> cti;
CommonTemplate<int>::E eee = CommonTemplate<int>::c;
Slightly improve cross-module merging for function templates. llvm-svn: 184689
2013-06-24 12:45:28 +08:00
}
When merging redeclaration chains across modules, if a declaration is visible in one module but is only declared as a friend in another module, keep it visible in the result of the merge. This is incomplete on two axes: 1) Our handling of local extern declarations is basically broken (we put them in the wrong decl context, and don't find them in redeclaration lookup, unless they've previously been declared), and this results in them making friends visible after a merge. 2) Eventually we'll need to mark that this has happened, and more carefully check whether a declaration should be visible if it was only visible in some of the modules in which it was declared. Fortunately it's rare for the identifier namespace of a declaration to change along its redeclaration chain. llvm-svn: 187639
2013-08-02 09:09:12 +08:00
RedeclaredAsFriend<int> raf1;
RedeclareTemplateAsFriend<double> rtaf;
RedeclaredAsFriend<double> raf2;
Test that we can merge together explicit and partial specializations from merged declarations of a class template. llvm-svn: 192746
2013-10-16 07:19:58 +08:00
MergeSpecializations<int*>::partially_specialized_in_a spec_in_a_1;
MergeSpecializations<int&>::partially_specialized_in_b spec_in_b_1;
MergeSpecializations<int[]>::partially_specialized_in_c spec_in_c_1;
MergeSpecializations<char>::explicitly_specialized_in_a spec_in_a_2;
MergeSpecializations<double>::explicitly_specialized_in_b spec_in_b_2;
MergeSpecializations<bool>::explicitly_specialized_in_c spec_in_c_2;
Fix deserializing of class template partial specializations. Assign sequence numbers as we deserialize class template partial specializations. We can't assume that the old sequence numbers will work. The sequence numbers are still deterministic, but are now a lot less predictable for class template partial specializations in modules/PCH. llvm-svn: 184811
2013-06-25 09:25:15 +08:00
@import cxx_templates_common;
typedef SomeTemplate<int*> SomeTemplateIntPtr;
typedef SomeTemplate<int&> SomeTemplateIntRef;
SomeTemplate<char*> some_template_char_ptr;
SomeTemplate<char&> some_template_char_ref;
C++ modules: if a class is defined in multiple modules (for instance, because it is an implicit instantiation of a class template specialization), pick the first-loaded definition to be the canonical definition, and merge all other definitions into it. This is still rather incomplete -- we need to extend every form of declaration that can appear within a CXXRecordDecl to be redeclarable if it came from an AST file (this includes fields, enumerators, ...). llvm-svn: 190315
2013-09-10 00:55:27 +08:00
void testImplicitSpecialMembers(SomeTemplate<char[1]> &a,
const SomeTemplate<char[1]> &b,
SomeTemplate<char[2]> &c,
const SomeTemplate<char[2]> &d) {
a = b;
c = d;
}
Slightly improve cross-module merging for function templates. llvm-svn: 184689
2013-06-24 12:45:28 +08:00
// CHECK-GLOBAL: DeclarationName 'f'
// CHECK-GLOBAL-NEXT: |-FunctionTemplate {{.*}} 'f'
// CHECK-GLOBAL-NEXT: `-FunctionTemplate {{.*}} 'f'
// CHECK-NAMESPACE-N: DeclarationName 'f'
// CHECK-NAMESPACE-N-NEXT: |-FunctionTemplate {{.*}} 'f'
// CHECK-NAMESPACE-N-NEXT: `-FunctionTemplate {{.*}} 'f'
AST dumper: if we have multiple implicit instantiations of the same class template specialization (from different modules), dump them all, so that every declaration is dumped somewhere. llvm-svn: 204100
2014-03-18 10:07:28 +08:00
// CHECK-DUMP: ClassTemplateDecl {{.*}} <{{.*}}/cxx-templates-common.h:1:1, {{.*}}> in cxx_templates_common SomeTemplate
// CHECK-DUMP: ClassTemplateSpecializationDecl {{.*}} prev [[CHAR2:[^ ]*]] {{.*}} SomeTemplate
// CHECK-DUMP-NEXT: TemplateArgument type 'char [2]'
// CHECK-DUMP: ClassTemplateSpecializationDecl [[CHAR2]] {{.*}} SomeTemplate definition
// CHECK-DUMP-NEXT: TemplateArgument type 'char [2]'
// CHECK-DUMP: ClassTemplateSpecializationDecl {{.*}} prev [[CHAR1:[^ ]*]] {{.*}} SomeTemplate
// CHECK-DUMP-NEXT: TemplateArgument type 'char [1]'
// CHECK-DUMP: ClassTemplateSpecializationDecl [[CHAR1]] {{.*}} SomeTemplate definition
// CHECK-DUMP-NEXT: TemplateArgument type 'char [1]'