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/merge-template-pattern-visi...

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

19 lines
888 B
C++
Raw Normal View History

[modules] When determining the visible module set during template instantiation, use the set of modules visible from the template definition, not from whichever declaration the specialization was instantiated from. llvm-svn: 241662
2015-07-08 10:22:15 +08:00
// RUN: rm -rf %t
Fix regression introduced by r279164: only pass definitions as the PatternDef to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. This reinstates r279486, reverted in r279500, with a fix to DiagnoseUninstantiableTemplate to only mark uninstantiable explicit instantiation declarations as invalid if we actually diagnosed them. (When we trigger an explicit instantiation of a class member from an explicit instantiation declaration for the class, it's OK if there is no corresponding definition and we certainly don't want to mark the member invalid in that case.) This previously caused a build failure during bootstrap. llvm-svn: 279557
2016-08-24 03:41:39 +08:00
// RUN: %clang_cc1 -fmodules -fno-modules-error-recovery -std=c++14 \
[modules] When determining the visible module set during template instantiation, use the set of modules visible from the template definition, not from whichever declaration the specialization was instantiated from. llvm-svn: 241662
2015-07-08 10:22:15 +08:00
// RUN: -fmodule-name=X -emit-module %S/Inputs/merge-template-pattern-visibility/module.modulemap -x c++ \
Fix regression introduced by r279164: only pass definitions as the PatternDef to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. This reinstates r279486, reverted in r279500, with a fix to DiagnoseUninstantiableTemplate to only mark uninstantiable explicit instantiation declarations as invalid if we actually diagnosed them. (When we trigger an explicit instantiation of a class member from an explicit instantiation declaration for the class, it's OK if there is no corresponding definition and we certainly don't want to mark the member invalid in that case.) This previously caused a build failure during bootstrap. llvm-svn: 279557
2016-08-24 03:41:39 +08:00
// RUN: -fmodules-local-submodule-visibility -o %t/X.pcm
[modules] When we merge two definitions of a function, mark the retained definition as visible in the discarded definition's module, as we do for other kinds of definition. llvm-svn: 281258
2016-09-13 05:06:40 +08:00
// RUN: %clang_cc1 -fmodules -fno-modules-error-recovery -std=c++14 \
// RUN: -fmodule-name=Y -emit-module %S/Inputs/merge-template-pattern-visibility/module.modulemap -x c++ \
// RUN: -fmodules-local-submodule-visibility -o %t/Y.pcm
// RUN: %clang_cc1 -fmodules -fno-modules-error-recovery -std=c++14 -fmodule-file=%t/X.pcm -fmodule-file=%t/Y.pcm \
// RUN: -fmodules-local-submodule-visibility -verify %s -I%S/Inputs/merge-template-pattern-visibility
#include "b.h"
#include "d.h"
// expected-no-diagnostics
void g() {
CrossModuleMerge::B<int> bi;
CrossModuleMerge::C(0);
}