[clang][lex] Remark on search path usage

For dependency scanning, it would be useful to collect header search paths (provided on command-line via `-I` and friends) that were actually used during pre

[clang][lex] Remark on search path usage

For dependency scanning, it would be useful to collect header search paths (provided on command-line via `-I` and friends) that were actually used during preprocessing. This patch adds that feature to `HeaderSearch` along with a new remark that reports such paths as they get used.

Previous version of this patch tried to use the existing `LookupFileCache` to report used paths via `HitIdx`. That doesn't work for `ComputeUserEntryUsage` (which is intended to be called *after* preprocessing), because it indexes used search paths by the file name. This means the values get overwritten when the code contains `#include_next`.

Note that `HeaderSearch` doesn't use `HeaderSearchOptions::UserEntries` directly. Instead, `InitHeaderSearch` pre-processes them (adds platform-specific paths, removes duplicates, removes paths that don't exist) and creates `DirectoryLookup` instances. This means we need a mechanism for translating between those two. It's not possible to go from `DirectoryLookup` back to the original `HeaderSearch`, so `InitHeaderSearch` now tracks the relationships explicitly.

Depends on D111557.

Reviewed By: dexonsmith

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

show more ...

[clang] Rename StringRef _lower() method calls to _insensitive()

This is mostly a mechanical change, but a testcase that contains
parts of the StringRef class (clang/test/Analysis/llvm-conventions.c

[clang] Rename StringRef _lower() method calls to _insensitive()

This is mostly a mechanical change, but a testcase that contains
parts of the StringRef class (clang/test/Analysis/llvm-conventions.cpp)
isn't touched.

show more ...

[clang][clangd] Use reverse header map lookup in suggestPathToFileForDiagnostics

Summary:
suggestPathToFileForDiagnostics is actively used in clangd for converting
an absolute path to a header file

[clang][clangd] Use reverse header map lookup in suggestPathToFileForDiagnostics

Summary:
suggestPathToFileForDiagnostics is actively used in clangd for converting
an absolute path to a header file to a header name as it should be spelled
in the sources. Current approach converts absolute path to relative path.
This diff implements missing logic that makes a reverse lookup from the
relative path to the key in the header map that should be used in the sources.

Prerequisite diff: https://reviews.llvm.org/D103229

Test Plan: check-clang

Reviewers: dexonsmith, bruno, rsmith

Subscribers: cfe-commits

Tasks:

Tags: #clang

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

show more ...

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

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

[clang] Adopt new FileManager error-returning APIs

Update the callers of FileManager::getFile and FileManager::getDirectory to handle the new llvm::ErrorOr-returning methods.

Signed-off-by: Harlan

[clang] Adopt new FileManager error-returning APIs

Update the callers of FileManager::getFile and FileManager::getDirectory to handle the new llvm::ErrorOr-returning methods.

Signed-off-by: Harlan Haskins <[email protected]>
llvm-svn: 367616

show more ...

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

[Lex] Make HeaderMaps a unique_ptr vector

Summary: unique_ptr makes the ownership clearer than a raw pointer container.

Reviewers: Eugene.Zelenko, dblaikie

Subscribers: cfe-commits

Differential R

[Lex] Make HeaderMaps a unique_ptr vector

Summary: unique_ptr makes the ownership clearer than a raw pointer container.

Reviewers: Eugene.Zelenko, dblaikie

Subscribers: cfe-commits

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

llvm-svn: 340198

show more ...

Use StringRef for MemoryBuffer identifier API (NFC)

llvm-svn: 283043

Lex: Return "" when HeaderMap::lookupFilename fails

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

Lex: Return "" when HeaderMap::lookupFilename fails

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.

llvm-svn: 261596

show more ...

Lex: Check for 0 buckets on header map construction

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
bucke

Lex: Check for 0 buckets on header map construction

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.

llvm-svn: 261585

show more ...

Lex: Never overflow the file in HeaderMap::lookupFilename()

If a header map file is corrupt, the strings in the string table may not
be null-terminated. The logic here previously relied on `MemoryB

Lex: Never overflow the file in HeaderMap::lookupFilename()

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

llvm-svn: 261461

show more ...

Lex: Change HeaderMapImpl::getString() to return StringRef, NFC

llvm-svn: 261459

Lex: Use dbgs() instead of fprintf() in HeaderMap::dump()

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

There's a slight change here, because I used `errs()` instea

Lex: Use dbgs() instead of fprintf() in HeaderMap::dump()

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.

llvm-svn: 261456

show more ...

Lex: Check whether the header map buffer has space for the buckets

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

There was already a check in `getBucket()`

Lex: Check whether the header map buffer has space for the buckets

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.

llvm-svn: 261449

show more ...

Lex: Check buckets on header map construction

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

Lex: Check buckets on header map construction

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.

llvm-svn: 261448

show more ...

Lex: Add some unit tests for corrupt header maps

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

Lex: Add some unit tests for corrupt header maps

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.

llvm-svn: 261446

show more ...

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

llvm-svn: 259232

Make VFS and FileManager match the current MemoryBuffer API.

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

llvm-svn: 220657

unique_ptrify HeaderMap::FileBuffer

llvm-svn: 216758

[C++11] Use 'nullptr'. Lex edition.

llvm-svn: 209083

[C++11] Replace OwningPtr include with <memory>.

llvm-svn: 203389

Replace OwningPtr with std::unique_ptr.

This compiles cleanly with lldb/lld/clang-tools-extra/llvm.

llvm-svn: 203279

Change OwningPtr::take() to OwningPtr::release().

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

llvm-svn: 203275

If the headermap maps the filename to a framework include ("Foo.h" -> "Foo/Foo.h"),
continue header lookup using the framework include as filename.

This allows us to conveniently treat
#import "Fo

If the headermap maps the filename to a framework include ("Foo.h" -> "Foo/Foo.h"),
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

llvm-svn: 201419

show more ...