Summary:
The previous behavior was aggressive,
#include "abc/f^/abc.h"
foo/ -> candidate
"f/abc.h" is replaced with "foo/", this patch will preserve the "abc.h".
Reviewers: sammccall
Subscribers: jkorous, arphaman, kadircet, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D76770
After a crash catched by the CrashRecoveryContext, this patch prevents from accessing dangling pointers in TimerGroup structures before the clang tool exits. Previously, the default TimerGroup had internal linked lists which were still pointing to old Timer or TimerGroup instances, which lived in stack frames released by the CrashRecoveryContext.
Fixes PR45164.
Differential Revision: https://reviews.llvm.org/D76099
Most clients of SourceManager.h need to do things like turning source
locations into file & line number pairs, but this doesn't require
bringing in FileManager.h and LLVM's FS headers.
The main code change here is to sink SM::createFileID into the cpp file.
I reason that this is not performance critical because it doesn't happen
on the diagnostic path, it happens along the paths of macro expansion
(could be hot) and new includes (less hot).
Saves some includes:
309 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/Basic/FileManager.h
272 - /usr/local/google/home/rnk/llvm-project/clang/include/clang/Basic/FileSystemOptions.h
271 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/VirtualFileSystem.h
267 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/FileSystem.h
266 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/Chrono.h
Differential Revision: https://reviews.llvm.org/D75406
Lots of headers pass around MemoryBuffer objects, but very few open
them. Let those that do include FileSystem.h.
Saves ~250 includes of Chrono.h & FileSystem.h:
$ diff -u thedeps-before.txt thedeps-after.txt | grep '^[-+] ' | sort | uniq -c | sort -nr
254 - ../llvm/include/llvm/Support/FileSystem.h
253 - ../llvm/include/llvm/Support/Chrono.h
237 - ../llvm/include/llvm/Support/NativeFormatting.h
237 - ../llvm/include/llvm/Support/FormatProviders.h
192 - ../llvm/include/llvm/ADT/StringSwitch.h
190 - ../llvm/include/llvm/Support/FormatVariadicDetails.h
...
This requires duplicating the file_t typedef, which is unfortunate. I
sunk the choice of mapping mode down into the cpp file using variable
template specializations instead of class members in headers.
Support only preferred spelling 'Modules/module.private.modulemap' and
not the deprecated 'module_private.map'.
rdar://problem/57715533
Reviewed By: bruno
Differential Revision: https://reviews.llvm.org/D75311
FileManager.h is an expensive header (~350ms for me in isolation), so
try to do without it.
Notably, we need to avoid checking the alignment of FileEntry, which
happens for DenseMap<FileEntry*> and PointerUnion<FileEntry*>. I
adjusted the code to avoid PointerUnion, and moved the DenseMap
insertion to the .cpp file.
Globally, this only saved about ~17 includes of the related headers
because SourceManager.h still includes FileManager.h, and it is more
popular than Module.h.
`vector' uses the keyword-and-predefine mode from gcc, while __vector is
reliably supported.
As a side effect, it also makes the code consistent in its usage of __vector.
Differential Revision: https://reviews.llvm.org/D74129
This reverts commits f41ec709d9 and 5fedc2b410. On some buildbots, Clang :: Driver/crash-report.c is broken with:
```
Command Output (stderr):
--
/home/buildslave/ps4-buildslave1/clang-with-thin-lto-ubuntu/llvm-project/clang/test/Driver/crash-report.c:48:11: error: CHECK: expected string not found in input
// CHECK: Preprocessed source(s) and associated run script(s) are located at:
^
<stdin>:1:1: note: scanning from here
/home/buildslave/ps4-buildslave1/clang-with-thin-lto-ubuntu/llvm-project/clang/test/Driver/crash-report.c:50:1: error: unknown type name 'BAZ'
```
Example: http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/21321/steps/test-stage1-compiler/logs/stdio
Previously, when the above '#pragma clang __debug' were used, Driver::generateCompilationDiagnostics() wouldn't work as expected.
The 'clang -E' process created for diagnostics would crash, because it would reach again the intended crash in Pragma.cpp, PragmaDebugHandler::HandlePragma() while preprocessing.
When generating crash diagnostics, we now disable the intended crashing behavior with a new cc1 flag -disable-pragma-debug-crash.
Notes:
- #pragma clang __debug llvm_report_fatal isn't currently tested by crash-report.c, because it needs exit() to be handled differently in -fintegrated-cc1 mode. See https://reviews.llvm.org/D73742 for an upcoming fix.
- This is also needed to further validate that -MF is removed from the 'clang -E ' crash diagnostic cmd-line (currently not the case). See https://reviews.llvm.org/D74076 for an upcoming fix.
Differential Revision: https://reviews.llvm.org/D74070
As discussed in D70568, remove this because it isn't used anywhere, and I think it's better to go through real crashes for testing (#pragma clang __debug crash).
Also remove the support function llvm::CrashRecoveryContext::HandleCrash() which was added at the same time by @ddunbar.
Differential Revision: https://reviews.llvm.org/D74063
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
See
https://docs.google.com/document/d/1xMkTZMKx9llnMPgso0jrx3ankI4cv60xeZ0y4ksf4wc/preview
for background discussion.
This adds a warning, flags and pragmas to limit the number of
pre-processor tokens either at a certain point in a translation unit, or
overall.
The idea is that this would allow projects to limit the size of certain
widely included headers, or for translation units overall, as a way to
insert backstops for header bloat and prevent compile-time regressions.
Differential revision: https://reviews.llvm.org/D72703
Summary:
As discussed in http://lists.llvm.org/pipermail/cfe-dev/2019-October/063459.html
the overflow of the souce locations (limited to 2^31 chars) can generate all sorts of
weird things (bogus warnings, hangs, crashes, miscompilation and correct compilation).
In debug mode this assert would fail. So it might be a good start, as in PR42301,
to detect the failure and exit with a proper error message.
Reviewers: rsmith, thakis, miyuki
Reviewed By: miyuki
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D70183
Summary:
Previously, the -fdollars-in-identifiers flag allows the '$' symbol to be used
in an identifier but the universal character name equivalent '\u0024' is not
allowed.
This patch changes this, so that \u0024 is valid in identifiers.
Reviewers: rsmith, jordan_rose
Reviewed By: rsmith
Subscribers: dexonsmith, simoncook, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D71758
Summary:
Before this patch adding a new /D flag when compiling a source file that consumed a PCH with clang-cl would issue a diagnostic and then fail. With the patch, the diagnostic is still issued but the definition is accepted. This matches the msvc behavior. The fuzzy-pch-msvc.c is a clone of the existing fuzzy-pch.c tests with some msvc specific rework.
msvc diagnostic:
warning C4605: '/DBAR=int' specified on current command line, but was not specified when precompiled header was built
Output of the CHECK-BAR test prior to the code change:
<built-in>(1,9): warning: definition of macro 'BAR' does not match definition in precompiled header [-Wclang-cl-pch]
#define BAR int
^
D:\repos\llvm\llvm-project\clang\test\PCH\fuzzy-pch-msvc.c(12,1): error: unknown type name 'BAR'
BAR bar = 17;
^
D:\repos\llvm\llvm-project\clang\test\PCH\fuzzy-pch-msvc.c(23,4): error: BAR was not defined
# error BAR was not defined
^
1 warning and 2 errors generated.
Reviewers: rnk, thakis, hans, zturner
Subscribers: mikerice, aganea, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72405
`APFLoat::convertFromString` returns `Expected` result, which must be
"checked" if the LLVM_ENABLE_ABI_BREAKING_CHECKS preprocessor flag is
set.
To mark an `Expected` result as "checked" we must consume the `Error`
within.
In many cases, we are only interested in knowing if an error occured,
without the need to examine the error info. This is achieved, easily,
with the `errorToBool()` API.
This patch makes the minimizer more conservative to avoid missing dependency files that are brought in by __has_include
PP expressions that occur in a condition of an #if/#elif that was previously skipped. The __has_include PP expressions
can be used in an #if/#elif either directly, or through macro expansion, so we can't detect them at the time of minimization.
Differential Revision: https://reviews.llvm.org/D70936
It is tricky to use replace_path_prefix correctly on Windows which uses
backslashes as native path separators. Switch back to the old approach
(startswith is not ideal) to appease build bots for now.
GCC 8 implements -fmacro-prefix-map. Like -fdebug-prefix-map, it replaces a string prefix for the __FILE__ macro.
-ffile-prefix-map is the union of -fdebug-prefix-map and -fmacro-prefix-map
Reviewed By: rnk, Lekensteyn, maskray
Differential Revision: https://reviews.llvm.org/D49466
__has_cpp_attribute is not available in C mode, and __has_c_attribute
should not be available in C++ mode. This also adds a test to
demonstrate that we properly handle scoped attribute tokens even in C
mode.
Refactor the logic on CompilerInstance::loadModule and a couple of
surrounding methods in order to clarify what's going on.
- Rename ModuleLoader::loadModuleFromSource to compileModuleFromSource
and fix its documentation, since it never loads a module. It just
creates/compiles one.
- Rename one of the overloads of compileModuleImpl to compileModule,
making it more obvious which one calls the other.
- Rename compileAndLoadModule to compileModuleAndReadAST. This
clarifies the relationship between this helper and its caller,
CompilerInstance::loadModule (the old name implied the opposite
relationship). It also (correctly) indicates that more needs to be
done to load the module than this function is responsible for.
- Split findOrCompileModuleAndReadAST out of loadModule. Besides
reducing nesting for this code thanks to early returns and the like,
this refactor clarifies the logic in loadModule, particularly around
calls to ModuleMap::cacheModuleLoad and
ModuleMap::getCachedModuleLoad. findOrCompileModuleAndReadAST also
breaks early if the initial ReadAST call returns Missing or OutOfDate,
allowing the last ditch call to compileModuleAndReadAST to come at the
end of the function body.
- Additionally split out selectModuleSource, clarifying the logic
due to early returns.
- Add ModuleLoadResult::isNormal and OtherUncachedFailure, so that
loadModule knows whether to cache the result.
OtherUncachedFailure was added to keep this patch NFC, but there's
a chance that these cases were uncached by accident, through
copy/paste/modify failures. These should be audited as a
follow-up (maybe we can eliminate this case).
- Do *not* lift the setting of `ModuleLoadFailed = true` to
loadModule because there isn't a clear pattern for when it's set.
This should be reconsidered in a follow-up, in case it would be
correct to set `ModuleLoadFailed` whenever no module is returned
and the result is either Normal or OtherUncachedFailure.
- Add some header documentation where it was missing, and fix it where
it was wrong.
This should have no functionality change.
https://reviews.llvm.org/D70556
Builtins are rarely if ever accessed via the Preprocessor. They are
typically found on the ASTContext, so there should be no performance
penalty to using a pointer indirection to store the builtin context.
In Microsoft-compatibility mode, single commas from nested macro expansions
should not be considered as argument separators; we already emulated this by
marking them to be ignored. However, in MSVC's preprocessor, subsequent
expansions DO treat these commas as argument separators... so we now ignore
each comma at most once.
Includes a small unit test that validates we match MSVC's behavior as shown
in https://gcc.godbolt.org/z/y0twaq
Fixes PR43282
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69626
The existing string/character literal skipping code in the
dependency directives source minimizer has two issues:
- It doesn't stop the scanning when a newline is reached before the terminating character,
unlike the lexer which considers the token to be done (even if it's invalid) at the end of the line.
- It doesn't support whitespace between '\' and the newline when looking if the '\' is used as a line continuation character.
This commit fixes both issues.
Differential Revision: https://reviews.llvm.org/D68436
llvm-svn: 374127
Summary:
Avoid parsing __pragma into an annotation token when macro arguments are pre-expanded.
This is what clang currently does when parsing _Pragmas.
Fixes https://bugs.llvm.org/show_bug.cgi?id=41128, where clang crashed
when trying to get the length of an annotation token.
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68114
llvm-svn: 373950
in the dependency source minimizer
Clang allows continuations that have whitespace between the backslash and the newline.
This patch ensures that the dependency source minimizer can handle the whitespace between
the backslash and the newline when looking for a line continuation.
Differential Revision: https://reviews.llvm.org/D68052
llvm-svn: 373007
This include search logic has an extra parameter to deal with Windows
includes with backslashes, which get normalized to forward slashes on
non-Windows under -fms-compatibility.
Hoist the conditional operator out of LookupHeaderIncludeOrImport and
pass the result in instead of repeating the ?: expression everywhere.
llvm-svn: 372926
In case of certain #define'd macros, there's a space just before line continuation
that the minimized-source lexer was missing to include, resulting in invalid stringize.
Patch by: kousikk (Kousik Kumar)
Differential Revision: https://reviews.llvm.org/D67635
llvm-svn: 372360
-frewrite-includes calls PP.SetMacroExpansionOnlyInDirectives() to avoid
macro expansions that are useless in that mode, but this can lead
to -Wunused-macros false positives. As -frewrite-includes does not emit
normal warnings, block -Wunused-macros too.
Differential Revision: https://reviews.llvm.org/D65371
llvm-svn: 372026
In order to enable future improvements to our attribute diagnostics,
this moves info from ParsedAttr into CommonAttributeInfo, then makes
this type the base of the *Attr and ParsedAttr types. Quite a bit of
refactoring took place, including removing a bunch of redundant Spelling
Index propogation.
Differential Revision: https://reviews.llvm.org/D67368
llvm-svn: 371875
This commit adds an optimization to clang-scan-deps and clang's preprocessor that skips excluded preprocessor
blocks by bumping the lexer pointer, and not lexing the tokens until reaching appropriate #else/#endif directive.
The skip positions and lexer offsets are computed when the file is minimized, directly from the minimized tokens.
On an 18-core iMacPro with macOS Catalina Beta I got 10-15% speed-up from this optimization when running clang-scan-deps on
the compilation database for a recent LLVM and Clang (3511 files).
Differential Revision: https://reviews.llvm.org/D67127
llvm-svn: 371656
In `DirectoryLookup::LookupFile` parameter `HasBeenMapped` doesn't cover
the case when clang finds a file through a header map but doesn't remap
the lookup filename because the target path is an absolute path. As a
result, -Wnonportable-include-path suppression for header maps
introduced in r301592 wasn't triggered.
Change parameter `HasBeenMapped` to `IsInHeaderMap` and use parameter
`MappedName` to track the filename remapping. This way we can handle
both relative and absolute paths in header maps, and account for their
specific properties, like filename remapping being a property preserved
across lookups in multiple directories.
rdar://problem/39516483
Reviewers: dexonsmith, bruno
Reviewed By: dexonsmith
Subscribers: jkorous, cfe-commits, ributzka
Differential Revision: https://reviews.llvm.org/D58094
llvm-svn: 371655
accessed name to the directory entry
This commit introduces a parallel API that returns a DirectoryEntryRef
to the FileManager, similar to the parallel FileEntryRef API. All
uses will have to be update in follow-up patches. The immediate use of the new API in this
patch fixes the issue where a file manager was reused in clang-scan-deps,
but reported an different file path whenever a framework lookup was done through a symlink.
Differential Revision: https://reviews.llvm.org/D67026
llvm-svn: 370562
Previously, an #error directive with quoted, multi-line content, along with CR+LF line endings wasn't handled correctly.
Differential Revision: https://reviews.llvm.org/D66556
llvm-svn: 370129
This fixes the issue where a filename dependendency was missing if the file that
was referenced with __has_include() was accessed through a symlink in an earlier run,
if the file manager was reused between runs.
llvm-svn: 370081
This reverts commit r369986.
This change added a dependency on the 'dos2unix' tool, which is not one
of our accepted test dependencies and may not exist on all machines that
build Clang.
llvm-svn: 370000
This fixes the issue where a filename dependendency was missing if the file that
was skipped was included through a symlink in an earlier run, if the file
manager was reused between runs.
llvm-svn: 369998
Previously, an #error directive with quoted, multi-line content, along with CR+LF line endings wasn't handled correctly.
Differential Revision: https://reviews.llvm.org/D66556
llvm-svn: 369986
`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
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
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368942
Summary:
Previously __has_builtin(__builtin_*) would return false for
__builtin_*s that we modeled as keywords rather than as functions
(because they take type arguments). With this patch, all builtins
that are called with function-call-like syntax return true from
__has_builtin (covering __builtin_* and also the __is_* and __has_* type
traits and the handful of similar builtins without such a prefix).
Update the documentation on __has_builtin and on type traits to match.
While doing this I noticed the type trait documentation was out of date
and incomplete; that's fixed here too.
Reviewers: aaron.ballman
Subscribers: jfb, kristina, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66100
llvm-svn: 368785
Summary:
As noted on Errc.h:
// * std::errc is just marked with is_error_condition_enum. This means that
// common patters like AnErrorCode == errc::no_such_file_or_directory take
// 4 virtual calls instead of two comparisons.
And on some libstdc++ those virtual functions conclude that
------------------------
int main() {
std::error_code foo = std::make_error_code(std::errc::no_such_file_or_directory);
return foo == std::errc::no_such_file_or_directory;
}
-------------------------
should exit with 0.
Reviewers: thakis, rnk, jfb
Reviewed By: thakis
Subscribers: lebedev.ri, dexonsmith, xbolva00, cfe-commits, caomhin
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66143
llvm-svn: 368739
This regressed in r368322, and was reported as PR42948 and on the
mailing list. The fix is to ignore the specific error code for this
case. The problem doesn't seem to reproduce on Windows, where a
different error code is used instead.
llvm-svn: 368475
Apparently Windows returns the "invalid argument" error code when the
path contains invalid characters such as '<'. The
test/Preprocessor/include-likely-typo.c test does this, so it was
failing after r368322.
Also, the diagnostic requires two arguments, so add the filename.
llvm-svn: 368348
clang would only print "file not found" when it's unable to find a
header file. If the reason for that is a file handle leak, that's not a
very useful error message. For errors that aren't in a small whitelist
("file not found", "file is directory"), print an error with the
strerror() output.
This changes behavior in corner cases: If clang was out of file handles
while looking in one -I dir but then suddenly wasn't when looking in the
next -I dir, and both directories contained a file with the desired
name, previously we'd silently return the file from the second
directory. For this reason, it's important to ignore "is a directory"
for this new diag: if a file foo/foo exists and -I -Ifoo are passed, an
include of "foo" should successfully open file "foo" in directory "foo/"
instead of complaining that "./foo" is a directory.
No test since we mostly hit this when there's a handle leak somewhere,
and currently there isn't one. I manually tested this with the repro
steps in comment 2 on the bug below.
Fixes PR42524.
Differential Revision: https://reviews.llvm.org/D65956
llvm-svn: 368322
Update the callers of FileManager::getFile and FileManager::getDirectory to handle the new llvm::ErrorOr-returning methods.
Signed-off-by: Harlan Haskins <harlan@apple.com>
llvm-svn: 367616
Summary:
Preivously we would only discard it if we failed to parse parameter lists.
If we do not consume the body, parser sees tokens inside directive. In
turn, this leads to spurious diagnostics and a crash in TokenBuffer, see
the added tests.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65517
llvm-svn: 367530
Summary:
The cache recorded the wrong expansion location for all but the first
stringization. It seems uncommon to stringize the same macro argument
multiple times, so this cache doesn't seem that important.
Fixes PR39942
Reviewers: vsk, rsmith
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65428
llvm-svn: 367337
We should re-emit `#pragma once` to ensure the preprocessor will
still honor it when running on minimized sources.
Differential Revision: https://reviews.llvm.org/D64945
llvm-svn: 366509
single quotes are not digit separators after a valid character literal prefix
The single quote character can act as a c++ digit separator.
However, the minimizer shouldn't treat it as such when it's actually following
a valid character literal prefix, like L, U, u, or u8.
Differential Revision: https://reviews.llvm.org/D64525
llvm-svn: 365700
Summary:
Currently HeaderSearch only looks at SearchDir's passed into it, but in
addition to those paths headers can be relative to including file's directory.
This patch makes sure that is taken into account.
Reviewers: gribozavr
Subscribers: jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63295
llvm-svn: 365005
This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a
bit_cast from a value v to a type T. This expression can be evaluated at
compile time under specific circumstances.
The compile time evaluation currently doesn't support bit-fields, but I'm
planning on fixing this in a follow up (some of the logic for figuring this out
is in CodeGen). I'm also planning follow-ups for supporting some more esoteric
types that the constexpr evaluator supports, as well as extending
__builtin_memcpy constexpr evaluation to use the same infrastructure.
rdar://44987528
Differential revision: https://reviews.llvm.org/D62825
llvm-svn: 364954
that might affect the dependency list for a compilation
This commit introduces a dependency directives source minimizer to clang
that minimizes header and source files to the minimum necessary preprocessor
directives for evaluating includes. It reduces the source down to #define, #include,
The source minimizer works by lexing the input with a custom fast lexer that recognizes
the preprocessor directives it cares about, and emitting those directives in the minimized source.
It ignores source code, comments, and normalizes whitespace. It gives up and fails if seems
any directives that it doesn't recognize as valid (e.g. #define 0).
In addition to the source minimizer this patch adds a
-print-dependency-directives-minimized-source CC1 option that allows you to invoke the minimizer
from clang directly.
Differential Revision: https://reviews.llvm.org/D55463
llvm-svn: 362459
The source location builtins are implemented as keywords, but
__has_builtin should still report true for them.
This patch also fixes a test failure on systemz where the alignment
of string literals is 2 not 1.
llvm-svn: 361920
A filename can be remapped with a header map to point to a framework
header and we can find the corresponding framework without the header.
But if the original filename doesn't have a remapped framework name,
we'll fail to find its location and will dereference a null pointer
during diagnostics emission.
Fix by tracking remappings better and emit the note only if a framework
is found before any of the remappings.
rdar://problem/48883447
Reviewers: arphaman, erik.pilkington, jkorous
Reviewed By: arphaman
Subscribers: dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D61707
llvm-svn: 361779
Currently, a pragma AST node's recorded location starts at the
namespace token (such as `omp` in the case of OpenMP) after the
`#pragma` token, and the `#pragma` location isn't available. However,
the `#pragma` location can be useful when, for example, rewriting a
directive using Clang's Rewrite facility.
This patch makes `#pragma` locations available in any `PragmaHandler`
but it doesn't yet make use of them.
This patch also uses the new `struct PragmaIntroducer` to simplify
`Preprocessor::HandlePragmaDirective`. It doesn't do the same for
`PPCallbacks::PragmaDirective` because that changes the API documented
in `clang-tools-extra/docs/pp-trace.rst`, and I'm not sure about
backward compatibility guarantees there.
Reviewed By: ABataev, lebedev.ri, aaron.ballman
Differential Revision: https://reviews.llvm.org/D61643
llvm-svn: 361335
Summary:
By adding a hook to consume all tokens produced by the preprocessor.
The intention of this change is to make it possible to consume the
expanded tokens without re-runnig the preprocessor with minimal changes
to the preprocessor and minimal performance penalty when preprocessing
without recording the tokens.
The added hook is very low-level and reconstructing the expanded token
stream requires more work in the client code, the actual algorithm to
collect the tokens using this hook can be found in the follow-up change.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: eraman, nemanjai, kbarton, jsji, riccibruno, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59885
llvm-svn: 361007
This relands commit rL360833 which caused issues on Win32
bots due to path handling/normalization differences. Now
this uses `sys::path::filename` which should handle
additional edge cases on Win32.
Original commit:
"[Clang][PP] Add the __FILE_NAME__ builtin macro"
This patch adds the __FILE_NAME__ macro that expands to the
last component of the path, similar to __FILE__ except with
a guarantee that only the last path component (without the
separator) will be rendered.
I intend to follow through with discussion of this with WG14
as a potential inclusion in the C standard or failing that,
try to discuss this with GCC developers since this extension
is desired by GCC and Clang users/developers alike.
Differential Revision: https://reviews.llvm.org/D61756
llvm-svn: 360938
This reverts "r360833: [Clang][PP] Add the __FILE_NAME__ builtin macro."
The tests are failing on Windows bots, reverting the patchset until I can
work out why.
llvm-svn: 360842
This patch adds the `__FILE_NAME__` macro that expands to the
last component of the path, similar to `__FILE__` except with
a guarantee that only the last path component (without the
separator) will be rendered.
I intend to follow through with discussion of this with WG14
as a potential inclusion in the C standard or failing that,
try to discuss this with GCC developers since this extension
is desired by GCC and Clang users/developers alike.
Differential Revision: https://reviews.llvm.org/D61756
llvm-svn: 360833
If a header file was processed for the second time, we could end up with a
wrong conditional stack and skipped ranges:
In the particular example, if the header guard is evaluated the second time and
it is decided to skip the conditional block, the corresponding "#endif" is
never seen since the preamble does not include it and we end up in the
Tok.is(tok::eof) case with a wrong conditional stack.
Detect the circular inclusion, emit a diagnostic and stop processing the
inclusion.
llvm-svn: 360418
This trips over a few other limitations, but in the interests of incremental development I'm starting here & I'll look at the issues with -verify and filesystem checks (the fact that the behavior depends on the existence of a 'foo' directory even though it shouldn't need it), etc.
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D61656
llvm-svn: 360195
* __VA_OPT__ is expanded if the *expanded* __VA_ARGS__ is non-empty,
not if the original argument contained no tokens.
* Placemarkers at the start and end of __VA_OPT__ are retained just
long enough to paste them with adjacent ## operators. We never paste
"across" a discarded placemarker.
llvm-svn: 359964
is not used since it consumes all preprocessor directives until it returns
a real token. Using the specific Lexer (i.e. CurLexer->Lex) makes it
possible to stop skipping after an #include or #pragma hdrstop. Previously
the skipping code was only handling CurLexer, now all will be handled
correctly.
Fixes: llvm.org/PR41585
Differential Revision: https://reviews.llvm.org/D61217
llvm-svn: 359506
Summary:
Include insertion in clangd was inserting absolute paths when the
include directory was an absolute path with a double dot. This patch makes sure
double dots are handled both with absolute and relative paths.
Reviewers: sammccall
Subscribers: ilya-biryukov, ioeric, jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60873
llvm-svn: 359078
global module fragment.
We know that the declaration in question should have been introduced by
a '#include', so try to figure out which one and suggest it. Don't
suggest importing the global module fragment itself!
llvm-svn: 358631
and the global and private module fragment.
For now, the private module fragment introducer is ignored, but use of
the global module fragment introducer should be properly enforced.
llvm-svn: 358353
internal lexing steps in the preprocessor.
It is not safe to use the preprocessor's token lookahead except when
operating on the final sequence of tokens that would be produced by
phase 4 of translation. Doing so corrupts the token lookahead cache used
by the parser. (See added testcase for an example.) Lookahead should
instead be viewed as a layer on top of the normal lexer.
Added assertions to catch any further incorrect uses of lookahead within
lexing actions.
llvm-svn: 358230
FileManager constructs a VFS in its constructor if it isn't passed one,
and there's no way to reset it. Make that contract clear by returning a
reference from its accessor.
https://reviews.llvm.org/D59388
llvm-svn: 357038
in the include path.
Instead of making the incorrect claim that the included file has an
absolute path, describe the actual problem: the including file was found
either by absolute path, or relative to such a file, or relative to the
primary source file.
llvm-svn: 356712
Use the new kind for both angled header-name tokens and for
double-quoted header-name tokens.
This is in preparation for C++20's context-sensitive header-name token
formation rules.
llvm-svn: 356530
tokens.
We now actually form an angled_string_literal token for a header name by
concatenation rather than just working out what its contents would be.
This substantially simplifies downstream processing and is necessary for
C++20 header unit imports.
llvm-svn: 356433
__pragma(execution_character_set(push, "UTF-8")) is used in
TraceLoggingProvider.h. This commit implements a no-op handler for
compatability, similar to how the flag -fexec_charset is handled.
Patch by Matt Gardner!
Differential Revision: https://reviews.llvm.org/D58530
llvm-svn: 356185
Change MemoryBufferCache to InMemoryModuleCache, moving it from Basic to
Serialization. Another patch will start using it to manage module build
more explicitly, but this is split out because it's mostly mechanical.
Because of the move to Serialization we can no longer abuse the
Preprocessor to forward it to the ASTReader. Besides the rename and
file move, that means Preprocessor::Preprocessor has one fewer parameter
and ASTReader::ASTReader has one more.
llvm-svn: 355777
When a framework with the same name is available at multiple framework
search paths, we use the first matching location. If a framework at this
location doesn't have all the headers, it can be confusing for
developers because they see only an error `'Foo/Foo.h' file not found`,
can find the complete framework with required header, and don't know the
incomplete framework was used instead.
Add a note explaining a framework without required header was found.
Also mention framework directory path to make it easier to find the
incomplete framework.
rdar://problem/39246514
Reviewers: arphaman, erik.pilkington, jkorous
Reviewed By: jkorous
Subscribers: jkorous, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D56561
llvm-svn: 353231
r352221 caused regressions in CUDA/HIP since device function may use _Float16 whereas host does not support it.
In this case host compilation should not diagnose usage of _Float16 in device functions or variables.
For now just do not diagnose _Float16 for CUDA/HIP. In the future we should have more precise check.
Differential Revision: https://reviews.llvm.org/D57369
llvm-svn: 352488
Float16 support was disabled recently on many platforms, however that
commit still allowed literals of Float16 type to work. This commit
removes those based on the same logic as Float16 disable.
Change-Id: I72243048ae2db3dc47bd3d699843e3edf9c395ea
llvm-svn: 352229
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
The test case had a parse error that was causing the condition string to be misreported. We now have better fallback code for error cases.
llvm-svn: 351470
Summary:
The version of make_absolute which accepted a specific directory to use
as the "base" for the computation could never fail, even though it
returned a std::error_code. The reason for that seems to be historical
-- the CWD flavour (which can fail due to failure to retrieve CWD) was
there first, and the new version was implemented by extending that.
This removes the error return value from the non-CWD overload and
reimplements the CWD version on top of that. This enables us to remove
some dead code where people were pessimistically trying to handle the
errors returned from this function.
Reviewers: zturner, sammccall
Subscribers: hiraditya, kristina, llvm-commits
Differential Revision: https://reviews.llvm.org/D56599
llvm-svn: 351317
In MSVC compatibility mode we were checking not the typo corrected
filename but the original filename.
Reviewers: christylee, compnerd
Reviewed By: christylee
Subscribers: jkorous, dexonsmith, sammccall, hokein, cfe-commits
Differential Revision: https://reviews.llvm.org/D56631
llvm-svn: 351232
This adjusts the source range passed in to the preprocessor callbacks to only include the condition range itself, rather than all of the conditionally skipped tokens.
llvm-svn: 350891
Change in r337953 violated the contract for `CXTranslationUnit_KeepGoing`:
> Do not stop processing when fatal errors are encountered.
Use different approach to fix long processing times with multiple inclusion
cycles. Instead of stopping preprocessing for fatal errors, do this after
reaching the max allowed include depth and only for the files that were
processed already. It is likely but not guaranteed those files cause a cycle.
rdar://problem/46108547
Reviewers: erik.pilkington, arphaman
Reviewed By: erik.pilkington
Subscribers: jkorous, dexonsmith, ilya-biryukov, Dmitry.Kozhevnikov
Differential Revision: https://reviews.llvm.org/D55095
llvm-svn: 348641
When debugging a boost build with a modified
version of Clang, I discovered that the PTH implementation
stores TokenKind in 8 bits. However, we currently have 368
TokenKinds.
The result is that the value gets truncated and the wrong token
gets picked up when including PTH files. It seems that this will
go wrong every time someone uses a token that uses the 9th bit.
Upon asking on IRC, it was brought up that this was a highly
experimental features that was considered a failure. I discovered
via googling that BoostBuild (mostly Boost.Math) is the only user of
this
feature, using the CC1 flag directly. I believe that this can be
transferred over to normal PCH with minimal effort:
https://github.com/boostorg/build/issues/367
Based on advice on IRC and research showing that this is a nearly
completely unused feature, this patch removes it entirely.
Note: I considered leaving the build-flags in place and making them
emit an error/warning, however since I've basically identified and
warned the only user, it seemed better to just remove them.
Differential Revision: https://reviews.llvm.org/D54547
Change-Id: If32744275ef1f585357bd6c1c813d96973c4d8d9
llvm-svn: 348266
Previously these would be transformed into annotation tokens and the
preprocessor would then assume they were real tokens with source
locations and assert/UB.
Other pragmas that produce annotation tokens aren't a problem because
they aren't handled if the parser isn't hooked up - ParsePragma.cpp
registers those handlers & isn't run for pure preprocessing. So they're
treated as unknown pragmas & printed verbatim by the preprocessor.
Perhaps these pragmas should be treated the same way? But they got mixed
in with other __debug pragmas that do need to be handled during
preprocessing.
The third __debug pragma that produces an annotation token is 'captured'
- which had its own fix for this issue - by not inserting the annotation
token in the first place if it detected that it was in preprocessing
mode. I've removed that fix (from Lex/Pragma.cpp) in favor of the more
general one in Frontend/PrintPreprocessedOutput.cpp.
llvm-svn: 346928
Include search paths can be relative paths. The loadSubdirectoryModuleMaps function
should account for that and respect the -working-directory parameter given to Clang.
rdar://46045849
Differential Revision: https://reviews.llvm.org/D54503
llvm-svn: 346822
This reverts commit r345963. We have a path forward now.
Original commit message:
The driver accidentally stopped passing the input filenames on to -cc1
in this mode due to confusion over what action was being requested.
This change also fixes a couple of crashes I encountered when passing
multiple files to such a -cc1 invocation.
llvm-svn: 346130
This reverts commit r345803 and r345915 (a follow-up fix to r345803).
Reason: r345803 blocks our internal integrate because of the new
warnings showing up in too many places. The fix is actually correct,
we will reland it after figuring out how to integrate properly.
llvm-svn: 345963
This patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the LLVM_FALLTHROUGH macro
2. Inserting 'break' before falling through into a case block consisting
of only 'break'.
We were already using this warning with GCC, but its warning behaves
slightly differently. In this patch, the following differences are
relevant:
1. GCC recognizes comments that say "fall through" as annotations, clang
doesn't
2. GCC doesn't warn on "case N: foo(); default: break;", clang does
3. GCC doesn't warn when the case contains a switch, but falls through
the outer case.
I will enable the warning separately in a follow-up patch so that it can
be cleanly reverted if necessary.
Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu
Differential Revision: https://reviews.llvm.org/D53950
llvm-svn: 345882
-fsyntax-only.
The driver accidentally stopped passing the input filenames on to -cc1
in this mode due to confusion over what action was being requested.
This change also fixes a couple of crashes I encountered when passing
multiple files to such a -cc1 invocation.
llvm-svn: 345803
I'm currently working on including macro expansions in the Static Analyzer's
plist output, where I can only access a const SourceManager.
Differential Revision: https://reviews.llvm.org/D53940
llvm-svn: 345741
We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.
Differential revision: https://reviews.llvm.org/D53547
llvm-svn: 345637
This patch moves the virtual file system form clang to llvm so it can be
used by more projects.
Concretely the patch:
- Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support.
- Moves the corresponding unit test from clang to llvm.
- Moves the vfs namespace from clang::vfs to llvm::vfs.
- Formats the lines affected by this change, mostly this is the result of
the added llvm namespace.
RFC on the mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html
Differential revision: https://reviews.llvm.org/D52783
llvm-svn: 344140
Summary:
The test is added in Testcase is at https://reviews.llvm.org/D52775. I tried to add the test to clang's code
completion test, it doesn't reproduce the crash.
Reviewers: sammccall, kristina
Reviewed By: sammccall
Subscribers: kristina, ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D52774
llvm-svn: 343592
Summary:
Similar to Sema typo correction, the Preprocessor typo correction should
also be hidden behind the SpellChecking flag.
Reviewers: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52778
llvm-svn: 343591
Summary: the crash is casued by an assertion in StringRef.
(llvm::StringRef::front() const: Assertion `!empty()' failed.)
Reviewers: sammccall
Subscribers: jsji, cfe-commits
Differential Revision: https://reviews.llvm.org/D52721
llvm-svn: 343481
include-likely-typo.c:3:10: error: '<empty_file_to_include.h>' file not found, did you mean 'empty_file_to_include.h'?
^~~~~~~~~~~~~~~~~~~~~~~~~~~
"empty_file_to_include.h"
1 error generated.
However, if a hint is not found, the error message will show only the trimmed name we use to look for a hint, so:
will result in:
include-leading-nonalpha-no-suggest.c:3:10: fatal error: 'non_existing_file_to_include.h' file not found
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
where the name reported after "fatal error:" doesn't match what the user wrote.
Patch by Jorge Gorbe!
Differential Revision: https://reviews.llvm.org/D52280
This change reports the original file name instead of the trimmed one when a suggestion is not found.
llvm-svn: 342667
This adds a preprocessor callback for the `__has_include` and
`__has_include_next` directives.
Successful checking for the presence of a header should add it to the list of
header dependencies so this overrides the callback in the dependency scanner.
Patch by Pete Cooper with some additions by me.
rdar://problem/39545636
Differential Revision: https://reviews.llvm.org/D30882
llvm-svn: 342517
Summary:
The dir component ("somedir" in #include <somedir/fo...>) is considered fixed.
We append "foo" to each directory on the include path, and then list its files.
Completions are of the forms:
#include <somedir/fo^
foo.h>
fox/
The filter is set to the filename part ("fo"), so fuzzy matching can be
applied to the filename only.
No fancy scoring/priorities are set, and no information is added to
CodeCompleteResult to make smart scoring possible. Could be in future.
Reviewers: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52076
llvm-svn: 342449
Summary:
Most callers I can find are using only `getName()`. Type is used by the
recursive iterator.
Now we don't have to call stat() on every listed file (on most platforms).
Exceptions are e.g. Solaris where readdir() doesn't include type information.
On those platforms we'll still stat() - see D51918.
The result is significantly faster (stat() can be slow).
My motivation: this may allow us to improve clang IO on large TUs with long
include search paths. Caching readdir() results may allow us to skip many stat()
and open() operations on nonexistent files.
Reviewers: bkramer
Subscribers: fedor.sergeev, cfe-commits
Differential Revision: https://reviews.llvm.org/D51921
llvm-svn: 342232
Summary:
When someone writes
#include "<some_file>"
or
#include " some_file "
the compiler returns "file not fuond..." with fonts and quotes that may
make it hard to see there are excess quotes or surprising bytes in the
filename. Assuming that files are usually logically named and start and
end with an alphanumeric character, we can check for the file's
existence by stripping the non-alphanumeric leading or trailing
characters. If the file is found, emit a non-fatal error with a
FixItHint.
Patch by Christy Lee!
Reviewers: aaron.ballman, erikjv, rsmith
Reviewed By: rsmith
Subscribers: lebedev.ri, xbolva00, sammccall, modocache, erikjv, aaron.ballman, cfe-commits
Differential Revision: https://reviews.llvm.org/D51333
llvm-svn: 342177
With clang-cl, when the user specifies /Yc or /Yu without a filename
the compiler uses a #pragma hdrstop in the main source file to
determine the end of the PCH. If a header is specified with /Yc or
/Yu #pragma hdrstop has no effect.
The optional #pragma hdrstop filename argument is not yet supported.
Differential Revision: https://reviews.llvm.org/D51391
llvm-svn: 341963
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
Summary:
Migrate callers to print().
dump() should be useful to downstreams and third parties as a debugging
aid. Everyone trips up on this and creates confusing output.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50661
llvm-svn: 339810
Summary:
This change is to support a new fature in clangd, tests will be send toclang-tools-extra with that change.
Unittests are included in: https://reviews.llvm.org/D50449
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: ioeric, MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D50443
llvm-svn: 339540
Reid Kleckner