Commit Graph

9 Commits

Author SHA1 Message Date
Benjamin Kramer a72a70aeb9 Revert "Reinstate r281429, reverted in r281452, with a fix for its mishandling of"
This reverts commit r284176. It still marks some modules as invisible
that should be visible. Will follow up with the author with a test case.

llvm-svn: 284382
2016-10-17 13:00:44 +00:00
Richard Smith b50df91178 Reinstate r281429, reverted in r281452, with a fix for its mishandling of
compiles without -fmodules-local-submodule-visibility. Original commit message:

[modules] When merging one definition into another, propagate the list of
re-exporting modules from the discarded definition to the retained definition.

llvm-svn: 284176
2016-10-13 23:04:14 +00:00
Eric Liu 762b4887c2 Revert "[modules] When merging one definition into another, propagate the list of re-exporting modules from the discarded definition to the retained definition."
This reverts commit r281429.

llvm-svn: 281452
2016-09-14 10:05:10 +00:00
Richard Smith 1c16d1b576 [modules] When merging one definition into another, propagate the list of
re-exporting modules from the discarded definition to the retained definition.

llvm-svn: 281429
2016-09-14 01:05:35 +00:00
Richard Smith 6561f92b62 [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-12 21:06:40 +00:00
Richard Smith 6f4e2e038d 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-23 19:41:39 +00:00
Chandler Carruth c6c937f2a6 Revert r279486 "Fix regression introduced by r279164"
Build bots seem unhappy and as Richard was leaving he asked me to revert
this for him. Doing so.

llvm-svn: 279500
2016-08-23 02:00:51 +00:00
Richard Smith 2fbcbb7b38 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.

llvm-svn: 279486
2016-08-22 22:25:03 +00:00
Richard Smith 7a591a4a46 [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 02:22:15 +00:00