| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 109727
|
|
|
|
| |
llvm-svn: 109725
|
|
|
|
|
|
|
|
| |
__debug overflow_stack'.
- For testing crash reporting stuff... you'd think I could just use some C++
code but Doug keeps fixing stuff!
llvm-svn: 109587
|
|
|
|
|
|
| |
PCHs; tests for this to follow.
llvm-svn: 109554
|
|
|
|
|
|
| |
those by Lexer::LexEndOfFile().
llvm-svn: 109486
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reparsing an ASTUnit. When saving a preamble, create a buffer larger
than the actual file we're working with but fill everything from the
end of the preamble to the end of the file with spaces (so the lexer
will quickly skip them). When we load the file, create a buffer of the
same size, filling it with the file and then spaces. Then, instruct
the lexer to start lexing after the preamble, therefore continuing the
parse from the spot where the preamble left off.
It's now possible to perform a simple preamble build + parse (+
reparse) with ASTUnit. However, one has to disable a bunch of checking
in the PCH reader to do so. That part isn't committed; it will likely
be handled with some other kind of flag (e.g., -fno-validate-pch).
As part of this, fix some issues with null termination of the memory
buffers created for the preamble; we were trying to explicitly
NULL-terminate them, even though they were also getting implicitly
NULL terminated, leading to excess warnings about NULL characters in
source files.
llvm-svn: 109445
|
|
|
|
| |
llvm-svn: 109440
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is present.
Rather than using clang_getCursorExtent(), which requires
us to lex the token at the ending position to determine its
length. Then, we'd be comparing [a, b) source ranges that cover the
characters in the range rather than the normal behavior for Clang's
source ranges, which covers the tokens in the range. However, relexing
causes us to read the source file (which may come from a precompiled
header), which is rather unfortunate and affects performance.
In the new scheme, we only use Clang-style source ranges that cover
the tokens in the range. At the entry points where this matters
(clang_annotateTokens, clang_getCursor), we make sure to move source
locations to the start of the token.
Addresses most of <rdar://problem/8049381>.
llvm-svn: 109134
|
|
|
|
|
|
|
|
|
| |
which is the part of the file that contains all of the initial
comments, includes, and preprocessor directives that occur before any
of the actual code. Added a new -print-preamble cc1 action that is
only used for testing.
llvm-svn: 108913
|
|
|
|
|
|
| |
standard's minimum requirements.
llvm-svn: 108837
|
|
|
|
| |
llvm-svn: 108633
|
|
|
|
|
|
|
| |
allow invalid token pastes (when in -fms-extensions mode)
with -Wno-invalid-token-paste
llvm-svn: 108624
|
|
|
|
|
|
|
|
|
|
|
| |
IdentifierInfos.
When loading the PCH, IdentifierInfos that are associated with pragmas cause declarations that use these identifiers to be deserialized (e.g. the "clang" pragma causes the "clang" namespace to be loaded).
We can avoid this if we just use StringRefs for the pragmas.
As a bonus, since we don't have to create and pass IdentifierInfos, the pragma interfaces get a bit more simplified.
llvm-svn: 108237
|
|
|
|
|
|
|
|
| |
so this code is
totally unnecessary.
llvm-svn: 108199
|
|
|
|
|
|
| |
tok::eofs.
llvm-svn: 108175
|
|
|
|
|
|
|
|
|
|
| |
In the case of backtracking, the cached token lexer will be the only
lexer on the stack, without this the token stack will be empty and EOF
won't be returned.
This fixes PR7072.
llvm-svn: 108124
|
|
|
|
| |
llvm-svn: 107836
|
|
|
|
| |
llvm-svn: 106950
|
|
|
|
|
|
| |
target specific preprocessor define as well.
llvm-svn: 106715
|
|
|
|
|
|
|
|
|
|
| |
Fix string concatenation to treat escapes in concatenated strings that
are wide because of other string chunks to process the escapes as wide
themselves. Before we would warn about and miscompile the attached testcase.
This fixes rdar://8040728 - miscompile + warning: hex escape sequence out of range
llvm-svn: 106012
|
|
|
|
| |
llvm-svn: 105830
|
|
|
|
|
|
|
|
| |
wouldn't have their
associated SmallVectors get deallocated.
llvm-svn: 105658
|
|
|
|
|
|
| |
scattered throughout the project Makefiles.
llvm-svn: 105638
|
|
|
|
|
|
| |
- This eliminates most dependencies on how Clang is installed relative to LLVM.
llvm-svn: 105637
|
|
|
|
|
|
| |
been processed, so they don't have to be tip-toed around.
llvm-svn: 105182
|
|
|
|
|
|
| |
literal. Fixes <rdar://problem/8044135>.
llvm-svn: 105181
|
|
|
|
|
|
| |
(radar 8020384)
llvm-svn: 104996
|
|
|
|
|
|
|
|
| |
diagnostics. That would be while we're parsing string literals for the
sole purpose of producing a diagnostic about them. Fixes
<rdar://problem/8026030>.
llvm-svn: 104684
|
|
|
|
|
|
|
|
|
|
|
| |
1) Suppress diagnostics as soon as we form the code-completion
token, so we don't get any error/warning spew from the early
end-of-file.
2) If we consume a code-completion token when we weren't expecting
one, go into a code-completion recovery path that produces the best
results it can based on the context that the parser is in.
llvm-svn: 104585
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
make it miss (invalid) things like:
<<<<<<<
>>>>>>>
and crash if
<<<<<<<
was at the end of the line. When we find a >>>>>>> that is not at the
end of the line, make sure to reset Pos so we don't crash on something
like:
<<<<<<< >>>>>>>
This isn't worth making testcases for, since each would require a new file.
rdar://7987078 - signal 11 compiling "<<<<<<<<<<"
llvm-svn: 103968
|
|
|
|
|
|
|
|
| |
a missing */ since we truncated the file.
This fixes rdar://7948776
llvm-svn: 103913
|
|
|
|
| |
llvm-svn: 102588
|
|
|
|
| |
llvm-svn: 102587
|
|
|
|
|
|
|
|
| |
into ContentCache::getBuffer. This allows it to produce
diagnostics on the broken #include line instead of without a
location.
llvm-svn: 101939
|
|
|
|
|
|
| |
Zhanyong Wan!
llvm-svn: 101813
|
|
|
|
| |
llvm-svn: 101580
|
|
|
|
| |
llvm-svn: 101226
|
|
|
|
|
|
| |
when avoiding paste. Patch by David Peixotto!
llvm-svn: 101218
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in an input file like this:
# 42
int x;
we were emitting:
# <something>
int x;
(with a space before the int) because we weren't clearing the leading
whitespace flag properly after the \n from the directive was handled.
llvm-svn: 101084
|
|
|
|
| |
llvm-svn: 100484
|
|
|
|
|
|
| |
the C-only "optimization".
llvm-svn: 100022
|
|
|
|
| |
llvm-svn: 100018
|
|
|
|
|
|
|
| |
term "fix-it" everywhere and even *I* get tired of long names
sometimes. No functionality change.
llvm-svn: 100008
|
|
|
|
|
|
| |
Abramo Bagnara!
llvm-svn: 99626
|
|
|
|
|
|
| |
form a >>=. Patch by Abramo Bagnara, testcase by me.
llvm-svn: 99624
|
|
|
|
|
|
| |
DependencyFile to not do work in its destructor.
llvm-svn: 99257
|
|
|
|
|
|
|
|
| |
instantiations when we have the corresponding macro definition and by
removing macro definition information from our table when the macro is
undefined.
llvm-svn: 99004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
record (which includes all macro instantiations and definitions). As
with all lay deserialization, this introduces a new external source
(here, an external preprocessing record source) that loads all of the
preprocessed entities prior to iterating over the entities.
The preprocessing record is an optional part of the precompiled header
that is disabled by default (enabled with
-detailed-preprocessing-record). When the preprocessor given to the
PCH writer has a preprocessing record, that record is written into the
PCH file. When the PCH reader is given a PCH file that contains a
preprocessing record, it will be lazily loaded (which, effectively,
implicitly adds -detailed-preprocessing-record). This is the first
case where we have sections of the precompiled header that are
added/removed based on a compilation flag, which is
unfortunate. However, this data consumes ~550k in the PCH file for
Cocoa.h (out of ~9.9MB), and there is a non-trivial cost to gathering
this detailed preprocessing information, so it's too expensive to turn
on by default. In the future, we should investigate a better encoding
of this information.
llvm-svn: 99002
|
|
|
|
|
|
|
|
| |
eliminating the extra PopulatePreprocessingRecord object. This will
become useful once we start writing the preprocessing record to
precompiled headers.
llvm-svn: 98966
|
|
|
|
|
|
| |
tie its creation to a CC1 flag -detailed-preprocessing-record.
llvm-svn: 98963
|