| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
This implements [dcl.modules.export] from the C++ Modules TS, which lets a module re-export another module with the "export import" syntax.
Differential Revision: https://reviews.llvm.org/D40270
llvm-svn: 318744
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
This reinstates r315251 and r315256, reverted in r315309 and r315308
respectively, tweaked to avoid triggering a linkage calculation when declaring
implicit special members (this exposed our pre-existing issue with typedef
names for linkage changing the linkage of types whose linkage has already been
computed and cached in more cases). A testcase for that regression has been
added in r315366.
llvm-svn: 315379
|
| |
|
|
|
|
| |
This reverts commit r315251. See the original commit thread for reason.
llvm-svn: 315309
|
| |
|
|
|
|
|
|
|
|
| |
When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.
llvm-svn: 315251
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This follows the scheme agreed with Nathan Sidwell, which can be found here:
https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile
This will be proposed to the itanium-cxx-abi list once we have some experience
with how well it works; the ABI for this TS should be considered unstable until
it is part of the Itanium C++ ABI.
llvm-svn: 312467
|
| |
|
|
|
|
| |
the module if declared in an export block.
llvm-svn: 307115
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inferring based on the current module at the point of creation.
This should result in no functional change except when building a preprocessed
module (or more generally when using #pragma clang module begin/end to switch
module in the middle of a file), in which case it allows us to correctly track
the owning module for declarations. We can't map from FileID to module in the
preprocessed module case, since all modules would have the same FileID.
There are still a couple of remaining places that try to infer a module from a
source location; I'll clean those up in follow-up changes.
llvm-svn: 303322
|
| |
|
|
|
|
|
| |
and appease:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/2030
llvm-svn: 302771
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Diagnostics related to redefinition errors that point to the same header
file do not provide much information that helps users fixing the issue.
- In the modules context, it usually happens because of non modular
includes.
- When modules aren't involved it might happen because of the lack of
header guards.
Enhance diagnostics in these scenarios.
Differential Revision: https://reviews.llvm.org/D28832
rdar://problem/31669175
llvm-svn: 302765
|
| |
|
|
| |
llvm-svn: 301271
|
| |
|
|
|
|
|
|
|
|
|
|
| |
implementation.
This switches from the prototype syntax in P0273R0 ('module' and 'module
implementation') to the consensus syntax 'export module' and 'module'.
In passing, drop the "module declaration must be first" enforcement, since EWG
seems to have changed its mind on that.
llvm-svn: 301056
|
| |
|
|
| |
llvm-svn: 282443
|
|
|
export-declarations. These don't yet have an effect on name visibility;
we still export everything by default.
llvm-svn: 280999
|
