| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
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
|
|
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
|
|
|
|
|
|
This removes one use of the deprecated `DirectoryEntry::getName()`.
|
|
This removes some uses of the deprecated `DirectoryEntry::getName()`.
|
|
This patch changes the argument type to `HeaderSearch::LookupFile()` from `const DirectoryEntry *` to `DirectoryEntryRef` in order to remove some calls to the deprecated `DirectoryEntry::getName()`.
Depends on D127660.
Reviewed By: bnbarham, benlangmuir
Differential Revision: https://reviews.llvm.org/D127663
|
|
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
|
|
Previously, if a header was found via in a header map, and not just remapped.
we wouldn't also find the module it maps to when using implicit modules (for
module maps that were explicitly loaded).
This diff just updates these code paths to also locate the owning module via
`findUsableModuleForHeader`.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D103930
|
|
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
|
|
The issue was introduced in D135801. When there are only header maps in the SearchDirs,
the out of bounds value is assigned to FirstNonHeaderMapSearchDirIdx.
Test Plan: check-clang
Differential Revision: https://reviews.llvm.org/D146156
|
|
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
|
|
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).
|
|
|
|
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
|
|
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
|
|
This reverts commit 1dc0a1e5d220b83c1074204bd3afd54f3bac4270.
Failures were caused by unintentional conversion to native slashes by
remove_dots, so undo that: we always suggest posix slashes for includes.
This could potentially be a change in behavior on windows if people were
spelling headers with backslashes and headermaps contained backslashes,
but that's all underspecified and I don't think anyone uses headermaps
on windows.
Differential Revision: https://reviews.llvm.org/D138709
|
|
This reverts commit 8bed59c7e7da2fea41a9167e15c15a8f58a5ede7.
Breaks bots e.g. https://lab.llvm.org/buildbot/#/builders/216/builds/13282
|
|
Since D60873 we remove dotdots from the search path entries, but not the
filenames we're matching against, so do the latter too.
Since this also removes (single) dots, drop the logic to skip over them.
(Some of this was already dead, some is newly dead).
See D138676 for motivation.
Differential Revision: https://reviews.llvm.org/D138677
|
|
Correct D135801 to be case insensitive.
Differential Revision: https://reviews.llvm.org/D137179
|
|
AffectingModules
Rename module related things according to the consensus in
https://discourse.llvm.org/t/rfc-unifying-the-terminology-about-modules-in-clang/66054/
to reduce further confusings.
This only renames things I can make sure. It doesn't mean all the names
in Preprocessor are correct now.
|
|
This patch fixes a performance regression introduced in D121685 that was caused by copying `DirectoryLookup`.
rdar://101206790
Reviewed By: ributzka
Differential Revision: https://reviews.llvm.org/D136019
|
|
HeaderSearch already uses a caching system to avoid duplicate searches,
but the initial cold miss can take a long time if a build system has
supplied thousands of HeaderMaps. For this case, the SearchDirs vector
begins with those HeaderMaps, so a cache miss requires testing if the
sought filename is present in each of those maps. Instead, we can
consolidate the keys of those HeaderMaps into one StringMap and then
each cache miss can skip directly to the correct HeaderMap or continue
its search beyond the initial sequence of HeaderMaps. In testing on TUs
with ~15000 SearchDirs where the initial 99% are HeaderMaps, time spent
in Clang was reduced by 15%. This patch is expected to be neutral for
SearchDir vectors that do not begin with HeaderMaps.
Differential Revision: https://reviews.llvm.org/D135801
|
|
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
|
|
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
|
|
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
|
|
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
|
|
When compiling a module, its semantics and Clang's behavior are affected by other modules. These modules are typically the **imported** ones. However, during implicit build, some modules end up being compiled and read without being actually imported. This patch starts tracking such modules and serializing them into `.pcm` files. This enables the dependency scanner to construct explicit compilations that mimic implicit build.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D132430
|
|
In the case of static compilation the file system is pretty much read-only
and taking a snapshot of it usually is sufficient. In the interactive C++
case the compilation is longer and people can create and include files, etc.
In that case we often do not want to open files or cache failures unless is
absolutely necessary.
This patch extends the original API call by forwarding some optional flags,
so we can continue use it in the previous way with no breakage.
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D131241
|
|
|
|
This reverts commit 340654e0f246cddb3fb6ebddb843ade9bfcff0a5, essentially reapplying 1d3ba05e4a288b49287fe997763e90234b8c62db.
The test VFS/real-path-found-first.m that was failing on Windows is now passing with a workaround.
|
|
|
|
tapi & clang-extractapi both attempt to construct then check against
how a header was included to determine api information when working
against multiple search paths, headermap, and vfsoverlay mechanisms.
Validating this against what the preprocessor sees during lookup time
makes this check more reliable.
Reviewed By: zixuw, jansvoboda11
Differential Revision: https://reviews.llvm.org/D124638
|
|
This reverts commit 1d3ba05e4a288b49287fe997763e90234b8c62db which caused failures of the VFS/real-path-found-first.m test on Windows build bots.
|
|
This patch changes the member of `FrameworkCacheEntry` from `const DirectoryEntry *` to `Optional<DirectoryEntryRef>` in order to remove uses of the deprecated `DirectoryEntry::getName()`.
Reviewed By: bnbarham
Differential Revision: https://reviews.llvm.org/D123854
|
|
This patch removes uses of the deprecated `DirectoryEntry::getName()` from `HeaderSearch::load*()` functions by using `DirectoryEntryRef` instead.
Note that we bail out in one case and use the also deprecated `FileEntry::getLastRef()`. That's to prevent this patch from growing, and is addressed in a follow-up.
Reviewed By: bnbarham
Differential Revision: https://reviews.llvm.org/D123771
|
|
The dependency scanner can reuse single FileManager instance across multiple translation units. This may lead to non-deterministic output depending on which TU gets processed first.
One of the problems is that Clang uses DirectoryEntry::getName in the header search algorithm. This function returns the path that was first used to construct the (shared) entry in FileManager. Using DirectoryEntryRef::getName instead preserves the case as it was spelled out for the current "get directory entry" request.
rdar://90647508
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D123229
|
|
in filesystems
It is simpler to search for module unit by -fprebuilt-module-path
option. However, the separator ':' of partitions is not friendly.
According to the discussion in https://reviews.llvm.org/D118586, I think
we get consensus to use '-' as the separator instead. The '-' is the
choice of GCC too.
Previously I thought it would be better to add an option. But I feel it
is over-engineering now. Another reason here is that there are too many
options for modules (for clang module mainly) now. Given it is not bad
to use '-' when searching, I think it is acceptable to not add an
option.
Reviewed By: iains
Differential Revision: https://reviews.llvm.org/D120874
|
|
`HeaderSearch` currently assumes `LookupFileCache` is eventually populated in `LookupFile`. However, that's not always the case with `-fms-compatibility` and its early returns.
This patch adds a defensive check that the iterator pulled out of the cache is actually valid before using it.
(This bug was introduced in D119721. Before that, the cache was initialized to `0` - essentially the `search_dir_begin()` iterator.)
Reviewed By: dexonsmith, erichkeane
Differential Revision: https://reviews.llvm.org/D122237
|
|
The iterator is not needed after the loop body anymore, meaning we can use more terse range-based for loop.
Depends on D121295.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D121685
|
|
To reduce the number of modules we build in explicit builds (which use strict context hash), we prune unused header search paths. This essentially merges parts of the dependency graph.
Determining whether a search path was used to discover a module (through implicit module maps) proved to be somewhat complicated. Initial support landed in D102923, while D113676 attempts to fix some bugs.
However, now that we don't use implicit module maps in explicit builds (since D120465), we don't need to consider such search paths as used anymore. Modules are no longer discovered through the header search mechanism, so we can drop such search paths (provided they are not needed for other reasons).
This patch removes whatever support for detecting such usage we had, since it's buggy and not required anymore.
Depends on D120465.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D121295
|
|
This patch replaces a lot of index-based loops with iterators and ranges.
Depends on D117566.
Reviewed By: ahoppen
Differential Revision: https://reviews.llvm.org/D119722
|
|
This patch starts using the new iterator type in `LookupFileCacheInfo`.
Depends on D117566.
Reviewed By: ahoppen
Differential Revision: https://reviews.llvm.org/D119721
|
|
The `const DirectoryLookup *` out-parameter of `{HeaderSearch,Preprocessor}::LookupFile()` is assigned the most recently used search directory, which callers use to implement `#include_next`.
From the function signature it's not obvious the `const DirectoryLookup *` is being used as an iterator. This patch introduces `ConstSearchDirIterator` to make that affordance obvious. This would've prevented a bug that occurred after initially landing D116750.
Reviewed By: ahoppen
Differential Revision: https://reviews.llvm.org/D117566
|
|
C++ module
An impilt used of C++ module without prebuild path may cause crash.
For example:
```
// ./dir1/C.cppm
export module C;
// ./dir2/B.cppm
export module B;
import C;
// ./A.cpp
import B;
import C;
```
When we compile A.cpp without the prebuild path of C.pcm, the compiler
will crash.
```
clang++ -std=c++20 --precompile -c ./dir1/C.cppm -o ./dir1/C.pcm
clang++ -std=c++20 --precompile -fprebuilt-module-path=./dir2 -c
./dir2/B.cppm -o ./dir2/B.pcm
clang++ -std=c++20 -fprebuilt-module-path=./dir2 A.cpp
```
The prebuilt path of module C is cached when import module B, and in the
function HeaderSearch::getCachedModuleFileName, the compiler try to get
the filename by modulemap without check if modulemap exists, and there
is no modulemap in C++ module.
Reviewed By: ChuanqiXu
Differential review: https://reviews.llvm.org/D119426
|
|
Previously, the Framework name was only set if the file
came from a header mapped framework; now we'll always
set the framework name if the file is in a framework.
Differential Revision: https://reviews.llvm.org/D117830
|
|
This patch replaces the exact include count of each file in `HeaderFileInfo` with a set of included files in `Preprocessor`.
The number of includes isn't a property of a header file but rather a preprocessor state. The exact number of includes is not used anywhere except statistic tracking.
Reviewed By: vsapsai
Differential Revision: https://reviews.llvm.org/D114095
|
|
The `{HeaderSearch,Preprocessor}::LookupFile()` functions take an out-parameter `const DirectoryLookup *&`. Most callers end up creating a `const DirectoryLookup *` variable that's otherwise unused.
This patch changes the out-parameter from reference to a pointer, making it possible to simply pass `nullptr` to the function without the ceremony.
Reviewed By: ahoppen
Differential Revision: https://reviews.llvm.org/D117312
|
|
This reverts commit 8503c688. This patch causes some issues with `#include_next`: https://github.com/llvm/llvm-project/issues/53161
|
