History log of /llvm-project/clang/lib/Sema/SemaModule.cpp (Results 51 – 75 of 98)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


1234