[clang] NFCI: Use `FileEntryRef` in `ModuleMapCallbacks`

[clang] NFCI: Use `FileEntryRef` in `ModuleMap`

[clang] NFCI: Use `FileEntryRef` in `ModuleMapParser`

[clang][modules] Respect "-fmodule-name=" when serializing included files into a PCH

Clang writes the set of textually included files into AST files, so that importers know to avoid including those

[clang][modules] Respect "-fmodule-name=" when serializing included files into a PCH

Clang writes the set of textually included files into AST files, so that importers know to avoid including those files again and instead deserialize their contents from the AST on-demand.

Logic for determining the set of included files files only considers headers that are either non-modular or that are modular but with `HeaderFileInfo::isCompilingModuleHeader` set. Logic for computing that bit is different than the one that determines whether to include a header textually with the "-fmodule-name=Mod" option. That can lead to header from module "Mod" being included textually in a PCH, but be omitted in the serialized set of included files. This can then allow such header to be textually included from importer of the PCH, wreaking havoc.

This patch fixes that by aligning the logic for computing `HeaderFileInfo::isCompilingModuleHeader` with the logic for deciding whether to include modular header textually.

As far as I can tell, this bug has been in Clang for forever. It got accidentally "fixed" by D114095 (that changed the logic for determining the set of included files) and got broken again in D155131 (which is essentially a revert of the former).

rdar://113520515

Reviewed By: benlangmuir

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

show more ...

[NFC] Remove needless nullchecks.

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

[clang][modules] Skip submodule & framework re-definitions in module maps

Before D150478, there were situations when Clang avoided parsing a module map because it was likely to re-define an already

[clang][modules] Skip submodule & framework re-definitions in module maps

Before D150478, there were situations when Clang avoided parsing a module map because it was likely to re-define an already defined module (either by a PCM or by previously-found module map). Since Clang no longer performs that check and does parse the extra module map (due to the FW/FW_Private issue described in D150478), this patch re-implements the same semantics by skipping the duplicate definition of the framework module while parsing the module map.

Depends on D150478.

Reviewed By: benlangmuir

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

show more ...

[clang][modules] Serialize `Module::DefinitionLoc`

This is a prep patch for avoiding the quadratic number of calls to `HeaderSearch::lookupModule()` in `ASTReader` for each (transitively) loaded PCM

[clang][modules] Serialize `Module::DefinitionLoc`

This is a prep patch for avoiding the quadratic number of calls to `HeaderSearch::lookupModule()` in `ASTReader` for each (transitively) loaded PCM file. (Specifically in the context of `clang-scan-deps`).

This patch explicitly serializes `Module::DefinitionLoc` so that we can stop relying on it being filled by the module map parser. This change also required change to the module map parser, where we used the absence of `DefinitionLoc` to determine whether a file came from a PCM file. We also need to make sure we consider the "containing" module map affecting when writing a PCM, so that it's not stripped during serialization, which ensures `DefinitionLoc` still ends up pointing to the correct offset. This is intended to be a NFC change.

Reviewed By: benlangmuir

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

show more ...

[clang] Implement `PointerLikeTraits` for `{File,Directory}EntryRef`

This patch implements `llvm::PointerLikeTraits<FileEntryRef>` and `llvm::PointerLikeTraits<DirectoryEntryRef>`, allowing some sim

[clang] Implement `PointerLikeTraits` for `{File,Directory}EntryRef`

This patch implements `llvm::PointerLikeTraits<FileEntryRef>` and `llvm::PointerLikeTraits<DirectoryEntryRef>`, allowing some simplifications around umbrella header/directory code.

Reviewed By: benlangmuir

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

show more ...

[llvm][vfs] For virtual directories, use the virtual path as the real path

A follow-up to D135841. This patch returns the virtual path for directories from `RedirectingFileSystem`. This ensures the

[llvm][vfs] For virtual directories, use the virtual path as the real path

A follow-up to D135841. This patch returns the virtual path for directories from `RedirectingFileSystem`. This ensures the contents of `Path` are the same as the contents of `FS->getRealPath(Path)`. This also means we can drop the workaround in Clang's module map canonicalization, where we couldn't use the real path for a directory if it resolved to a different `DirectoryEntry`. In addition to that, we can also avoid introducing new workaround for a bug triggered by the newly introduced test case.

Reviewed By: benlangmuir

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

show more ...

[clang] NFC: Use `DirectoryEntryRef` in `FileManager::getCanonicalName()`

This patch removes the last use of deprecated `DirectoryEntry::getName()`.

Depends on D151855.

Reviewed By: benlangmuir

D

[clang] NFC: Use `DirectoryEntryRef` in `FileManager::getCanonicalName()`

This patch removes the last use of deprecated `DirectoryEntry::getName()`.

Depends on D151855.

Reviewed By: benlangmuir

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

show more ...

[clang] Use `{File,Directory}EntryRef` in modular header search (part 2/2)

This patch removes some deprecated uses of `{File,Directory}Entry::getName()`. No functional change intended.

Depends on D

[clang] Use `{File,Directory}EntryRef` in modular header search (part 2/2)

This patch removes some deprecated uses of `{File,Directory}Entry::getName()`. No functional change intended.

Depends on D151854.

Reviewed By: benlangmuir

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

show more ...

[clang] Use `FileEntryRef` in modular header search (part 1/2)

This patch removes some deprecated uses of `{File,Directory}Entry::getName()`. No functional change indended.

Depends on D151853.

Rev

[clang] Use `FileEntryRef` in modular header search (part 1/2)

This patch removes some deprecated uses of `{File,Directory}Entry::getName()`. No functional change indended.

Depends on D151853.

Reviewed By: benlangmuir

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

show more ...

[clang] NFCI: Split `HeaderSearch::findAllModulesForHeader()`

This mimics the `ModuleMap` API and enables D151854, where the `AllowCreation = true` function needs `FileEntryRef` but `AllowCreation =

[clang] NFCI: Split `HeaderSearch::findAllModulesForHeader()`

This mimics the `ModuleMap` API and enables D151854, where the `AllowCreation = true` function needs `FileEntryRef` but `AllowCreation = false` functions is happy with plain `FileEntry`. No functional change intended.

Reviewed By: benlangmuir

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

show more ...

[clang] NFCI: Use `FileEntryRef` in `ModuleMapCallbacks`

This patch removes path hackery from `ModuleMapCallbacks` by adopting `FileEntryRef`. No functional change intended.

Reviewed By: benlangmui

[clang] NFCI: Use `FileEntryRef` in `ModuleMapCallbacks`

This patch removes path hackery from `ModuleMapCallbacks` by adopting `FileEntryRef`. No functional change intended.

Reviewed By: benlangmuir

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

show more ...

[clang][modules] NFCI: Extract optionality out of `Module::{Header,DirectoryName}`

Most users of `Module::Header` already assume its `Entry` is populated. Enforce this assumption in the type system

[clang][modules] NFCI: Extract optionality out of `Module::{Header,DirectoryName}`

Most users of `Module::Header` already assume its `Entry` is populated. Enforce this assumption in the type system and handle the only case where this is not the case by wrapping the whole struct in `std::optional`. Do the same for `Module::DirectoryName`.

Depends on D151584.

Reviewed By: benlangmuir

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

show more ...

[clang] NFCI: Use DirectoryEntryRef in Module::Directory

This patch changes the type of `Module::Directory` from `const DirectoryEntry *` to (essentially) `Optional<DirectoryEntryRef>` in order to r

[clang] NFCI: Use DirectoryEntryRef in Module::Directory

This patch changes the type of `Module::Directory` from `const DirectoryEntry *` to (essentially) `Optional<DirectoryEntryRef>` in order to remove uses of the deprecated `DirectoryEntry::getName()`.

Depends on D127651.

Reviewed By: bnbarham

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

show more ...

[clang][lex] NFCI: Use DirectoryEntryRef in ModuleMap::parseModuleMapFile()

This patch changes the argument type of `ModuleMap::parseModuleMapFile()` from `const DirectoryEntry *` to `DirectoryEntry

[clang][lex] NFCI: Use DirectoryEntryRef in ModuleMap::parseModuleMapFile()

This patch changes the argument type of `ModuleMap::parseModuleMapFile()` from `const DirectoryEntry *` to `DirectoryEntryRef` in order to remove the deprecated uses of `DirectoryEntry::getName()`.

Depends on D127648.

Reviewed By: bnbarham

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

show more ...

[clang][lex] NFCI: Use DirectoryEntryRef in ModuleMap::inferFrameworkModule()

This patch changes the argument type of `ModuleMap::inferFrameworkModule()` from `const DirectoryEntry *` to `DirectoryE

[clang][lex] NFCI: Use DirectoryEntryRef in ModuleMap::inferFrameworkModule()

This patch changes the argument type of `ModuleMap::inferFrameworkModule()` from `const DirectoryEntry *` to `DirectoryEntryRef` in order to remove the deprecated uses of `DirectoryEntry::getName()`.

Depends on D127647.

Reviewed By: bnbarham

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

show more ...

[clang][lex] NFCI: Use FileEntryRef in ModuleMap::{load,lookup}ModuleMap()

This patch changes the return/argument types of `ModuleMap::{load,lookup}ModuleMap()` from `const FileEntry *` to `FileEntr

[clang][lex] NFCI: Use FileEntryRef in ModuleMap::{load,lookup}ModuleMap()

This patch changes the return/argument types of `ModuleMap::{load,lookup}ModuleMap()` from `const FileEntry *` to `FileEntryRef` in order to remove uses of the deprecated `DirectoryEntry::getName()`.

Reviewed By: bnbarham

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

show more ...

[clang][modules] NFCI: Use `DirectoryEntryRef` for umbrella directory

This removes some deprecated uses of `DirectoryEntry::getName()`.

Depends on D151581.

Differential Revision: https://reviews.l

[clang][modules] NFCI: Use `DirectoryEntryRef` for umbrella directory

This removes some deprecated uses of `DirectoryEntry::getName()`.

Depends on D151581.

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

show more ...

[clang][modules] NFCI: Distinguish as-written and effective umbrella directories

For modules with umbrellas, we track how they were written in the module map. Unfortunately, the getter for the umbre

[clang][modules] NFCI: Distinguish as-written and effective umbrella directories

For modules with umbrellas, we track how they were written in the module map. Unfortunately, the getter for the umbrella directory conflates the "as written" directory and the "effective" directory (either the written one or the parent of the written umbrella header).

This patch makes the distinction between "as written" and "effective" umbrella directories clearer. No functional change intended.

Reviewed By: benlangmuir

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

show more ...

[clang] Prevent creation of new submodules in ASTWriter

Avoid inferring new submodules for headers in ASTWriter's collection of
affecting modulemap files, since we don't want to pick up dependencies

[clang] Prevent creation of new submodules in ASTWriter

Avoid inferring new submodules for headers in ASTWriter's collection of
affecting modulemap files, since we don't want to pick up dependencies
that didn't actually exist during parsing.

rdar://109112624

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

show more ...

re-land [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

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

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

This reverts commit c6e9823724ef6bdfee262289ee34d162db436af0.

Reason: Broke the ASan buildbots, see https://reviews.llvm.org/D126959
(t

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

This reverts commit c6e9823724ef6bdfee262289ee34d162db436af0.

Reason: Broke the ASan buildbots, see https://reviews.llvm.org/D126959
(the original phabricator review) for more info.

show more ...

Revert "Silence unused variable warning in NDEBUG builds"

This reverts commit 8c7c1f11ffaacf762e612c65440fd2cbb58ee426.

Reason: Dependent change https://reviews.llvm.org/D126959 broke the ASan
buil

Revert "Silence unused variable warning in NDEBUG builds"

This reverts commit 8c7c1f11ffaacf762e612c65440fd2cbb58ee426.

Reason: Dependent change https://reviews.llvm.org/D126959 broke the ASan
buildbots. See that phabricator review for more comments.

show more ...