Change the warning message for -Wincomplete-umbrella to report the location of the umbrella header;
Differential Revision: https://reviews.llvm.org/D82118
Before the change the diagnostic for
module unknown.submodule {}
was "error: expected module name" which is incorrect and misleading
because both "unknown" and "submodule" are valid module names.
We already have a better error message when a parent module is a
submodule itself and is missing. Make the error for a missing top-level
module more like the one for a submodule.
rdar://problem/64424407
Reviewed By: bruno
Differential Revision: https://reviews.llvm.org/D84458
HeaderSearch was marking requested HeaderFileInfo as Resolved only based on
the presence of ExternalSource. As the result, using any module was enough
to set ExternalSource and headers unknown to this module would have
HeaderFileInfo with empty fields, including `isImport = 0`, `NumIncludes = 0`.
Such HeaderFileInfo was preserved without changes regardless of how the
header was used in other modules and caused incorrect result in
`HeaderSearch::ShouldEnterIncludeFile`.
Fix by marking HeaderFileInfo as Resolved only if ExternalSource knows
about this header.
rdar://problem/62126911
Reviewed By: bruno
Differential Revision: https://reviews.llvm.org/D80263
Summary:
We would like to use NumericLiteralParser in the implementation of the
syntax tree builder, and plumbing a preprocessor there seems
inconvenient and superfluous.
Reviewers: eduucaldas
Reviewed By: eduucaldas
Subscribers: gribozavr2, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D83480
Summary:
Add an `-Wundef-prefix=<arg1>,<arg2>...` option, which is similar to `-Wundef`, but only give warnings for undefined macros with the given prefixes.
Reviewers: ributzka, steven_wu, cishida, bruno, arphaman, rsmith
Reviewed By: ributzka, arphaman
Subscribers: riccibruno, dexonsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80751
This patch was authored by Zixu Wang <zixu_wang@apple.com>
Previously, this would fail if the builtin headers had been "claimed" by
a different module that wraps these builtin headers. libc++ does this,
for example.
This change adds a test demonstrating this situation; the test fails
without the fix.
The commit 3c28a2dc6b introduced the check that checks if we're
trying to re-enter a main file when building a preamble. Unfortunately this slowed down the preamble
compilation by 80-90% in some test cases, as translateFile is really slow. This change checks
to see if the FileEntry is the main file without calling translateFile, but by using the new
isMainFile check instead. This speeds up preamble building by 1.5-2x for certain test cases that we have.
rdar://59361291
Differential Revision: https://reviews.llvm.org/D79834
In D49466, sys::path::replace_path_prefix was used instead startswith for -f[macro/debug/file]-prefix-map options.
However those were reverted later (commit rG3bb24bf25767ef5bbcef958b484e7a06d8689204) due to broken Windows tests.
This patch restores those replace_path_prefix calls.
It also modifies the prefix matching to be case-insensitive under Windows.
Differential Revision : https://reviews.llvm.org/D76869
D52774 fixed a bug with typo correction of includes, but didn't add
a test.
D65907 then broke recovery of typo correction of includes again,
because it extracted the code that writes to Filename to a separate
function that took the parameter not by reference.
Fix that, and also don't repeat the slash normalization computation
and fix both lookup and regular file name after recovery.
Differential Revision: https://reviews.llvm.org/D79595
See PR45812 for motivation.
No explicit test since I couldn't figure out how to get the
current disk drive in lower case into a form in lit where I could
mkdir it and cd to it. But the change does have test coverage in
that I can remove the case normalization in lit, and tests failed
on several bots (and for me locally if in a pwd with a lower-case
drive) without that normalization prior to this change.
Differential Revision: https://reviews.llvm.org/D79531
The approach in D30000 assumes that the '/' returned by path::begin()
is the first element for absolute paths, but that's not true on
Windows.
Also, on Windows backslashes in include lines often end up escaped
so that there are two of them. Having backslashes in include lines
is undefined behavior in most cases and implementation-defined
behavior in C++20, but since clang treats it as normal repeated
path separators, the diagnostic should too.
Unbreaks -Wnonportable-include-path for absolute paths on Windows,
and unbreaks it on non-Windows in the case of absolute paths with
repeated directory separators.
This affects e.g. the `#include __FILE__` technique if the file
passed to clang has the wrong case for the drive letter. Before:
C:\src\llvm-project>bin\clang-cl.exe c:\src\llvm-project\test.cc
c:\\src\\llvm-project\\test.cc(4,10): warning: non-portable path to file
'"c\\srccllvm-projectctest.cc.'; specified path differs in case from
file name on disk [-Wnonportable-include-path]
^
Now:
C:\src\llvm-project> out\gn\bin\clang-cl c:\src\llvm-project\test.cc
c:\\src\\llvm-project\\test.cc(4,10): warning: non-portable path to file
'"C:\\src\\llvm-project\\test.cc"'; specified path differs in case from
file name on disk [-Wnonportable-include-path]
^
Differential Revision: https://reviews.llvm.org/D79223
Fix a few bugs where we would fail to properly determine header to
module correspondence when determining whether to suggest a #include or
import, and suggest a #include more often in language modes where there
is no import syntax. Generally, if the target is in a header with
include guards or #pragma once, we should suggest either #including or
importing that header, and not importing a module that happens to
textually include it.
In passing, improve the notes we attach to the corresponding
diagnostics: calling an entity that we couldn't see "previous" is
confusing.
If a PCH is used for compilation, SourceManager::isInMainFile()
returns true even for the "<built-in>" predefines area. Using -D
only for the TU compilation may trigger -Wunused-macros for it.
It is admitedly a bit fishy to set a macro only for a TU and not
for the PCH, but this works fine if the PCH does not use the macro
(I couldn't find a statement on this for Clang, but GCC explicitly
allows this in the docs).
Differential Revision: https://reviews.llvm.org/D73846
Summary:
Macro argument expansion logic relies on skipping file IDs that created
as a result of an include. Unfortunately it fails to do that for
predefined buffer since it doesn't have a valid insertion location.
As a result of that any file ID created for an include inside the
predefined buffers breaks the traversal logic in
SourceManager::computeMacroArgsCache.
To fix this issue we first record number of created FIDs for predefined
buffer, and then skip them explicitly in source manager.
Another solution would be to just give predefined buffers a valid source
location, but it is unclear where that should be..
Reviewers: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D78649
Summary:
This is guaranteed to be a no-op without the preamble, so should be a
no-op with it too.
Partially fixes https://github.com/clangd/clangd/issues/337
This doesn't yet work for #ifndef guards, which are not recognized in preambles.
see D78038
I can't for the life of me work out how to test this outside clangd.
The original reentrant preamble diagnostic was untested, I added a test
to clangd for that too.
Reviewers: kadircet
Subscribers: ilya-biryukov, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D78366
whether they have missing header files.
Whether a module's headers happen to be present on the local file system
should make no difference to whether we make its contents visible when
importing another module that re-exports it. If we have an up-to-date
AST file that we can load, that's all that matters.
This fixes the ability to header syntax checking for modular headers in
C++20 mode (or in prior modes where -fmodules-local-submodule-visibility
is enabled but -fmodules is not).
modules too.
This more accurately reflects the semantics of this flag, as distinct
from "IsAvailable", which (in an explicit modules world) only describes
whether a module is buildable, not whether it's importable.
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
Chuyang Chen