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.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298905 91177308-0d34-0410-b5e6-96231b3b80d8

No functionality change intended.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298443 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283856 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283815 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278586 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: Removed unused headers, replaced some headers with forward class declarations

Patch by: Eugene <claprix@yandex.ru>

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275882 91177308-0d34-0410-b5e6-96231b3b80d8

Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842

Re-commit of r272562 after addressing clang-x86-win2008-selfhost failure.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272584 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272572 91177308-0d34-0410-b5e6-96231b3b80d8

Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

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



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272562 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271761 91177308-0d34-0410-b5e6-96231b3b80d8

Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842

Patch by Eric Niebler



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271708 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266089 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259355 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255129 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255091 91177308-0d34-0410-b5e6-96231b3b80d8

than reusing the "overridden buffer" mechanism. This will allow us to make
embedded files and overridden files behave differently in future.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254121 91177308-0d34-0410-b5e6-96231b3b80d8

Differential Revision: http://reviews.llvm.org/D14394

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252501 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: It breaks the build for the ASTMatchers

Subscribers: klimek, cfe-commits

Differential Revision: http://reviews.llvm.org/D13893

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250827 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: Replace empty bodies of default constructors and destructors with '= default'.

Reviewers: bkramer, klimek

Subscribers: klimek, alexfh, cfe-commits

Differential Revision: http://reviews.llvm.org/D13890

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250822 91177308-0d34-0410-b5e6-96231b3b80d8

No functional change intended.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243970 91177308-0d34-0410-b5e6-96231b3b80d8

[modules] Fix issue where building a module from a relative path when -working-directory option is set, results in error.

The error was "module '<name>' was built in directory '<path>' but now resides in directory '<path>'
rdar://21330027

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243718 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243625 91177308-0d34-0410-b5e6-96231b3b80d8

It looks like we were somehow relying somewhere on removing 'foo/./bar'
but *not* 'foo/../foo/bar'. Currently investigating.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243600 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243597 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242499 91177308-0d34-0410-b5e6-96231b3b80d8

PR24067.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241782 91177308-0d34-0410-b5e6-96231b3b80d8

Fixes PR24067.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241770 91177308-0d34-0410-b5e6-96231b3b80d8

of the llvm targets from clang/CodeGen into ClangCheck.cpp and CIndex.cpp.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241653 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241642 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241620 91177308-0d34-0410-b5e6-96231b3b80d8

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.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232622 91177308-0d34-0410-b5e6-96231b3b80d8

components. These sometimes get synthetically added, and we don't want -Ifoo
and -I./foo to be treated fundamentally differently here.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224055 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222306 91177308-0d34-0410-b5e6-96231b3b80d8

This eliminates converting back and forth between the 3 formats and
gives us a more homogeneous interface.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220657 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217385 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216476 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215541 91177308-0d34-0410-b5e6-96231b3b80d8

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)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215388 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215318 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213439 91177308-0d34-0410-b5e6-96231b3b80d8