Summary:
InMemoryFileSystem::status behaves differently than
RealFileSystem::status. The Name contained in the Status returned by
RealFileSystem::status will be the path as requested by the caller,
whereas InMemoryFileSystem::status returns the normalized path.
For example, when requested the status for "../src/first.h",
RealFileSystem returns a Status with "../src/first.h" as the Name.
InMemoryFileSystem returns "/absolute/path/to/src/first.h".
The reason for this change is that I want to make a unit test in the
clangd testsuite (where we use an InMemoryFileSystem) to reproduce a
bug I get with the clangd program (where a RealFileSystem is used).
This difference in behavior "hides" the bug in the unit test version.
An indirect impact of this change is that a -Wnonportable-include-path
warning is now emitted in test PCH/case-insensitive-include.c. This is
because the real path of the included file (with the wrong case) was not
available previously, whereas it is now.
Reviewers: malaperle, ilya-biryukov, bkramer
Reviewed By: ilya-biryukov
Subscribers: eric_niebler, malaperle, omtcyfz, hokein, bkramer, ilya-biryukov, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D48903
llvm-svn: 339063
Summary:
InMemoryFileSystem::status behaves differently than
RealFileSystem::status. The Name contained in the Status returned by
RealFileSystem::status will be the path as requested by the caller,
whereas InMemoryFileSystem::status returns the normalized path.
For example, when requested the status for "../src/first.h",
RealFileSystem returns a Status with "../src/first.h" as the Name.
InMemoryFileSystem returns "/absolute/path/to/src/first.h".
The reason for this change is that I want to make a unit test in the
clangd testsuite (where we use an InMemoryFileSystem) to reproduce a
bug I get with the clangd program (where a RealFileSystem is used).
This difference in behavior "hides" the bug in the unit test version.
Reviewers: malaperle, ilya-biryukov, bkramer
Subscribers: cfe-commits, ioeric, ilya-biryukov, bkramer, hokein, omtcyfz
Differential Revision: https://reviews.llvm.org/D48903
llvm-svn: 338057
Summary:
- add comments clarifying semantics
- Status::copyWithNewName(Status, Name) --> instance method
- Status::copyWithNewName(fs::file_status, Name) --> constructor (it's not a copy)
- File::getName() -> getRealPath(), reflecting its actual behavior/function
and stop returning status().getName() in the base class (callers can do this
fallback if they want to, it complicates the contracts).
This is mostly NFC, but the behavior of File::getName() affects FileManager's
FileEntry::tryGetRealPathName(), which now fails in more cases:
- non-real file cases
- real-file cases where the underlying vfs::File was opened in a way that
doesn't call realpath().
(In these cases we don't know a distinct real name, so in principle it seems OK)
Reviewers: klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49724
llvm-svn: 337834
This reverts commit r336807. This breaks users of
ClangTool::mapVirtualFile. Will try to investigate a fix. See also the
discussion on https://reviews.llvm.org/D48903
llvm-svn: 336831
Summary:
InMemoryFileSystem::status behaves differently than
RealFileSystem::status. The Name contained in the Status returned by
RealFileSystem::status will be the path as requested by the caller,
whereas InMemoryFileSystem::status returns the normalized path.
For example, when requested the status for "../src/first.h",
RealFileSystem returns a Status with "../src/first.h" as the Name.
InMemoryFileSystem returns "/absolute/path/to/src/first.h".
The reason for this change is that I want to make a unit test in the
clangd testsuite (where we use an InMemoryFileSystem) to reproduce a
bug I get with the clangd program (where a RealFileSystem is used).
This difference in behavior "hides" the bug in the unit test version.
In general, I guess it's good if InMemoryFileSystem works as much as
possible like RealFileSystem.
Doing so made the FileEntry::RealPathName value (assigned in
FileManager::getFile) wrong when using the InMemoryFileSystem. That's
because it assumes that vfs::File::getName will always return the real
path. I changed to to use FileSystem::getRealPath instead.
Subscribers: ilya-biryukov, ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D48903
llvm-svn: 336807
Do not memory map the main file if the flag UserFilesAreVolatile is set to true
in ASTUnit when calling FileSystem::getBufferForFile.
Differential Revision: https://reviews.llvm.org/D47460
llvm-svn: 334070
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the
default macro instead of a reinvented one.
See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.
llvm-svn: 331069
The getVirtualFile method would create entries for e.g. libclang's
CXUnsavedFile but not mark them as valid. The effect is that a lookup
through getFile where the file name is not exactly matching the virtual
file (e.g. through mixing slashes and backslashes on Windows) would
result in a normal file "lookup", and re-using the file entry found
by using the UniqueID, and overwrite the file entry fields. Because the
lookup involves opening the file, and moving it into the file entry, the
file is now open. The SourceManager keys its buffers on the UniqueID
(which is still the same), so it will find an already loaded buffer.
Because only the loading a buffer from disk will close the file, the
FileEntry will hold on to an open file for as long as the FileManager
is around. As the FileManager will only get destroyed at a reparse,
you can't safe to the "leaked" and locked file on Windows.
llvm-svn: 298905
Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842
Re-commit after addressing issues with of generating too many warnings for Windows and asan test failures.
Patch by Eric Niebler
llvm-svn: 272562
addAncestorsAsVirtualDirs("<stdin>") quickly returns without doing work
because "<stdin>" has no parent_path. This violates the expectation
that a subsequent call to getDirectoryFromFile("<stdin>") would succeed.
Instead, it fails because it uses the "." if the file has no path
component.
Fix this by keeping the behavior between addAncestorsAsVirtualDirs and
getDirectoryFromFile symmetric.
llvm-svn: 266089
than reusing the "overridden buffer" mechanism. This will allow us to make
embedded files and overridden files behave differently in future.
llvm-svn: 254121
Summary: It breaks the build for the ASTMatchers
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D13893
llvm-svn: 250827
Also fix completely broken and untested code which was hiding the
primary bug. The !LLVM_ON_UNIX branch of the ifdef was actually a no-op.
I ran into this in the wild. It was causing failures in our SDK build.
Ideally we'd have a perfect llvm::sys::fs::canonical, but at least this
is a step in the right direction, and fixes an obviously broken case.
In some sense the test case I've added here is an integration test. We
should have these routines thoroughly unit tested in llvm::sys::fs.
llvm-svn: 243597
- introduces a new cc1 option -fmodule-format=[raw,obj]
with 'raw' being the default
- supports arbitrary module container formats that libclang is agnostic to
- adds the format to the module hash to avoid collisions
- splits the old PCHContainerOperations into PCHContainerWriter and
a PCHContainerReader.
Thanks to Richard Smith for reviewing this patch!
llvm-svn: 242499
This patch adds ObjectFilePCHContainerOperations uses the LLVM backend
to put the contents of a PCH into a __clangast section inside a COFF, ELF,
or Mach-O object file container.
This is done to facilitate module debugging by makeing it possible to
store the debug info for the types defined by a module alongside the AST.
rdar://problem/20091852
llvm-svn: 241620
Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.
There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.
llvm-svn: 232622
components. These sometimes get synthetically added, and we don't want -Ifoo
and -I./foo to be treated fundamentally differently here.
llvm-svn: 224055
Because we may change the name of a FileEntry inside getFile, the name
returned by FileEntry::getName() could be destroyed. This was causing a
use-after-free when searching the HeaderFileInfo on-disk hashtable for a
module or pch.
llvm-svn: 217385
With modules we start accessing headers for the first time while reading
the module map, which often has very different paths from the include
scanning logic.
Using the name by which the file was accessed gets us one step closer to
the right solution, which is using a FileName abstraction that decouples
the name by which a file was accessed from the FileEntry.
llvm-svn: 215541
And in the process, discover that FileManager::removeStatCache had a
double-delete when removing an element from the middle of the list (at
the beginning or the end of the list, there was no problem) and add a
unit test to exercise the code path (which successfully crashed when run
(with modifications to match the old API) without this patch applied)
llvm-svn: 215388
It's also possible to just write "= nullptr", but there's some question
of whether that's as readable, so I leave it up to authors to pick which
they prefer for now. If we want to discuss standardizing on one or the
other, we can do that at some point in the future.
llvm-svn: 213439
Successfully loaded module files may be referenced in other
ModuleManagers, so don't invalidate them. Two related things are fixed:
1) I thought the last module in the manager was always the one that
failed, but it isn't. So check explicitly against the list of
vetted modules from ReadASTCore.
2) We now keep the file descriptor of pcm file open, which avoids the
possibility of having two different pcms for the same module loaded when
building in parallel with headers being modified during a build.
<rdar://problem/16835846>
llvm-svn: 211330
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.
llvm-svn: 209534
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.
llvm-svn: 202539
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.
llvm-svn: 202442
Keep the copy constructor around, and add a FIXME that we should really
remove it as soon as we have C++11 std::map's emplace function.
llvm-svn: 202439
This cleans up some constructors that would not be safe once FileEntry
owns the storage for its name. These were already suspect, since they
wouldn't work if the FileEntry had an open file descriptor. The only
user for these constructors was in UniqueFileContainer, which wasn't a
very useful abstraction anyway. So it and UniqueDirContainer have been
replaced with std::map<UniqueID, *>.
This change should not affect anything outside the FileManager.
llvm-svn: 202420
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.
llvm-svn: 201818
This unifies the unix and windows versions of FileManager::UniqueDirContainer
and FileManager::UniqueFileContainer by using UniqueID.
We cannot just replace "struct stat" with llvm::sys::fs::file_status, since we
want to be able to construct fake ones, and file_status has different members
on unix and windows.
What the patch does is:
* Record only the information that clang is actually using.
* Use llvm::sys::fs::status instead of stat and fstat.
* Use llvm::sys::fs::UniqueID
* Delete the old windows versions of UniqueDirContainer and
UniqueFileContainer since the "unix" one now works on windows too.
llvm-svn: 187619
On windows, c:foo is a valid file path, but stat fails on just "c:". This
causes a problem for clang since its file manager wants to cache data about
the parent directory.
There are refactorings to be done in here, but this gives clang the correct
behavior and testing first.
Patch by Yunzhong Gao!
llvm-svn: 187359
factor the realpath calls into FileManager::getCanonicalName() so we
can cache the results of this epically slow operation. 5% speedup on
my modules test, and realpath drops out of the profile.
llvm-svn: 173542
a file or directory, allowing just a stat call if a file descriptor
is not needed.
Doing just 'stat' is faster than 'open/fstat/close'.
This has the effect of cutting down system time for validating the input files of a PCH.
llvm-svn: 169831
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
- The whole {File,Source}Manager is built around wanting to pre-determine the
size of files, so we can't fit this in naturally. Instead, we handle it like
we do STDIN, where we just replace the main file contents upfront.
llvm-svn: 167419
Clear the FileManager's stat cache in between running
translation units, as the stat cache loaded from a pch
is only valid for one compiler invocation.
llvm-svn: 161047
as "volatile", meaning there's a high enough chance that they may
change while we are trying to use them.
This flag is only enabled by libclang.
Currently "volatile" source files will be stat'ed immediately
before opening them, because the file size stat info
may not be accurate since when we got it (e.g. from the PCH).
This avoids crashes when trying to reference mmap'ed memory
from a file whose size is not what we expect.
Note that there's still a window for a racing issue to occur
but the window for it should be way smaller than before.
We can consider later on to avoid mmap completely on such files.
rdar://11612916
llvm-svn: 160074
Implement UniqueFileContainer::erase(), camelCase, add comment on future optimizations of the cache versus de-optimizations of invalidations.
llvm-svn: 159997
add interface for removing a FileEntry from the cache.
Forces a re-read the contents from disk, e.g. because a tool (like cling) wants to pick up a modified file.
llvm-svn: 159256
validate that we didn't override the contents of any of such files.
If this is detected, emit a diagnostic error and recover gracefully
by using the contents of the original file that the PCH was built from.
Part of rdar://11305263
llvm-svn: 156107
Simon Marchi