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 ...

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 ...

[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 ...

[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 ...

[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 ...

Revert "[C++20] [Modules] Implement Reachable initiallly"

This reverts commit a223ba0a697c1598b434cf2495c9cd9ec5640fc7.

The previous commit don't contain additional information, which is bad.

[C++20] [Modules] Implement Reachable initiallly

[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).

[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 ...

[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 ...

[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 ...

[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 ...

[clang] Sema::ActOnModuleImport - remove superfluous nullptr test

Mod has already been dereferenced

[NFC] [C++20] [Modules] Simplify ActOnModuleImport by merging Path and Parition

Reviewed By: iains

Differential Revision: https://reviews.llvm.org/D120793

[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 ...

[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

[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 ...

[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 ...

[Sema] Silence unused variable warning in Release builds. NFC.

[C++20][Modules][3/8] Initial handling for module partitions.

This implements the parsing and recognition of module partition CMIs
and removes the FIXMEs in the parser.

Module partitions are recogn

[C++20][Modules][3/8] Initial handling for module partitions.

This implements the parsing and recognition of module partition CMIs
and removes the FIXMEs in the parser.

Module partitions are recognised in the base computation of visibility,
however additional amendments to visibility follow in subsequent patches.

Differential Revision: https://reviews.llvm.org/D118586

show more ...

[C++20][Modules][2/8] Add enumerations for partition modules and stream them.

This is an initial enabling patch for module partition support.
We add enumerations for partition interfaces/implementat

[C++20][Modules][2/8] Add enumerations for partition modules and stream them.

This is an initial enabling patch for module partition support.
We add enumerations for partition interfaces/implementations.

This means that the module kind enumeration now occupies three
bits, so the AST streamer is adjusted for this. Adding one bit there
seems preferable to trying to overload the meanings of existing
kinds (and we will also want to add a C++20 header unit case later).

Differential Revision: https://reviews.llvm.org/D114714

show more ...

[C++20][Modules][1/8] Track valid import state.

In C++20 modules imports must be together and at the start of the module.
Rather than growing more ad-hoc flags to test state, this keeps track of the

[C++20][Modules][1/8] Track valid import state.

In C++20 modules imports must be together and at the start of the module.
Rather than growing more ad-hoc flags to test state, this keeps track of the
phase of of a valid module TU (first decl, global module frag, module,
private module frag). If the phasing is broken (with some diagnostic) the
pattern does not conform to a valid C++20 module, and we set the state
accordingly.

We can thus issue diagnostics when imports appear in the wrong places and
decouple the C++20 modules state from other module variants (modules-ts and
clang modules). Additionally, we attempt to diagnose wrong imports before
trying to find the module where possible (the latter will generally emit an
unhelpful diagnostic about the module not being available).

Although this generally simplifies the handling of C++20 module import
diagnostics, the motivation was that, in particular, it allows detecting
invalid imports like:

import module A;

int some_decl();

import module B;

where being in a module purview is insufficient to identify them.

Differential Revision: https://reviews.llvm.org/D118893

show more ...

Revert "[C++20][Modules][1/8] Track valid import state."

This reverts commit 8a3f9a584ad43369cf6a034dc875ebfca76d9033.

need to investigate build failures that do not show on CI or local
testing.

[C++20][Modules][1/8] Track valid import state.

In C++20 modules imports must be together and at the start of the module.
Rather than growing more ad-hoc flags to test state, this keeps track of the

[C++20][Modules][1/8] Track valid import state.

In C++20 modules imports must be together and at the start of the module.
Rather than growing more ad-hoc flags to test state, this keeps track of the
phase of of a valid module TU (first decl, global module frag, module,
private module frag). If the phasing is broken (with some diagnostic) the
pattern does not conform to a valid C++20 module, and we set the state
accordingly.

We can thus issue diagnostics when imports appear in the wrong places and
decouple the C++20 modules state from other module variants (modules-ts and
clang modules). Additionally, we attempt to diagnose wrong imports before
trying to find the module where possible (the latter will generally emit an
unhelpful diagnostic about the module not being available).

Although this generally simplifies the handling of C++20 module import
diagnostics, the motivation was that, in particular, it allows detecting
invalid imports like:

import module A;

int some_decl();

import module B;

where being in a module purview is insufficient to identify them.

Differential Revision: https://reviews.llvm.org/D118893

show more ...

[C++20] [Modules] Don't create multiple global module fragment

Since the serialization code would recognize modules by names and the
name of all global module fragment is <global>, so that the
seria

[C++20] [Modules] Don't create multiple global module fragment

Since the serialization code would recognize modules by names and the
name of all global module fragment is <global>, so that the
serialization code would complain for the same module.

This patch fixes this by using a unique global module fragment in Sema.
Before this patch, the compiler would fail on an assertion complaining
the duplicated modules.

Reviewed By: urnathan, rsmith

Differential Revision: https://reviews.llvm.org/D115610

show more ...