History log of /llvm-project/clang/lib/Basic/FileManager.cpp (Results 51 – 75 of 245)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3
# 466f8843 18-Feb-2020 Jim Lin <tclin914@gmail.com>

[NFC] Remove trailing space

sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h,td}


Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1
# adcd0268 28-Jan-2020 Benjamin Kramer <benny.kra@googlemail.com>

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...


Revision tags: llvmorg-11-init
# e8efac4b 20-Dec-2019 Karl-Johan Karlsson <karl-johan.karlsson@ericsson.com>

[clang] Fix the canonicalization of paths in -fdiagnostics-absolute-paths

In the current implementation of clang the canonicalization of paths in
diagnostic messages (when using -fdiagnostics-absolu

[clang] Fix the canonicalization of paths in -fdiagnostics-absolute-paths

In the current implementation of clang the canonicalization of paths in
diagnostic messages (when using -fdiagnostics-absolute-paths) only works
if the symbolic link is in the directory part of the filename, not if
the file itself is a symbolic link to another file.

This patch adds support to canonicalize the complete path including the
file.

Reviewers: rsmith, hans, rnk, ikudrin

Reviewed By: rnk

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

show more ...


Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1
# b3144145 08-Nov-2019 Alex Suhan <asuhan@google.com>

Basic: fix FileManager invalidation issue for file redirect

Insertion into SeenFileEntries can invalidate iterators, we need to do
another lookup on the re-intern path.


# e8752a9d 11-Oct-2019 Volodymyr Sapsai <vsapsai@apple.com>

[Stats] Convert some ad-hoc header search stats to ALWAYS_ENABLED_STATISTIC.

rdar://problem/55715134

Reviewers: dsanders, bogner, rtereshin

Reviewed By: dsanders

Subscribers: hiraditya, jkorous,

[Stats] Convert some ad-hoc header search stats to ALWAYS_ENABLED_STATISTIC.

rdar://problem/55715134

Reviewers: dsanders, bogner, rtereshin

Reviewed By: dsanders

Subscribers: hiraditya, jkorous, dexonsmith, ributzka, cfe-commits, llvm-commits

Tags: #llvm

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

llvm-svn: 374581

show more ...


Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4
# 0377ca64 31-Aug-2019 Alex Lorenz <arphaman@gmail.com>

Introduce a DirectoryEntryRef that stores both a reference and an
accessed name to the directory entry

This commit introduces a parallel API that returns a DirectoryEntryRef
to the FileManager, simi

Introduce a DirectoryEntryRef that stores both a reference and an
accessed name to the directory entry

This commit introduces a parallel API that returns a DirectoryEntryRef
to the FileManager, similar to the parallel FileEntryRef API. All
uses will have to be update in follow-up patches. The immediate use of the new API in this
patch fixes the issue where a file manager was reused in clang-scan-deps,
but reported an different file path whenever a framework lookup was done through a symlink.

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

llvm-svn: 370562

show more ...


# e1b7f22b 30-Aug-2019 Duncan P. N. Exon Smith <dexonsmith@apple.com>

ASTReader: Bypass overridden files when reading PCHs

If contents of a file that is part of a PCM are overridden when reading
it, but weren't overridden when the PCM was being built, the ASTReader
wi

ASTReader: Bypass overridden files when reading PCHs

If contents of a file that is part of a PCM are overridden when reading
it, but weren't overridden when the PCM was being built, the ASTReader
will emit an error. Now it creates a separate FileEntry for recovery,
bypassing the overridden content instead of discarding it. The
pre-existing testcase clang/test/PCH/remap-file-from-pch.cpp confirms
that the new recovery method works correctly.

This resolves a long-standing FIXME to avoid hypothetically invalidating
another precompiled module that's already using the overridden contents.

This also removes ContentCache-related API that would be unsafe to use
across `CompilerInstance`s in an implicit modules build. This helps to
unblock us sinking it from SourceManager into FileManager in the future,
which would allow us to delete `InMemoryModuleCache`.

https://reviews.llvm.org/D66710

llvm-svn: 370546

show more ...


# 122705b9 30-Aug-2019 Duncan P. N. Exon Smith <dexonsmith@apple.com>

FileManager: Remove ShouldCloseOpenFile argument from getBufferForFile, NFC

Remove this dead code. We always close it.

llvm-svn: 370488


Revision tags: llvmorg-9.0.0-rc3
# 0785f8d0 29-Aug-2019 Volodymyr Sapsai <vsapsai@apple.com>

Remove `FileManager::invalidateCache` as it has no callers anymore. NFC.

llvm-svn: 370400


# 9ef6c49b 26-Aug-2019 Duncan P. N. Exon Smith <dexonsmith@apple.com>

FileManager: Use llvm::Expected in new getFileRef API

`FileManager::getFileRef` is a modern API which we expect to convert to
over time. We should modernize the error handling as well, using
`llvm:

FileManager: Use llvm::Expected in new getFileRef API

`FileManager::getFileRef` is a modern API which we expect to convert to
over time. We should modernize the error handling as well, using
`llvm::Expected` instead of `llvm::ErrorOr`, to help clients that care
about errors to ensure nothing is missed.

However, not all clients care. I've also added another path for those
that don't:

- `FileEntryRef` is now copy- and move-assignable (using a pointer
instead of a reference).
- `FileManager::getOptionalFileRef` returns an `llvm::Optional` instead
of `llvm::Expected`.
- Added an `llvm::expectedToOptional` utility in case this is useful
elsewhere.

https://reviews.llvm.org/D66705

llvm-svn: 369943

show more ...


# 98f9e94e 26-Aug-2019 Richard Smith <richard-llvm@metafoo.co.uk>

Fix use of invalidated iterator introduced by r369680.

llvm-svn: 369932


# 894b8d1d 25-Aug-2019 Duncan P. N. Exon Smith <dexonsmith@apple.com>

FileManager: Factor duplicated code in getBufferForFile, NFC

Incidentally, this also unifies the two versions (removing an
unnecessary call to `SmallString::c_str`).

llvm-svn: 369861


# 4dc5573a 22-Aug-2019 Alex Lorenz <arphaman@gmail.com>

Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations

This commit introduces a parallel API to FileManager's getFi

Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations

This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.

The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.

Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.

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

llvm-svn: 369680

show more ...


# f56e8991 21-Aug-2019 Nico Weber <nicolasweber@gmx.de>

clang: Fix typo in comment

llvm-svn: 369536


# 2b3d49b6 14-Aug-2019 Jonas Devlieghere <jonas@devlieghere.com>

[Clang] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
o

[Clang] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

Differential revision: https://reviews.llvm.org/D66259

llvm-svn: 368942

show more ...


Revision tags: llvmorg-9.0.0-rc2
# 461f0722 01-Aug-2019 Harlan Haskins <harlan@harlanhaskins.com>

[clang] Adopt llvm::ErrorOr in FileManager methods

Previously, the FileManager would use NULL returns to signify whether a file existed, but that doesn’t cover permissions issues or anything else th

[clang] Adopt llvm::ErrorOr in FileManager methods

Previously, the FileManager would use NULL returns to signify whether a file existed, but that doesn’t cover permissions issues or anything else that might occur while trying to stat or read a file. Instead, convert getFile and getDirectory into returning llvm::ErrorOr

Signed-off-by: Harlan Haskins <harlan@apple.com>
llvm-svn: 367615

show more ...


Revision tags: llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1
# eec3c0f9 16-Apr-2019 Harlan Haskins <harlan@harlanhaskins.com>

[FileSystemStatCache] Return std::error_code from stat cache methods

Summary:
Previously, we would return true/false signifying if the cache/lookup
succeeded or failed. Instead, provide clients with

[FileSystemStatCache] Return std::error_code from stat cache methods

Summary:
Previously, we would return true/false signifying if the cache/lookup
succeeded or failed. Instead, provide clients with the underlying error
that was thrown while attempting to look up in the cache.

Since clang::FileManager doesn't make use of this information, it discards the
error that's received and casts away to bool.

This change is NFC.

Reviewers: benlangmuir, arphaman

Subscribers: dexonsmith, cfe-commits

Tags: #clang

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

llvm-svn: 358509

show more ...


Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4
# 06f64d53 05-Mar-2019 Harlan Haskins <harlan@harlanhaskins.com>

Replace clang::FileData with llvm::vfs::Status

Summary:
FileData was only ever used as a container for the values in
llvm::vfs::Status, so they might as well be consolidated.

The `InPCH` member was

Replace clang::FileData with llvm::vfs::Status

Summary:
FileData was only ever used as a container for the values in
llvm::vfs::Status, so they might as well be consolidated.

The `InPCH` member was also always set to false, and unused.

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 355368

show more ...


Revision tags: llvmorg-8.0.0-rc3
# cd8607db 18-Feb-2019 Jan Korous <jkorous@apple.com>

Reland "[clang][FileManager] fillRealPathName even if we aren't opening the file"

This reverts commit e2bb3121fd4ab5b01f9ec1d2e3e9877db9c6a54c.
+ fixed test for Windows

llvm-svn: 354291


# e2bb3121 15-Feb-2019 Reid Kleckner <rnk@google.com>

Revert r354075 "[clang][FileManager] fillRealPathName even if we aren't opening the file"

The new test doesn't pass on Windows.

llvm-svn: 354169


# 85eb363d 14-Feb-2019 Jan Korous <jkorous@apple.com>

[clang][FileManager] fillRealPathName even if we aren't opening the file

The pathname wasn't previously filled when the getFile() method was called with openFile = false.
We are caching FileEntry-s

[clang][FileManager] fillRealPathName even if we aren't opening the file

The pathname wasn't previously filled when the getFile() method was called with openFile = false.
We are caching FileEntry-s in ParsedAST::Includes in clangd and this caused the problem.

This fixes an internal test failure in clangd - ClangdTests.GoToInclude.All

rdar://47536127

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

llvm-svn: 354075

show more ...


Revision tags: llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2
# 018ab5fa 30-Jan-2019 Richard Smith <richard-llvm@metafoo.co.uk>

Simplify and modernize this code a little.

No functionality change intended.

llvm-svn: 352593


# fa361206 24-Jan-2019 Sam McCall <sam.mccall@gmail.com>

[FileManager] Revert r347205 to avoid PCH file-descriptor leak.

Summary:
r347205 fixed a bug in FileManager: first calling
getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in
the

[FileManager] Revert r347205 to avoid PCH file-descriptor leak.

Summary:
r347205 fixed a bug in FileManager: first calling
getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in
the file not being open.

Unfortunately, some code was (inadvertently?) relying on this bug: when
building with a PCH, the file entries are obtained first by passing
shouldOpen=false, and then later shouldOpen=true, without any intention
of reading them. After r347205, they do get unneccesarily opened.
Aside from extra operations, this means they need to be closed. Normally
files are closed when their contents are read. As these files are never
read, they stay open until clang exits. On platforms with a low
open-files limit (e.g. Mac), this can lead to spurious file-not-found
errors when building large projects with PCH enabled, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=924225

Fixing the callsites to pass shouldOpen=false when the file won't be
read is not quite trivial (that info isn't available at the direct
callsite), and passing shouldOpen=false is a performance regression (it
results in open+fstat pairs being replaced by stat+open).

So an ideal fix is going to be a little risky and we need some fix soon
(especially for the llvm 8 branch).
The problem addressed by r347205 is rare and has only been observed in
clangd. It was present in llvm-7, so we can live with it for now.

Reviewers: bkramer, thakis

Subscribers: ilya-biryukov, ioeric, kadircet, cfe-commits

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

llvm-svn: 352079

show more ...


Revision tags: llvmorg-8.0.0-rc1
# 2946cd70 19-Jan-2019 Chandler Carruth <chandlerc@gmail.com>

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...


# d92b1ae1 21-Dec-2018 Alex Lorenz <arphaman@gmail.com>

Remove stat cache chaining as it's no longer needed after PTH support has been
removed

Stat cache chaining was implemented for a StatListener in the PTH writer so that
it could write out the stat in

Remove stat cache chaining as it's no longer needed after PTH support has been
removed

Stat cache chaining was implemented for a StatListener in the PTH writer so that
it could write out the stat information to PTH. r348266 removed support for PTH,
and it doesn't seem like there are other uses of stat cache chaining. We can
remove the chaining support.

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

llvm-svn: 349942

show more ...


12345678910