| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
By using vfs::recursive_directory_iterator, this warning will now fire
when some or all of a module's headers are from VFS mappings.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211746 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
For now, this is only used by its unit tests. It is similar to the API
in llvm::sys::fs::recursive_directory_iterator, but without some of the
more complex features like requesting that the iterator not recurse into
the next directory, for example.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211732 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
1) missing iterator bits needed by libstdc++4.7
Using find_if was convenient, but since operator++ wasn't a good
interface anyway, I just replaced with a range-based for loop and
removed operator++ from the directory_iterator class.
2) stop relying on order of iterating real files
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211633 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
The API is based on sys::fs::directory_iterator, but it allows iterating
over overlays and the yaml-based VFS. For now, it isn't used by
anything (except its tests).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211623 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210780 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we lookup a path using its 'real' path first, we need to ensure that
when we run header search we still use the VFS-mapped path or we will
not be able to find the corresponding module for the header.
The real problem is that we tie the name of a file to its underlying
FileEntry, which is uniqued by inode, so we only ever get the first name
it is looked up by. This doesn't work with modules, which rely on a
specific file system structure. I'm hoping to have time to write up a
proposal for fixing this more permanently soon, but as a stopgap this
patch updates the name of the file's directory if it comes from a VFS
mapping.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209534 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
There are a couple of issues with writing VFS maps that are awkward to
fix within the current mutually recursive approach. Instead, replace
the algorithm with an iterative version that uses an explicit stack of
directories.
Includes tests for cases the old approach was tripping on.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209332 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
This moves the logic to write a JSON VFS mapping from the C api into
VirtualFileSystem, so that we can use it internally.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209241 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208063 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
opening functions.
Needs llvm r208007.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208008 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
This compiles cleanly with lldb/lld/clang-tools-extra/llvm.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203279 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
Allow trivial read-only filesystems such as RealFileSystem to be shared
between threads.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202986 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
| |
a missing include from CLog.h.
CLog.h referenced most of the core libclang types but never directly
included Index.h that provides them. Previously it got lucky and other
headers were always included first but with the sorting it ended up
first in one case and stopped compiling. Adding the Index.h include
fixes it right up.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202810 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202625 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Was r202442
There were two issues with the original patch that have now been fixed.
1. We were memset'ing over a FileEntry in a test case. After adding a
std::string to FileEntry, this still happened to not break for me.
2. I didn't pass the FileManager into the new compiler instance in
compileModule. This was hidden in some cases by the fact I didn't
clear the module cache in the test.
Also, I changed the copy constructor for FileEntry, which was memcpy'ing
in a (now) unsafe way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202539 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Revert r202442, which broke the buildbots.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202443 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
Pass through the externally-visible names that we got from the VFS down
to FileManager, and test that this is the name showing up in __FILE__,
diagnostics, and debug information.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202442 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When true, sets the name of the file to be the name from
'external-contents'. Otherwise, you get the virtual path that the file
was looked up by. This will not affect any non-virtual paths, or fully
virtual paths (for which there is no reasonable 'external' name anyway).
The setting is available globally, but can be overriden on a per-file
basis.
The goal is that this setting will control which path you see in debug
info, diagnostics, etc. which are sensitive to which path is used. That
will come in future patches that pass the name through to FileManager.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202329 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202108 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
This allows the unit tests to not use global state when checking
diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202072 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provides a way to create a virtual file system using a YAML file that
supports mapping a file to a path on an 'external' file system. The
external file system will typically be the 'real' file system, but for
testing it can be changed.
A future patch will add a clang option to allow the user to specify such
a file and overlay it, but for now this code is only exercised by the
unit tests.
Differential Revision: http://llvm-reviews.chandlerc.com/D2835
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201905 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
Previously reverted in r201755 due to causing an assertion failure.
I've removed the offending assertion, and taught the CompilerInstance to
create a default virtual file system inside createFileManager. In the
future, we should be able to reach into the CompilerInvocation to
customize this behaviour without breaking clients that don't care.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201818 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
assertion
in our internal build bots.
This reverts commits 201618, 201635, 201636, 201639, 201685, 201691, and 201696.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201755 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
No functional change
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201696 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
Provides a way to merge multiple vfs::FileSystem objects into a single
filesystem.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201635 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This adds the minimum virtual file system support to start migrating
FileManager onto the VFS.
Originally discussed here:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-February/035188.html
Differential Revision: http://llvm-reviews.chandlerc.com/D2745
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201618 91177308-0d34-0410-b5e6-96231b3b80d8
|