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
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
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
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
Fixes a problem when we have multiple inclusion cycles and try to
enumerate all possible ways to reach the max inclusion depth.
rdar://problem/38871876
Reviewers: bruno, rsmith, jkorous, aaron.ballman
Reviewed By: bruno, jkorous, aaron.ballman
Subscribers: dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D48786
llvm-svn: 337953
Implement support for MS-style PCH through headers.
This enables support for /Yc and /Yu where the through header is either
on the command line or included in the source. It replaces the current
support the requires the header also be specified with /FI.
This change adds a -cc1 option -pch-through-header that is used to either
start or stop compilation during PCH create or use.
When creating a PCH, the compilation ends after compilation of the through
header.
When using a PCH, tokens are skipped until after the through header is seen.
Patch By: mikerice
Differential Revision: https://reviews.llvm.org/D46652
llvm-svn: 336379
This commit relands r331904.
Adding a SrcMgr::CharacteristicKind parameter to the InclusionDirective
in PPCallbacks, and updating calls to that function. This will be useful
in https://reviews.llvm.org/D43778 to determine which includes are
system
headers.
Differential Revision: https://reviews.llvm.org/D46614
llvm-svn: 332021
Adding a SrcMgr::CharacteristicKind parameter to the InclusionDirective
in PPCallbacks, and updating calls to that function. This will be useful
in https://reviews.llvm.org/D43778 to determine which includes are system
headers.
Differential Revision: https://reviews.llvm.org/D46614
llvm-svn: 331904
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
When a '>>' token is split into two '>' tokens (in C++11 onwards), or (as an
extension) when we do the same for other tokens starting with a '>', we can't
just use a location pointing to the first '>' as the location of the split
token, because that would result in our miscomputing the length and spelling
for the token. As a consequence, for example, a refactoring replacing 'A<X>'
with something else would sometimes replace one character too many, and
similarly diagnostics highlighting a template-id source range would highlight
one character too many.
Fix this by creating an expansion range covering the first character of the
'>>' token, whose spelling is '>'. For this to work, we generalize the
expansion range of a macro FileID to be either a token range (the common case)
or a character range (used in this new case).
llvm-svn: 331155
LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the
default macro instead of a reinvented one.
See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.
llvm-svn: 331069
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
When skipping building the module for a private framework module,
LangOpts.CurrentModule isn't enough for implict modules builds; for
instance, in case a private module is built while building a public one,
LangOpts.CurrentModule doesn't reflect the -fmodule-name being passed
down, but instead the module name which triggered the build.
Store the actual -fmodule-name in LangOpts.ModuleName and actually
check a name was provided during compiler invocation in order to
skip building the private module.
rdar://problem/38434694
llvm-svn: 328053
Assume Foo.framework with two module maps and two modules Foo and
Foo_Private.
Framework authors need to skip building both Foo and Foo_Private when
using -fmodule-name=Foo, since both are part of the framework and used
interchangeably during compilation.
rdar://problem/37500098
llvm-svn: 325305
The skipped preprocessor ranges are now serialized in the AST PCH file. This fixes, for example, libclang's clang_getSkippedRanges() returning zero ranges after reparsing a translation unit.
Differential Revision: https://reviews.llvm.org/D20124
llvm-svn: 322503
When modules come from module map files explicitly specified by
-fmodule-map-file= arguments, allow those to override/shadow modules
with the same name that are found implicitly by header search. If such a
module is looked up by name (e.g. @import), we will always find the one
from -fmodule-map-file. If we try to use a shadowed module by including
one of its headers report an error.
This enables developers to force use of a specific copy of their module
to be used if there are multiple copies that would otherwise be visible,
for example if they develop modules that are installed in the default
search paths.
Patch originally by Ben Langmuir,
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html
Based on cfe-dev discussion:
http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html
Differential Revision: https://reviews.llvm.org/D31269
rdar://problem/23612102
llvm-svn: 321855
When modules come from module map files explicitly specified by
-fmodule-map-file= arguments, allow those to override/shadow modules
with the same name that are found implicitly by header search. If such a
module is looked up by name (e.g. @import), we will always find the one
from -fmodule-map-file. If we try to use a shadowed module by including
one of its headers report an error.
This enables developers to force use of a specific copy of their module
to be used if there are multiple copies that would otherwise be visible,
for example if they develop modules that are installed in the default
search paths.
Patch originally by Ben Langmuir,
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html
Based on cfe-dev discussion:
http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html
Differential Revision: https://reviews.llvm.org/D31269
rdar://problem/23612102
llvm-svn: 321781
When a preamble ends in a conditional preprocessor block that is being
skipped, the preprocessor needs to continue skipping that block when
the preamble is used.
This fixes PR34570.
llvm-svn: 317308
This patch implements an extension to the preprocessor:
__VA_OPT__(contents) --> which expands into its contents if variadic arguments are supplied to the parent macro, or behaves as an empty token if none.
- Currently this feature is only enabled for C++2a (this could be enabled, with some careful tweaks, for other dialects with the appropriate extension or compatibility warnings)
- The patch was reviewed here: https://reviews.llvm.org/D35782 and asides from the above (and moving some of the definition and expansion recognition logic into the corresponding state machines), I believe I incorporated all of Richard's suggestions.
A few technicalities (most of which were clarified through private correspondence between rsmith, hubert and thomas) are worth mentioning. Given:
#define F(a,...) a #__VA_OPT__(a ## a) a ## __VA_OPT__(__VA_ARGS__)
- The call F(,) Does not supply any tokens for the variadic arguments and hence VA_OPT behaves as a placeholder.
- When expanding VA_OPT (for e.g. F(,1) token pasting occurs eagerly within its contents if the contents need to be stringified.
- A hash or a hashhash prior to VA_OPT does not inhibit expansion of arguments if they are the first token within VA_OPT.
- When a variadic argument is supplied, argument substitution occurs within the contents as does stringification - and these resulting tokens are inserted back into the macro expansions token stream just prior to the entire stream being rescanned and concatenated.
See wg21.link/P0306 for further details on the feature.
Acknowledgment: This patch would have been poorer if not for Richard Smith's usual thoughtful analysis and feedback.
llvm-svn: 315840
Summary:
This fixes PR34547.
`Lexer::LexEndOfFile` handles recording of ConditionalStack for
preamble and reporting errors about unmatched conditionalal PP
directives.
However, SkipExcludedConditionalBlock contianed duplicated logic for
reporting errors and clearing ConditionalStack, but not for preamble
recording.
This fix removes error reporting logic from
`SkipExcludedConditionalBlock`, unmatched PP conditionals are now
reported inside `Lexer::LexEndOfFile`.
Reviewers: erikjv, klimek, bkramer
Reviewed By: erikjv
Subscribers: nik, cfe-commits
Differential Revision: https://reviews.llvm.org/D37700
llvm-svn: 313014
This patch teaches the preprocessor to report more precise source ranges for
code that is skipped due to conditional directives.
The new behavior includes the '#' from the opening directive and the full text
of the line containing the closing directive in the skipped area. This matches
up clang's behavior (we don't IRGen the code between the closing "endif" and
the end of a line).
This also affects the code coverage implementation. See llvm.org/PR34166 (this
also happens to be rdar://problem/23224058).
The old behavior (report the end of the skipped range as the end
location of the 'endif' token) is preserved for indexing clients.
Differential Revision: https://reviews.llvm.org/D36642
llvm-svn: 312947
- This will also be used for the forthcoming __VA_OPT__ feature approved for C++2a.
- recommended by rsmith during his review of the __VA_OPT__ patch (https://reviews.llvm.org/D35782)
llvm-svn: 308948
- Extracted the reading of the tokens out into a separate function.
- Replace 'Argument' with 'Parameter' when referring to the identifiers of the macro definition (as opposed to the supplied arguments - MacroArgs - during the macro invocation).
This is in preparation for submitting patches for review to implement __VA_OPT__ which will otherwise just keep lengthening the HandleDefineDirective function and making it less comprehensible.
I will also directly update some extra clang tooling that is broken by the change from Argument to Parameter.
Hopefully the bots will stay appeased.
Thanks!
llvm-svn: 308190
- Extracted the reading of the tokens out into a separate function.
- Replace 'Argument' with 'Parameter' when referring to the identifiers of the macro definition (as opposed to the supplied arguments - MacroArgs - during the macro invocation).
This is in preparation for submitting patches for review to implement __VA_OPT__ which will otherwise just keep lengthening the HandleDefineDirective function and making it less comprehensible.
Thanks!
llvm-svn: 308157
The goal of this commit is to fix clang-format so it does not merge tokens when
using the alternative spelling keywords. (eg: "not foo" should not become "notfoo")
The problem is that Preprocessor::HandleIdentifier used to drop the identifier info
from the token for these keyword. This means the first condition of
TokenAnnotator::spaceRequiredBefore is not met. We could add explicit check for
the spelling in that condition, but I think it is better to keep the IdentifierInfo
and handle the operator keyword explicitly when needed. That actually leads to simpler
code, and probably slightly more efficient as well.
Another side effect of this change is that __identifier(and) will now work as
one would expect, removing a FIXME from the MicrosoftExtensions.cpp test
Differential Revision: https://reviews.llvm.org/D35172
llvm-svn: 308008
'HandleEndifDirective' asserts that 'WasSkipping' is false, so switch to using 'FoundNonSkip' as the hint for 'SingleFileParseMode' to keep going with parsing.
llvm-svn: 305940
This is useful for being able to parse the preprocessor directive blocks even if the header, that defined the macro that is checked, hasn't been included.
Differential Revision: https://reviews.llvm.org/D34263
llvm-svn: 305797
This is useful for parsing a single file, as a fast/inaccurate 'mode' that can still provide declarations from the file, like the classes and their methods.
llvm-svn: 305044
This patch adds support for a `header` declaration in a module map to specify
certain `stat` information (currently, size and mtime) about that header file.
This has two purposes:
- It removes the need to eagerly `stat` every file referenced by a module map.
Instead, we track a list of unresolved header files with each size / mtime
(actually, for simplicity, we track submodules with such headers), and when
attempting to look up a header file based on a `FileEntry`, we check if there
are any unresolved header directives with that `FileEntry`'s size / mtime and
perform deferred `stat`s if so.
- It permits a preprocessed module to be compiled without the original files
being present on disk. The only reason we used to need those files was to get
the `stat` information in order to do header -> module lookups when using the
module. If we're provided with the `stat` information in the preprocessed
module, we can avoid requiring the files to exist.
Unlike most `header` directives, if a `header` directive with `stat`
information has no corresponding on-disk file the enclosing module is *not*
marked unavailable (so that behavior is consistent regardless of whether we've
resolved a header directive, and so that preprocessed modules don't get marked
unavailable). We could actually do this for all `header` directives: the only
reason we mark the module unavailable if headers are missing is to give a
diagnostic slightly earlier (rather than waiting until we actually try to build
the module / load and validate its .pcm file).
Differential Revision: https://reviews.llvm.org/D33703
llvm-svn: 304515
and it has an include guard, produce callbacks for a module import, not for a
skipped non-modular header.
Fixes -E output when preprocessing a module to list these cases as a module
import, rather than suppressing the #include and losing the import side effect.
llvm-svn: 304183
This allows #line directives to appear in system headers that have code
that clang would normally warn on. This is compatible with GCC, which is
easy to test by running `gcc -E`.
Fixes PR30752
llvm-svn: 303582
remove the mechanism for doing so.
This mechanism was incorrect in the presence of preprocessed modules (and
#pragma clang module begin/end).
llvm-svn: 303469
These pragmas are intended to simulate the effect of entering or leaving a file
with an associated module. This is not completely implemented yet: declarations
between the pragmas will not be attributed to the correct module, but macro
visibility is already functional.
Modules named by #pragma clang module begin must already be known to clang (in
some module map that's either loaded or on the search path).
llvm-svn: 302098
Benjamin Kramer