Silence unused variable warning in NDEBUG builds

I usually would fold this into the assert, but the comment there
suggests side effects. NFC.

ModuleMap.cpp:938:9: error: unused variable 'MainFile'

Silence unused variable warning in NDEBUG builds

I usually would fold this into the assert, but the comment there
suggests side effects. NFC.

ModuleMap.cpp:938:9: error: unused variable 'MainFile' [-Werror,-Wunused-variable]
auto *MainFile = SourceMgr.getFileEntryForID(SourceMgr.getMainFileID());

show more ...

[C++20][Modules] Introduce an implementation module.

We need to be able to distinguish individual TUs from the same module in cases
where TU-local entities either need to be hidden (or, for some cas

[C++20][Modules] Introduce an implementation module.

We need to be able to distinguish individual TUs from the same module in cases
where TU-local entities either need to be hidden (or, for some cases of ADL in
template instantiation, need to be detected as exposures).

This creates a module type for the implementation which implicitly imports its
primary module interface per C++20:
[module.unit/8] 'A module-declaration that contains neither an export-keyword
nor a module-partition implicitly imports the primary module interface unit of
the module as if by a module-import-declaration.

Implementation modules are never serialized (-emit-module-interface for an
implementation unit is diagnosed and rejected).

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

show more ...

[clang] Unconditionally add autolink hints for frameworks.

Clang infers framework autolink hints when parsing a modulemap. In order to do
so, it checks if the module is a framework and if there is a

[clang] Unconditionally add autolink hints for frameworks.

Clang infers framework autolink hints when parsing a modulemap. In order to do
so, it checks if the module is a framework and if there is a framework binary
or TBD file in the SDK. Only when Clang finds the filei, then the autolink hint
is added to the module metadata.

During a project build many clang processes perform this check, which causes
many stat calls - even for modules/frameworks that are not even used.

The linker is already resilient to non-existing framework links that come from
the autolink metadata, so there is no need for Clang to do this check.

Instead the autolink hints are now added unconditionally and the linker only
needs to do the check once. This reduces the overall number of stat calls.

This fixes rdar://106578342.

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

show more ...

[C++20] [Modules] Support to export declarations in language linkage

Close https://github.com/llvm/llvm-project/issues/60405

See the discussion in the above link for the background.

What the patch

[C++20] [Modules] Support to export declarations in language linkage

Close https://github.com/llvm/llvm-project/issues/60405

See the discussion in the above link for the background.

What the patch does:
- Rename `Module::ModuleKind::GlobalModuleFragment` to
`Module::ModuleKind::ExplicitGlobalModuleFragment`.
- Add another module kind `ImplicitGlobalModuleFragment` to
`ModuleKind`.
- Create an implicit global module fragment for the language linkage
declarations inside a module purview.
- If the language linkage lives inside the scope of an export decl,
the created modules is marked as exported to outer modules.
- In fact, Sema will only create at most 2 implicit global module
fragments to avoid creating a lot of unnecessary modules in the edging
case.

Reviewed By: iains

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

show more ...

[Clang] Improve error message for violations of -fmodules-decluse.

Now it reports the name of the indirectly-used module which is
missing.

Reviewed By: ChuanqiXu

Differential Revision: https://rev

[Clang] Improve error message for violations of -fmodules-decluse.

Now it reports the name of the indirectly-used module which is
missing.

Reviewed By: ChuanqiXu

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

show more ...

[clang][nfc] refactor Module::Header to use OptionalFileEntryRef

Refactor the `Module::Header` class to use an `OptionalFileEntryRef`
instead of a `FileEntry*`. This is preparation for refactoring t

[clang][nfc] refactor Module::Header to use OptionalFileEntryRef

Refactor the `Module::Header` class to use an `OptionalFileEntryRef`
instead of a `FileEntry*`. This is preparation for refactoring the
`TopHeaderNames` to use `FileEntryRef` so that we preserve the
lookup path of the headers when serializing.

This is mostly based on https://reviews.llvm.org/D90497

Reviewed By: jansvoboda11

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

show more ...

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is p

[clang] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Option

[clang] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[Clang] Prepare for llvm::Optional becoming std::optional.

The needed tweaks are mostly trivial, the one nasty bit is Clang's usage
of OptionalStorage. To keep this working old Optional stays around

[Clang] Prepare for llvm::Optional becoming std::optional.

The needed tweaks are mostly trivial, the one nasty bit is Clang's usage
of OptionalStorage. To keep this working old Optional stays around as
clang::CustomizableOptional, with the default Storage removed.
Optional<File/DirectoryEntryRef> is replaced with a typedef.

I tested this with GCC 7.5, the oldest supported GCC I had around.

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

show more ...

Revert "[clang] Convert OptionalFileEntryRefDegradesToFileEntryPtr to std::optional"

This reverts commit 8f0df9f3bbc6d7f3d5cbfd955c5ee4404c53a75d.

The Optional*RefDegradesTo*EntryPtr types want to

Revert "[clang] Convert OptionalFileEntryRefDegradesToFileEntryPtr to std::optional"

This reverts commit 8f0df9f3bbc6d7f3d5cbfd955c5ee4404c53a75d.

The Optional*RefDegradesTo*EntryPtr types want to keep the same size as
the underlying type, which std::optional doesn't guarantee. For use with
llvm::Optional, they define their own storage class, and there is no way
to do that in std::optional.

On top of that, that commit broke builds with older GCCs, where
std::optional was not trivially copyable (static_assert in the clang
sources was failing).

show more ...

[clang] Convert OptionalFileEntryRefDegradesToFileEntryPtr to std::optional

llvm::Optional::value => operator*/operator->

std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The

llvm::Optional::value => operator*/operator->

std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The
call sites block std::optional migration.

This makes `ninja clang` work in the absence of llvm::Optional::value.

show more ...

Don't include None.h (NFC)

I've converted all known uses of None to std::nullopt, so we no longer
need to include None.h.

This is part of an effort to migrate from llvm::Optional to
std::optional:

Don't include None.h (NFC)

I've converted all known uses of None to std::nullopt, so we no longer
need to include None.h.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[clang] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of m

[clang] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[clang][deps][lex] Avoid canonicalization of remapped framework directories

In D134923, the scanner introduced canonicalization of framework directories when reporting module map paths in order to i

[clang][deps][lex] Avoid canonicalization of remapped framework directories

In D134923, the scanner introduced canonicalization of framework directories when reporting module map paths in order to increase module sharing. However, if we canonicalize framework directory that plays a role in a VFS remapping, and later try to use that module map to build the module, header lookup can fail. This happens when the module headers are remapped using the original framework path.

This patch fixes that. The implementation relies on the fact that the chain of directories in VFS remapping are assigned `DirectoryEntry` objects distinct from their on-disk counterparts. If we detect that case, we avoid the canonicalization.

Reviewed By: benlangmuir

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

show more ...

[C++20] [Modules] Remove unmaintained Header Module

Currently there is a -emit-header-module mode, which can combine several
headers together as a module interface. However, this breaks our
assumpti

[C++20] [Modules] Remove unmaintained Header Module

Currently there is a -emit-header-module mode, which can combine several
headers together as a module interface. However, this breaks our
assumption (for standard c++ modules) about module interface. The module
interface should come from a module interface unit. And if it is a
header, it should be a header unit. And currently we have no ideas to
combine several headers together.

So I think this mode is an experimental one and it is not maintained and
it is not used. So it will be better to remove them.

Reviewed By: Bigcheese, dblaikie, bruno

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

show more ...

[NFC] [C++20] [Modules] Remove unused Global Module Fragment variables/arguments

[clang][modules] Fix handling of `ModuleHeaderRole::ExcludedHeader`

This is a follow-up to D134224. The original patch added new `ExcludedHeader` enumerator to `ModuleMap::ModuleHeaderRole` and star

[clang][modules] Fix handling of `ModuleHeaderRole::ExcludedHeader`

This is a follow-up to D134224. The original patch added new `ExcludedHeader` enumerator to `ModuleMap::ModuleHeaderRole` and started associating headers with the modules they were excluded from. This was necessary to consider their module maps as "affecting" in certain situations and in turn serialize them into the PCM.

The association of the header and module needs to be handled when deserializing the PCM as well, though. This patch fixes a potential assertion failure and a regression. This essentially reverts parts of feb54b6ded123f8118fdc20620d3f657dfeab485.

Reviewed By: Bigcheese

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

show more ...

[clang][deps] Canonicalize module map path

When dep-scanning, canonicalize the module map path as much as we can.
This avoids unnecessarily needing to build multiple versions of a module
due to syml

[clang][deps] Canonicalize module map path

When dep-scanning, canonicalize the module map path as much as we can.
This avoids unnecessarily needing to build multiple versions of a module
due to symlinks or case-insensitive file paths.

Despite the name `tryGetRealPathName`, the previous implementation did
not actually return the realpath most of the time, and indeed it would
be incorrect to do so since the realpath could be outside the module
directory, which would have broken finding headers relative to the
module.

Instead, use a canonicalization that is specific to the needs of
modulemap files (canonicalize the directory separately from the
filename).

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

show more ...

[clang] Update ModuleMap::getModuleMapFile* to use FileEntryRef

Update SourceManager::ContentCache::OrigEntry to keep the original
FileEntryRef, and use that to enable ModuleMap::getModuleMapFile* t

[clang] Update ModuleMap::getModuleMapFile* to use FileEntryRef

Update SourceManager::ContentCache::OrigEntry to keep the original
FileEntryRef, and use that to enable ModuleMap::getModuleMapFile* to
return the original FileEntryRef. This change should be NFC for
most users of SourceManager::ContentCache, but it could affect behaviour
for users of getNameAsRequested such as in compileModuleImpl. I have not
found a way to detect that difference without additional functional
changes, other than incidental cases like changes from / to \ on
Windows so there is no new test.

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

show more ...

[clang][modules][deps] Report modulemaps describing excluded headers

Module map files describing excluded headers do affect compilation. Track them in the compiler, serialize them into the PCM file

[clang][modules][deps] Report modulemaps describing excluded headers

Module map files describing excluded headers do affect compilation. Track them in the compiler, serialize them into the PCM file and report them in the scanner.

Depends on D134222.

Reviewed By: Bigcheese

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

show more ...

[clang][modules] Don't hard code [no_undeclared_includes] for the Darwin module

The Darwin module has specified [no_undeclared_includes] for at least five years now, there's no need to hard code it

[clang][modules] Don't hard code [no_undeclared_includes] for the Darwin module

The Darwin module has specified [no_undeclared_includes] for at least five years now, there's no need to hard code it in the compiler.

Reviewed By: ributzka, Bigcheese

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

show more ...

[clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFC

With C++17 there is no Clang pedantic warning or MSVC C5051.

Reviewed By: aaron.ballman

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

Use any_of (NFC)

[clang] Use value instead of getValue (NFC)