#
1614d634 |
| 18-Nov-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[NFC] Remove unused codes after 4a7be42d922af
There are still some unused codes remained after 4a7be42d922af. And this patch tries to remove them.
|
#
9044226b |
| 15-Nov-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[NFC] [C++20] [Modules] Remove unused Global Module Fragment variables/arguments
|
#
964c4948 |
| 03-Nov-2022 |
Haojian Wu <hokein.wu@gmail.com> |
Remove an unused local variable, NFC.
|
#
b8ceb9f4 |
| 03-Nov-2022 |
Aaron Ballman <aaron@aaronballman.com> |
[C++20] Diagnose invalid and reserved module names
[module.unit]p1 specifies that module and import are invalid components of a module name, that module names cannot contain reserved identifiers, an
[C++20] Diagnose invalid and reserved module names
[module.unit]p1 specifies that module and import are invalid components of a module name, that module names cannot contain reserved identifiers, and that std followed by zero or more digits is reserved.
The first issue (module and import pseudo-keywords) requires a diagnostic, the second issue (use of reserved identifiers) does not require a diagnostic. We diagnose both the same -- the code is ill- formed unless the module declaration is in a system "header". This allows STL implementations to use the reserved module names while preventing users from stealing them out from under us.
Differential Revision: https://reviews.llvm.org/D136953
show more ...
|
#
9974ed80 |
| 08-Oct-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[C++20] [Modules] Remove assertion of current module when acting on import
Closes https://github.com/llvm/llvm-project/issues/58199
Previously, when we act on a import statement, we'll assume there
[C++20] [Modules] Remove assertion of current module when acting on import
Closes https://github.com/llvm/llvm-project/issues/58199
Previously, when we act on a import statement, we'll assume there is a module declaration in the current TU if the command line tells us we're compiling a module unit. This makes since on valid codes. However, for invalid codes, it is possible. See https://github.com/llvm/llvm-project/issues/58199 for example.
This patch removes the assertion. And the assertion is a noop and it should be safe to remove it.
show more ...
|
#
fee3cccc |
| 22-Jun-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules] Improve handing of Private Module Fragment diagnostics.
This adds a check for exported inline functions, that there is a definition in the definition domain (which, in practice, can
[C++20][Modules] Improve handing of Private Module Fragment diagnostics.
This adds a check for exported inline functions, that there is a definition in the definition domain (which, in practice, can only be the module purview but before any PMF starts) since the PMF definition domain cannot contain exports.
This is: [dcl.inline]/7 If an inline function or variable that is attached to a named module is declared in a definition domain, it shall be defined in that domain.
The patch also amends diagnostic output by excluding the PMF sub-module from the set considered as sources of missing decls. There is no point in telling the user that the import of a PMF object is missing - since such objects are never reachable to an importer. We still show the definition (as unreachable), to help point out this.
Differential Revision: https://reviews.llvm.org/D128328
show more ...
|
#
e8e46cdc |
| 27-Jul-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[NFC] [C++20] [Modules] Use Sema::isCurrentModulePurview() to simplify the codes
|
Revision tags: llvmorg-14.0.4 |
|
#
afda39a5 |
| 15-May-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
re-land [C++20][Modules] Build module static initializers per P1874R1.
The re-land fixes module map module dependencies seen on Greendragon, but not in the clang test suite.
---
Currently we only
re-land [C++20][Modules] Build module static initializers per P1874R1.
The re-land fixes module map module dependencies seen on Greendragon, but not in the clang test suite.
---
Currently we only implement this for the Itanium ABI since the correct mangling for the initializers in other ABIs is not yet known.
Intended result:
For a module interface [which includes partition interface and implementation units] (instead of the generic CXX initializer) we emit a module init that:
- wraps the contained initializations in a control variable to ensure that the inits only happen once, even if a module is imported many times by imports of the main unit.
- calls module initializers for imported modules first. Note that the order of module import is not significant, and therefore neither is the order of imported module initializers.
- We then call initializers for the Global Module Fragment (if present) - We then call initializers for the current module. - We then call initializers for the Private Module Fragment (if present)
For a module implementation unit, or a non-module TU that imports at least one module we emit a regular CXX init that:
- Calls the initializers for any imported modules first. - Then proceeds as normal with remaining inits.
For all module unit kinds we include a global constructor entry, this allows for the (in most cases unusual) possibility that a module object could be included in a final binary without a specific call to its initializer.
Implementation:
- We provide the module pointer in the AST Context so that CodeGen can act on it and its sub-modules.
- We need to account for module build lines like this: ` clang -cc1 -std=c++20 Foo.pcm -emit-obj -o Foo.o` or ` clang -cc1 -std=c++20 -xc++-module Foo.cpp -emit-obj -o Foo.o`
- in order to do this, we add to ParseAST to set the module pointer in the ASTContext, once we establish that this is a module build and we know the module pointer. To be able to do this, we make the query for current module public in Sema.
- In CodeGen, we determine if the current build requires a CXX20-style module init and, if so, we defer any module initializers during the "Eagerly Emitted" phase.
- We then walk the module initializers at the end of the TU but before emitting deferred inits (which adds any hidden and static ones, fixing https://github.com/llvm/llvm-project/issues/51873 ).
- We then proceed to emit the deferred inits and continue to emit the CXX init function.
Differential Revision: https://reviews.llvm.org/D126189
show more ...
|
#
b19d3ee7 |
| 11-Jul-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
Revert "[C++20][Modules] Build module static initializers per P1874R1."
This reverts commit ac507102d258b6fc0cb57eb60c9dfabd57ff562f.
reverting while we figuere out why one of the green dragon lldb
Revert "[C++20][Modules] Build module static initializers per P1874R1."
This reverts commit ac507102d258b6fc0cb57eb60c9dfabd57ff562f.
reverting while we figuere out why one of the green dragon lldb test fails.
show more ...
|
#
ac507102 |
| 15-May-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules] Build module static initializers per P1874R1.
Currently we only implement this for the Itanium ABI since the correct mangling for the initializers in other ABIs is not yet known.
I
[C++20][Modules] Build module static initializers per P1874R1.
Currently we only implement this for the Itanium ABI since the correct mangling for the initializers in other ABIs is not yet known.
Intended result:
For a module interface [which includes partition interface and implementation units] (instead of the generic CXX initializer) we emit a module init that:
- wraps the contained initializations in a control variable to ensure that the inits only happen once, even if a module is imported many times by imports of the main unit.
- calls module initializers for imported modules first. Note that the order of module import is not significant, and therefore neither is the order of imported module initializers.
- We then call initializers for the Global Module Fragment (if present) - We then call initializers for the current module. - We then call initializers for the Private Module Fragment (if present)
For a module implementation unit, or a non-module TU that imports at least one module we emit a regular CXX init that:
- Calls the initializers for any imported modules first. - Then proceeds as normal with remaining inits.
For all module unit kinds we include a global constructor entry, this allows for the (in most cases unusual) possibility that a module object could be included in a final binary without a specific call to its initializer.
Implementation:
- We provide the module pointer in the AST Context so that CodeGen can act on it and its sub-modules.
- We need to account for module build lines like this: ` clang -cc1 -std=c++20 Foo.pcm -emit-obj -o Foo.o` or ` clang -cc1 -std=c++20 -xc++-module Foo.cpp -emit-obj -o Foo.o`
- in order to do this, we add to ParseAST to set the module pointer in the ASTContext, once we establish that this is a module build and we know the module pointer. To be able to do this, we make the query for current module public in Sema.
- In CodeGen, we determine if the current build requires a CXX20-style module init and, if so, we defer any module initializers during the "Eagerly Emitted" phase.
- We then walk the module initializers at the end of the TU but before emitting deferred inits (which adds any hidden and static ones, fixing https://github.com/llvm/llvm-project/issues/51873 ).
- We then proceed to emit the deferred inits and continue to emit the CXX init function.
Differential Revision: https://reviews.llvm.org/D126189
show more ...
|
#
354a597b |
| 08-Jul-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[C++20] [Modules] Don't complain about duplicated default template argument across modules
See https://github.com/cplusplus/draft/pull/5204 for a detailed background.
Simply, the test redundant-
[C++20] [Modules] Don't complain about duplicated default template argument across modules
See https://github.com/cplusplus/draft/pull/5204 for a detailed background.
Simply, the test redundant-template-default-arg.cpp attached to this patch should be accepted instead of being complained about the redefinition.
Reviewed By: urnathan, rsmith, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D118034
show more ...
|
#
9c04851c |
| 29-Jun-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[C++20] [Module] Support reachable definition initially/partially
This patch introduces a new kind of ModuleOwnershipKind as ReachableWhenImported. This intended the status for reachable described a
[C++20] [Module] Support reachable definition initially/partially
This patch introduces a new kind of ModuleOwnershipKind as ReachableWhenImported. This intended the status for reachable described at: https://eel.is/c++draft/module.reach#3.
Note that this patch is not intended to support all semantics about reachable semantics. For example, this patch didn't implement discarded declarations in GMF. (https://eel.is/c++draft/module.global.frag#3).
This fixes: https://bugs.llvm.org/show_bug.cgi?id=52281 and https://godbolt.org/z/81f3ocjfW.
Reviewed By: rsmith, iains
Differential Revision: https://reviews.llvm.org/D113545
show more ...
|
#
7a541406 |
| 29-Jun-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
Revert "[C++20] [Modules] Implement Reachable initiallly"
This reverts commit a223ba0a697c1598b434cf2495c9cd9ec5640fc7.
The previous commit don't contain additional information, which is bad.
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
#
a223ba0a |
| 21-Feb-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[C++20] [Modules] Implement Reachable initiallly
|
#
92fed06f |
| 11-Apr-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules] Remove an empty statement [NFC].
This addresses a post commit review comment by removing an unused and empty 'else' (replaced with a comment).
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
#
f60dc3ca |
| 04-May-2021 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules] Adjust handling of exports of namespaces and using-decls.
This adjusts the handling for:
export module M;
export namespace {};
export namespace N {}; export using namespace N;
[C++20][Modules] Adjust handling of exports of namespaces and using-decls.
This adjusts the handling for:
export module M;
export namespace {};
export namespace N {}; export using namespace N;
In the first case, we were allowing empty anonymous namespaces as part of an extension allowing empty top-level entities, but that seems inappropriate in this case, since the linkage would be internal for the anonymous namespace. We now report an error for this.
The second case was producing a warning diagnostic that this was accepted as an extension - however the C++20 standard does allow this as well-formed.
In the third case we keep the current practice that this is accepted with a warning (as an extension). The C++20 standard says it's an error.
We also ensure that using decls are only applied to items with external linkage.
This adjusts error messages for exports involving redeclarations in modules to be more specific about the reason that the decl has been rejected.
Differential Revision: https://reviews.llvm.org/D122119
show more ...
|
#
d9cea8d3 |
| 02-Mar-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules][HU 4/5] Handle pre-processed header units.
We wish to support emitting a pre-processed output for an importable header unit, that can be consumed to produce the same header units as
[C++20][Modules][HU 4/5] Handle pre-processed header units.
We wish to support emitting a pre-processed output for an importable header unit, that can be consumed to produce the same header units as the original source.
This means that ee need to find the original filename used to produce the re-preprocessed output, so that it can be assigned as the module name. This is peeked from the first line of the pre-processed source when the action sets up the files.
Differential Revision: https://reviews.llvm.org/D121098
show more ...
|
#
cf396c56 |
| 24-Mar-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules] Correct an assert for modules-ts.
When adding the support for modules partitions we added an assert that the actual status of Global Module Fragments matches the state machine that
[C++20][Modules] Correct an assert for modules-ts.
When adding the support for modules partitions we added an assert that the actual status of Global Module Fragments matches the state machine that is driven by the module; keyword.
That does not apply to the modules-ts case, where there is an implicit GMF.
Differential Revision: https://reviews.llvm.org/D122394
show more ...
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3 |
|
#
6c0e60e8 |
| 20-Sep-2020 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules][HU 1/5] Introduce header units as a module type.
This is the first in a series of patches that introduce C++20 importable header units.
These differ from clang header modules in th
[C++20][Modules][HU 1/5] Introduce header units as a module type.
This is the first in a series of patches that introduce C++20 importable header units.
These differ from clang header modules in that: (a) they are identifiable by an internal name (b) they represent the top level source for a single header - although that might include or import other headers.
We name importable header units with the path by which they are specified (although that need not be the absolute path for the file).
So "foo/bar.h" would have a name "foo/bar.h". Header units are made a separate module type so that we can deal with diagnosing places where they are permitted but a named module is not.
Differential Revision: https://reviews.llvm.org/D121095
show more ...
|
#
8d093111 |
| 09-Mar-2022 |
Simon Pilgrim <llvm-dev@redking.me.uk> |
[clang] Sema::ActOnModuleImport - remove superfluous nullptr test
Mod has already been dereferenced
|
#
3eb2da76 |
| 02-Mar-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[NFC] [C++20] [Modules] Simplify ActOnModuleImport by merging Path and Parition
Reviewed By: iains
Differential Revision: https://reviews.llvm.org/D120793
|
#
b3fcfcb9 |
| 01-May-2021 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules][7/8] Find the primary interface name for a module.
When we are building modules, there are cases where the only way to determine validity of access is by comparing primary interface
[C++20][Modules][7/8] Find the primary interface name for a module.
When we are building modules, there are cases where the only way to determine validity of access is by comparing primary interface names. This is because we need to be able to associate a primary interface name with an imported partition, but before the primary interface module is complete - so that textual comparison is necessary.
If this turns out to be needed many times, we could cache the result, but it seems unlikely to be significant (at this time); cases with very many imported partitions would seem unusual.
Differential Revision: https://reviews.llvm.org/D118598
show more ...
|
#
853ca547 |
| 30-Jan-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules][6/8] Record direct module imports.
This is a small cache to avoid having to check both Exports and Imports.
Differential Revision: https://reviews.llvm.org/D118589
|
#
1a76d256 |
| 30-Jan-2022 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules][5/8] Diagnose wrong import/export for partition CMIs.
We cannot export partition implementation CMIs, but we can export the content of partition interface CMIs.
Differential Revisi
[C++20][Modules][5/8] Diagnose wrong import/export for partition CMIs.
We cannot export partition implementation CMIs, but we can export the content of partition interface CMIs.
Differential Revision: https://reviews.llvm.org/D118588
show more ...
|
#
61144914 |
| 07-Feb-2021 |
Iain Sandoe <iain@sandoe.co.uk> |
[C++20][Modules][4/8] Handle generation of partition implementation CMIs.
Partition implementations are special, they generate a CMI, but it does not have an 'export' line, and we cannot export anyt
[C++20][Modules][4/8] Handle generation of partition implementation CMIs.
Partition implementations are special, they generate a CMI, but it does not have an 'export' line, and we cannot export anything from the it [that is it can only make decls available to other members of the owning module, not to importers of that].
Add initial testcases for partition handling, derived from the examples in Section 10 of the C++20 standard, which identifies what should be accepted and/or rejected.
Differential Revision: https://reviews.llvm.org/D118587
show more ...
|