Change getString() to return Optional<StringRef>, and change
lookupFilename() to return an empty string if either one of the prefix
and suffix can't be found.

This is a more robust follow-up to r261461, but it's still not entirely
satisfactory.  Ideally we'd report that the header map is corrupt;
perhaps something for a follow-up.

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

Switch to using `isPowerOf2_32()` to check whether the buckets are a
power of two, and as a side benefit reject loading a header map with no
buckets.  This is a follow-up to r261448.

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

If a header map file is corrupt, the strings in the string table may not
be null-terminated.  The logic here previously relied on `MemoryBuffer`
always being null-terminated, but this isn't actually guaranteed by the
class AFAICT.  Moreover, we're seeing a lot of crash traces at calls to
`strlen()` inside of `lookupFilename()`, so something is going wrong
there.

Instead, use `strnlen()` to get the length, and check for corruption.

Also remove code paths that could call `StringRef(nullptr)`.  r261459
made these rather obvious (although they'd been there all along).

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

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

This way it's easy to change HeaderMapImpl::getString() to return a
StringRef.

There's a slight change here, because I used `errs()` instead of
`dbgs()`.  But `dbgs()` is more appropriate for a dump method.

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

Check up front whether the header map buffer has space for all of its
declared buckets.

There was already a check in `getBucket()`, but it had UB (comparing
pointers that were outside of objects in the error path) and was
insufficient (only checking for a single byte of the relevant bucket).
I fixed the check, moved it to `checkHeader()`, and left a fixed version
behind as an assertion.

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

If the number of buckets is not a power of two, immediately recognize
the header map as corrupt, rather than waiting for the first lookup.  I
converted the later check to an assert.

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

Split the implementation of `HeaderMap` into `HeaderMapImpl` so that we
can write unit tests that don't depend on the `FileManager`, and then
write a few tests that cover the types of corrupt header maps already
detected.

This also moves type and constant definitions from HeaderMap.cpp to
HeaderMapTypes.h so that the test can access them.

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

Annotate dump() methods with LLVM_DUMP_METHOD, addressing Richard Smith r259192 post commit comment.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259232 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

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

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203389 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

This is a precursor to moving to std::unique_ptr.

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

continue header lookup using the framework include as filename.

This allows us to conveniently treat
  #import "Foo.h"
as an implicit module import if we can resolve "Foo/Foo.h" as such.

rdar://16042979

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

The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.

DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.

One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).

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

These are causing assertions on some MSVC builds.

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

Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.

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

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

(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)

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

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

them into the clang namespace.


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

includes get resolved, especially when they are found relatively to
another include file. We also try to get it working for framework
includes, but that part of the code is untested, as I don't have a code
base that uses it.

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

clients to observe the exact path through which an #included file was
located. This is very useful when trying to record and replay inclusion
operations without it beind influenced by the aggressive caching done
inside the FileManager to avoid redundant system calls and filesystem
operations.

The work to compute and return this is only done in the presence of
callbacks, so it should have no effect on normal compilation.

Patch by Manuel Klimek.

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

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

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

FileSystemOpts through a ton of apis, simplifying a lot of code.
This also fixes a latent bug in ASTUnit where it would invoke
methods on FileManager without creating one in some code paths
in cindextext.


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

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

When -working-directory is passed in command line, file paths are resolved relative to the specified directory.
This helps both when using libclang (where we can't require the user to actually change the working directory)
and to help reproduce test cases when the reproduction work comes along.

--FileSystemOptions is introduced which controls how file system operations are performed (currently it just contains
 the working directory value if set).
--FileSystemOptions are passed around to various interfaces that perform file operations.
--Opening & reading the content of files should be done only through FileManager. This is useful in general since
 file operations will be abstracted in the future for the reproduction mechanism.

FileSystemOptions is independent of FileManager so that we can have multiple translation units sharing the same
FileManager but with different FileSystemOptions.

Addresses rdar://8583824.

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

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

nicer than passing around two const char*'s.


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

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

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

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

Initialize Suffix and Prefix to 0, even with a bad entry.  Removes an uninitialized value warning from gcc.


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

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

lib dir and move all the libraries into it.  This follows the main
llvm tree, and allows the libraries to be built in parallel.  The
top level now enforces that all the libs are built before Driver,
but we don't care what order the libs are built in.  This speeds
up parallel builds, particularly incremental ones.


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

discussion of this change.



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

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