| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
properly. This warning checks that the #ifndef and #define directives at
the beginning of a header refer to the same macro name. Includes a fix-it
hint to correct the header guard.
llvm-svn: 183867
|
| |
|
|
|
|
| |
I am about to move PathV2.h to Path.h.
llvm-svn: 183795
|
| |
|
|
|
|
| |
module but isn't itself part of a module.
llvm-svn: 182263
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.
One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).
llvm-svn: 181869
|
| |
|
|
| |
llvm-svn: 171497
|
| |
|
|
|
|
| |
reached EOF and did not expand the argument into the source context.
llvm-svn: 170980
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
| |
|
|
|
|
|
|
| |
within its own argument list. The original definition is used for the immediate
expansion, but the new definition is used for any subsequent occurences within
the argument list or after the expansion.
llvm-svn: 162906
|
| |
|
|
| |
llvm-svn: 158970
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enable incremental parsing by the Preprocessor,
where more code can be provided after an EOF.
It mainly prevents the tearing down of the topmost lexer.
To be used like this:
PP.enableIncrementalProcessing();
while (getMoreSource()) {
while (Parser.ParseTopLevelDecl(ADecl)) {...}
}
PP.enableIncrementalProcessing(false);
llvm-svn: 152914
|
| |
|
|
|
|
|
| |
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
llvm-svn: 149799
|
| |
|
|
|
|
|
|
|
| |
features needed for a particular module to be available. This allows
mixed-language modules, where certain headers only work under some
language variants (e.g., in C++, std.tuple might only be available in
C++11 mode).
llvm-svn: 147387
|
| |
|
|
| |
llvm-svn: 147208
|
| |
|
|
|
|
|
|
| |
found within that umbrella directory that were not actually included
by the umbrella header. They should either be referenced in the module
map or included by the umbrella header.
llvm-svn: 147207
|
| |
|
|
|
|
|
| |
actually a terribly good heuristic, and the world is too horrible for
it to work.
llvm-svn: 146393
|
| |
|
|
|
|
| |
Me, I believe him.
llvm-svn: 142327
|
| |
|
|
| |
llvm-svn: 142324
|
| |
|
|
|
|
|
| |
public. Add a __private_macro__ directive to hide a macro, similar to
the __module_private__ declaration specifier.
llvm-svn: 142188
|
| |
|
|
| |
llvm-svn: 141681
|
| |
|
|
|
|
|
|
|
|
|
| |
CoreFoundation object-transfer properties audited, and add a #pragma
to cause them to be automatically applied to functions in a particular
span of code. This has to be implemented largely in the preprocessor
because of the requirement that the region be entirely contained in
a single file; that's hard to impose from the parser without registering
for a ton of callbacks.
llvm-svn: 140846
|
| |
|
|
|
|
| |
It already works (and is useful with) macro locs as well.
llvm-svn: 140057
|
| |
|
|
|
|
|
|
|
|
|
|
| |
keyword. We now handle this keyword in HandleIdentifier, making a note
for ourselves when we've seen the __import_module__ keyword so that
the next lexed token can trigger a module import (if needed). This
greatly simplifies Preprocessor::Lex(), and completely erases the 5.5%
-Eonly slowdown Argiris noted when I originally implemented
__import_module__. Big thanks to Argiris for noting that horrible
regression!
llvm-svn: 139265
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would cut off the source file buffer at the code-completion
point; this impeded code-completion inside C++ inline methods and,
recently, with buffering ObjC methods.
Have the code-completion inserted into the source buffer so that it can
be buffered along with a method body. When we actually hit the code-completion
point the cut-off lexing or parsing.
Fixes rdar://10056932&8319466
llvm-svn: 139086
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently getMacroArgExpandedLocation is very inefficient and for the case
of a location pointing at the main file it will end up checking almost all of
the SLocEntries. Make it faster:
-Use a map of macro argument chunks to their expanded source location. The map
is for a single source file, it's stored in the file's ContentCache and lazily
computed, like the source lines cache.
-In SLocEntry's FileInfo add an 'unsigned NumCreatedFIDs' field that keeps track
of the number of FileIDs (files and macros) that were created during preprocessing
of that particular file SLocEntry. This is useful when computing the macro argument
map in skipping included files while scanning for macro arg FileIDs that lexed from
a specific source file. Due to padding, the new field does not increase the size
of SLocEntry.
llvm-svn: 138225
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously macro expanded tokens were added to Preprocessor's bump allocator and never released,
even after the TokenLexer that were lexing them was finished, thus they were wasting memory.
A very "useful" boost library was causing clang to eat 1 GB just for the expanded macro tokens.
Introduce a special cache that works like a stack; a TokenLexer can add the macro expanded tokens
in the cache, and when it finishes, the tokens are removed from the end of the cache.
Now consumed memory by expanded tokens for that library is ~ 1.5 MB.
Part of rdar://9327049.
llvm-svn: 134105
|
| |
|
|
|
|
|
|
| |
The previous name was inaccurate as this token in fact appears at
the end of every preprocessing directive, not just macro definitions.
No functionality change, except for a diagnostic tweak.
llvm-svn: 126631
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Diagnostic pragmas are broken because we don't keep track of the diagnostic state changes and we only check the current/latest state.
Problems manifest if a diagnostic is emitted for a source line that has different diagnostic state than the current state; this can affect
a lot of places, like C++ inline methods, template instantiations, the lexer, etc.
Fix the issue by having the Diagnostic object keep track of the source location of the pragmas so that it is able to know what is the diagnostic state at any given source location.
Fixes rdar://8365684.
llvm-svn: 121873
|
| |
|
|
|
|
|
|
| |
into ContentCache::getBuffer. This allows it to produce
diagnostics on the broken #include line instead of without a
location.
llvm-svn: 101939
|
| |
|
|
|
|
| |
DependencyFile to not do work in its destructor.
llvm-svn: 99257
|
| |
|
|
|
|
|
| |
SourceManager versions), updating those callers that need to recover
gracefully from failure.
llvm-svn: 98665
|
| |
|
|
|
|
| |
simplifying the SourceManager interfaces somewhat.
llvm-svn: 98598
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
SourceManager's getBuffer() (and similar) operations. This abstract
can be used to force callers to cope with errors in getBuffer(), such
as missing files and changed files. Fix a bunch of callers to use the
new interface.
Add some very basic checks for file consistency (file size,
modification time) into ContentCache::getBuffer(), although these
checks don't help much until we've updated the main callers (e.g.,
SourceManager::getSpelling()).
llvm-svn: 98585
|
| |
|
|
|
|
|
|
| |
definitions from a precompiled header. This ensures that
code-completion with macro names behaves the same with or without
precompiled headers.
llvm-svn: 92497
|
| |
|
|
|
|
|
|
| |
expected to fail.
Also, update SourceManager.h doxyments for getBuffer() to reflect reality.
llvm-svn: 90701
|
| |
|
|
|
|
| |
should be forced to deal with error conditions.
llvm-svn: 90700
|
| |
|
|
|
|
|
|
|
|
|
|
| |
in diagnostics when we fail to open a file. This allows us to
report things like:
$ clang test.c -I.
test.c:2:10: fatal error: error opening file './foo.h': Permission denied
#include "foo.h"
^
llvm-svn: 90276
|
| |
|
|
|
|
|
|
|
|
| |
stat a file but where mmaping it fails. In this case, we emit an
error like:
t.c:1:10: fatal error: error opening file '../../foo.h'
instead of "cannot find file".
llvm-svn: 90110
|
| |
|
|
| |
llvm-svn: 90080
|
| |
|
|
| |
llvm-svn: 81346
|
| |
|
|
| |
llvm-svn: 69987
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
and the token after the # should be expanded if it is not a valid directive.
This allows us to transform things like:
#define FOO BAR
# FOO
into # BAR, even though FOO is not normally expanded for directives.
This should fix PR3833
llvm-svn: 67236
|
| |
|
|
| |
llvm-svn: 66954
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now instead of just tracking the expansion history, also track the full
range of the macro that got replaced. For object-like macros, this doesn't
change anything. For _Pragma and function-like macros, this means we track
the locations of the ')'.
This is required for PR3579 because apparently GCC uses the line of the ')'
of a function-like macro as the location to expand __LINE__ to.
llvm-svn: 64601
|
| |
|
|
| |
llvm-svn: 64503
|
| |
|
|
| |
llvm-svn: 63925
|
| |
|
|
|
|
| |
redundant #includes. Patch by Anders Johnsen!
llvm-svn: 63271
|
| |
|
|
|
|
|
|
|
| |
.def file for each library. This means that adding a diagnostic
to sema doesn't require all the other libraries to be rebuilt.
Patch by Anders Johnsen!
llvm-svn: 63111
|
| |
|
|
|
|
|
| |
safe because a #line can change the file characteristic on a per-loc
basis.
llvm-svn: 62502
|
| |
|
|
| |
llvm-svn: 62424
|
| |
|
|
|
|
| |
of a SourceLocation. This should speed it up and definitely simplifies it.
llvm-svn: 62422
|