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

197 lines
8.8 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
[modules] Simplify -cc1 interface for enabling implicit module maps. We used to have a flag to enable module maps, and two more flags to enable implicit module maps. This is all redundant; we don't need any flag for enabling module maps in the abstract, and we don't usually have -fno- flags for -cc1. We now have just a single flag, -fimplicit-module-maps, that enables implicitly searching the file system for module map files and loading them. The driver interface is unchanged for now. We should probably rename -fmodule-maps to -fimplicit-module-maps at some point. llvm-svn: 239789
2015-06-16 08:08:24 +08:00
// RUN: not %clang_cc1 -x objective-c++ -fmodules -fimplicit-module-maps -fno-modules-error-recovery -fmodules-cache-path=%t -I %S/Inputs %s -std=c++11 -ast-dump-lookups | FileCheck %s --check-prefix=CHECK-GLOBAL
// RUN: not %clang_cc1 -x objective-c++ -fmodules -fimplicit-module-maps -fno-modules-error-recovery -fmodules-cache-path=%t -I %S/Inputs %s -std=c++11 -ast-dump-lookups -ast-dump-filter N | FileCheck %s --check-prefix=CHECK-NAMESPACE-N
// RUN: not %clang_cc1 -x objective-c++ -fmodules -fimplicit-module-maps -fno-modules-error-recovery -fmodules-cache-path=%t -I %S/Inputs %s -std=c++11 -ast-dump -ast-dump-filter SomeTemplate | FileCheck %s --check-prefix=CHECK-DUMP
// RUN: %clang_cc1 -x objective-c++ -fmodules -fimplicit-module-maps -fno-modules-error-recovery -fmodules-cache-path=%t -I %S/Inputs %s -verify -std=c++11
// RUN: %clang_cc1 -x objective-c++ -fmodules -fimplicit-module-maps -fno-modules-error-recovery -fmodules-cache-path=%t -I %S/Inputs %s -verify -std=c++11 -DEARLY_IMPORT
[modules] Put class template declarations into the scope in which they're declared, rather than putting them into the template parameter scope. We previously had *no record* in the scope for class template declarations, once those declarations completed and their template parameter scopes were popped. This in turn caused us to be unable to merge class template declarations that were declared in the global scope (where we use scope lookup rather than DeclContext lookup for merging), when loading a module. llvm-svn: 216311
2014-08-23 08:49:01 +08:00
#ifdef EARLY_IMPORT
#include "cxx-templates-textual.h"
#endif
Slightly improve cross-module merging for function templates. llvm-svn: 184689
2013-06-24 12:45:28 +08:00
@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;
[modules] When completing the redecl chain for an anonymous declaration in a merged context, pull in the lexical decls in that context, since one of them may complete the redecl chain. llvm-svn: 216652
2014-08-28 13:44:07 +08:00
@import cxx_templates_d;
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}}
[modules] When performing a lookup into a namespace, ensure that any later redefinitions of that namespace have already been loaded. When writing out the names in a namespace, if we see a name that is locally declared and had imported declarations merged on top of it, export the local declaration as the lookup result, because it will be the most recent declaration of that entity in the redeclaration chain of an importer of the module. llvm-svn: 215518
2014-08-13 09:23:33 +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}}
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.
If an instantiation of a template is required to be a complete type, check whether the definition of the template is visible rather than checking whether the instantiated definition happens to be in an imported module. llvm-svn: 208150
2014-05-07 10:25:43 +08:00
//
// We turn off error recovery for modules in this test (so we don't get an
// implicit import of cxx_templates_b_impl), and that results in us producing
// a big spew of errors here.
//
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-error@Inputs/cxx-templates-a.h:19 {{definition of 'DefinedInBImpl' must be imported}}
If an instantiation of a template is required to be a complete type, check whether the definition of the template is visible rather than checking whether the instantiated definition happens to be in an imported module. llvm-svn: 208150
2014-05-07 10:25:43 +08:00
// expected-note@Inputs/cxx-templates-b-impl.h:1 +{{definition is here}}
// expected-error@Inputs/cxx-templates-a.h:19 +{{}}
// expected-error@Inputs/cxx-templates-a.h:20 +{{}}
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
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;
If an instantiation of a template is required to be a complete type, check whether the definition of the template is visible rather than checking whether the instantiated definition happens to be in an imported module. llvm-svn: 208150
2014-05-07 10:25:43 +08:00
TemplateInstantiationVisibility<char[1]> tiv1;
TemplateInstantiationVisibility<char[2]> tiv2;
TemplateInstantiationVisibility<char[3]> tiv3; // expected-error {{must be imported from module 'cxx_templates_b_impl'}}
// expected-note@cxx-templates-b-impl.h:10 {{previous definition is here}}
TemplateInstantiationVisibility<char[4]> tiv4;
If a class template specialization from one module has its definition instantiated in another module, and the instantiation uses a partial specialization, include the partial specialization and its template arguments in the update record. We'll need them if someone imports the second module and tries to instantiate a member of the template. llvm-svn: 209472
2014-05-23 04:59:29 +08:00
int &p = WithPartialSpecializationUse().f();
[modules] If a referenced-but-not-instantiated class template specialization gets explicitly specialized, don't reuse the previous class template specialization declaration as a new declaration. The benefit here is fairly marginal, it harms source fidelity, and this is horrible to model if the specialization was imported from another module (without this change, it asserts or worse). llvm-svn: 209552
2014-05-24 05:00:28 +08:00
int &q = WithExplicitSpecializationUse().inner_template<int>();
[modules] Add testcase for a bug reduced from a selfhost issue. This bug was never present in Clang trunk, but was present in some of my development work, and it seems like a useful test to have. llvm-svn: 214154
2014-07-29 08:58:01 +08:00
int *r = PartiallyInstantiatePartialSpec<int*>::bar();
[modules] When we merge together multiple class template specialization definitions (because some other declaration declares a special member that isn't present in the canonical definition), we need to search *all* of them; we can't just stop when we find the requested name in any of the definitions, because that can fail to find things (and in particular, it can fail to find the member of the canonical declaration and return a bogus ODR failure). llvm-svn: 215612
2014-08-14 10:21:01 +08:00
(void)&WithImplicitSpecialMembers<int>::n;
[modules] Put class template declarations into the scope in which they're declared, rather than putting them into the template parameter scope. We previously had *no record* in the scope for class template declarations, once those declarations completed and their template parameter scopes were popped. This in turn caused us to be unable to merge class template declarations that were declared in the global scope (where we use scope lookup rather than DeclContext lookup for merging), when loading a module. llvm-svn: 216311
2014-08-23 08:49:01 +08:00
MergeClassTemplateSpecializations_string s;
[modules] When building an injected-class-name type, we may have to insert it into multiple merged classes' TypeForDecl slots. llvm-svn: 220331
2014-10-22 05:15:18 +08:00
extern TestInjectedClassName::A *use_a;
extern TestInjectedClassName::C *use_c;
TestInjectedClassName::UseD();
Slightly improve cross-module merging for function templates. llvm-svn: 184689
2013-06-24 12:45:28 +08:00
}
[modules] Don't try to merge template specializations by performing name lookup into their container; we won't find them there. These things are already being merged when they're added to their primary template's folding set, so this merging is redundant (and causes us to reject-valid because we think we've found an odr violation). llvm-svn: 212788
2014-07-11 08:20:06 +08:00
static_assert(Outer<int>::Inner<int>::f() == 1, "");
static_assert(Outer<int>::Inner<int>::g() == 2, "");
[modules] When merging class definitions, make the retained definition visible if the merged definition is visible, and perform lookups into all merged copies of the definition (not just for special members) so that we can complete the redecl chains for members of the class. llvm-svn: 233420
2015-03-28 05:16:39 +08:00
static_assert(MergeTemplateDefinitions<int>::f() == 1, "");
[modules] When merging a class template, also merge the definition of its pattern. llvm-svn: 212836
2014-07-12 02:22:58 +08:00
static_assert(MergeTemplateDefinitions<int>::g() == 2, "");
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;
[modules] Delay loading the field declared with an anonymous tag declaration until after we've had a chance to merge that tag. llvm-svn: 219539
2014-10-11 06:37:41 +08:00
MergeAnonUnionMember<> maum_main;
[modules] When instantiating a class member, don't expect to find the previous declaration in the instantiation if the previous declaration came from another definition of the class template that got merged into the pattern definition. llvm-svn: 219552
2014-10-11 08:37:16 +08:00
typedef DontWalkPreviousDeclAfterMerging<int> dwpdam_typedef_2;
dwpdam_typedef::type dwpdam_typedef_use;
DontWalkPreviousDeclAfterMerging<int>::Inner::type dwpdam;
[modules] Delay loading the field declared with an anonymous tag declaration until after we've had a chance to merge that tag. llvm-svn: 219539
2014-10-11 06:37:41 +08:00
[modules] Track the described template in an alias declaration that is the pattern of an alias template declaration. Use this to merge alias templates properly when they're members of class template specializations. llvm-svn: 216437
2014-08-26 11:52:16 +08:00
using AliasTemplateMergingTest = WithAliasTemplate<int>::X<char>;
[modules] When completing the redecl chain for an anonymous declaration in a merged context, pull in the lexical decls in that context, since one of them may complete the redecl chain. llvm-svn: 216652
2014-08-28 13:44:07 +08:00
int AnonymousDeclsMergingTest(WithAnonymousDecls<int> WAD, WithAnonymousDecls<char> WADC) {
[modules] Number anonymous declarations that are lexically within mergeable contexts, so that we can merge them when we merge the surrounding context. llvm-svn: 216639
2014-08-28 09:33:39 +08:00
return InstantiateWithAnonymousDeclsA(WAD) +
[modules] When completing the redecl chain for an anonymous declaration in a merged context, pull in the lexical decls in that context, since one of them may complete the redecl chain. llvm-svn: 216652
2014-08-28 13:44:07 +08:00
InstantiateWithAnonymousDeclsB(WAD) +
InstantiateWithAnonymousDeclsB2(WADC) +
InstantiateWithAnonymousDeclsD(WADC);
[modules] Number anonymous declarations that are lexically within mergeable contexts, so that we can merge them when we merge the surrounding context. llvm-svn: 216639
2014-08-28 09:33:39 +08:00
}
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;
}
If a template instantation introduces a name into a namespace, we need to write out a visible update record for that namespace even if it was never declared in this module. llvm-svn: 204554
2014-03-23 10:30:01 +08:00
bool testFriendInClassTemplate(Std::WithFriend<int> wfi) {
return wfi != wfi;
}
When we inject a declaration into a namespace, add the primary DeclContext to the update set rather than the current DeclContext. Add test for the local extern case too. llvm-svn: 204568
2014-03-24 03:45:26 +08:00
namespace Std {
void g(); // expected-error {{functions that differ only in their return type cannot be overloaded}}
// expected-note@cxx-templates-common.h:21 {{previous}}
}
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
Add the location of Decls to ast dump. While investigating some debug info issues, Eric and I came across a particular template case where the location of a decl was quite different from the range of the same decl. It might've been rather helpful if the dumper had actually showed us this. llvm-svn: 205396
2014-04-02 13:48:29 +08:00
// CHECK-DUMP: ClassTemplateDecl {{.*}} <{{.*[/\\]}}cxx-templates-common.h:1:1, {{.*}}> col:{{.*}} in cxx_templates_common SomeTemplate
[modules] When collecting declarations to complete a redeclaration chain for an entity, put the originally-canonical decl IDs in the right places in the redecl chain rather than reordering them all to the start. If we don't ensure that the redecl chain order is consistent with the topological module order, we can fail to make a declaration visible if later declarations are in more IDNSs than earlier ones (for instance, because the earlier decls are invisible friends). llvm-svn: 228978
2015-02-13 07:21:45 +08:00
// CHECK-DUMP: ClassTemplateSpecializationDecl {{.*}} prev {{.*}} SomeTemplate
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-NEXT: TemplateArgument type 'char [2]'
[modules] When collecting declarations to complete a redeclaration chain for an entity, put the originally-canonical decl IDs in the right places in the redecl chain rather than reordering them all to the start. If we don't ensure that the redecl chain order is consistent with the topological module order, we can fail to make a declaration visible if later declarations are in more IDNSs than earlier ones (for instance, because the earlier decls are invisible friends). llvm-svn: 228978
2015-02-13 07:21:45 +08:00
// CHECK-DUMP: ClassTemplateSpecializationDecl {{.*}} SomeTemplate definition
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-NEXT: TemplateArgument type 'char [2]'
[modules] When collecting declarations to complete a redeclaration chain for an entity, put the originally-canonical decl IDs in the right places in the redecl chain rather than reordering them all to the start. If we don't ensure that the redecl chain order is consistent with the topological module order, we can fail to make a declaration visible if later declarations are in more IDNSs than earlier ones (for instance, because the earlier decls are invisible friends). llvm-svn: 228978
2015-02-13 07:21:45 +08:00
// CHECK-DUMP: ClassTemplateSpecializationDecl {{.*}} prev {{.*}} SomeTemplate
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-NEXT: TemplateArgument type 'char [1]'
[modules] When collecting declarations to complete a redeclaration chain for an entity, put the originally-canonical decl IDs in the right places in the redecl chain rather than reordering them all to the start. If we don't ensure that the redecl chain order is consistent with the topological module order, we can fail to make a declaration visible if later declarations are in more IDNSs than earlier ones (for instance, because the earlier decls are invisible friends). llvm-svn: 228978
2015-02-13 07:21:45 +08:00
// CHECK-DUMP: ClassTemplateSpecializationDecl {{.*}} SomeTemplate definition
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-NEXT: TemplateArgument type 'char [1]'