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 ...
|