| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 134996
|
| |
|
|
| |
llvm-svn: 133633
|
| |
|
|
|
|
| |
use the deprecated forms of llvm::StringMap::GetOrCreateValue().
llvm-svn: 133515
|
| |
|
|
| |
llvm-svn: 132059
|
| |
|
|
|
|
|
|
|
| |
Patch by Matthieu Monrocq with tweaks by me to avoid StringRefs in the static
diagnostic data structures, which resulted in a huge global-var-init function.
Depends on llvm commit r132046.
llvm-svn: 132047
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
header. Getting it in the wrong order generated incorrect line markers in -E
mode. In the testcase from PR9861 we used to generate:
# 1 "test.c" 2
# 1 "./foobar.h" 1
# 0 "./foobar.h"
# 0 "./foobar.h" 3
# 2 "test.c" 2
now we properly produce:
# 1 "test.c" 2
# 1 "./foobar.h" 1
# 1 "./foobar.h" 3
# 2 "test.c" 2
This fixes PR9861.
llvm-svn: 131871
|
| |
|
|
|
|
|
|
|
| |
includes get resolved, especially when they are found relatively to
another include file. We also try to get it working for framework
includes, but that part of the code is untested, as I don't have a code
base that uses it.
llvm-svn: 130246
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clients to observe the exact path through which an #included file was
located. This is very useful when trying to record and replay inclusion
operations without it beind influenced by the aggressive caching done
inside the FileManager to avoid redundant system calls and filesystem
operations.
The work to compute and return this is only done in the presence of
callbacks, so it should have no effect on normal compilation.
Patch by Manuel Klimek.
llvm-svn: 127742
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 126221
|
| |
|
|
| |
llvm-svn: 126220
|
| |
|
|
| |
llvm-svn: 125474
|
| |
|
|
| |
llvm-svn: 125473
|
| |
|
|
| |
llvm-svn: 122394
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
SourceManager::getPresumedLoc(), so that we don't try to make use of
an invalid presumed location. Doing so can cause crashes.
llvm-svn: 118885
|
| |
|
|
| |
llvm-svn: 116825
|
| |
|
|
|
|
| |
That, and keep aKor happy :P.
llvm-svn: 114816
|
| |
|
|
| |
llvm-svn: 114814
|
| |
|
|
|
|
|
|
| |
spelled (#pragma, _Pragma, __pragma). In -E mode, use that information
to add appropriate newlines when translating _Pragma and __pragma into
#pragma, like GCC does. Fixes <rdar://problem/8412013>.
llvm-svn: 113553
|
| |
|
|
| |
llvm-svn: 113125
|
| |
|
|
|
|
|
| |
#pragma without requiring it to be in the "clang" namespace, from
Louis Gerbarg!
llvm-svn: 112484
|
| |
|
|
| |
llvm-svn: 112392
|
| |
|
|
|
|
| |
Patch by Francois Pichet!
llvm-svn: 112391
|
| |
|
|
|
|
|
| |
CrashRecovery since it avoids sending a signal which may be intercepted by the
debugger.
llvm-svn: 111449
|
| |
|
|
|
|
| |
those crash paths.
llvm-svn: 111311
|
| |
|
|
| |
llvm-svn: 111234
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 106950
|
| |
|
|
| |
llvm-svn: 105830
|
| |
|
|
|
|
| |
recovery for those that need it.
llvm-svn: 98689
|
| |
|
|
|
|
| |
returns a StringRef. Use it to simplify some repetitive code.
llvm-svn: 97322
|
| |
|
|
|
|
|
| |
is #included with "foo.h" style syntax instead of framework syntax.
It produced too much noise.
llvm-svn: 94120
|
| |
|
|
|
|
| |
nicer than passing around two const char*'s.
llvm-svn: 93094
|
| |
|
|
|
|
|
| |
import other headers within the same framework with the full
framework path, not with a relative include.
llvm-svn: 93083
|
| |
|
|
| |
llvm-svn: 81346
|
| |
|
|
| |
llvm-svn: 75431
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
declaration in the AST.
The new ASTContext::getCommentForDecl function searches for a comment
that is attached to the given declaration, and returns that comment,
which may be composed of several comment blocks.
Comments are always available in an AST. However, to avoid harming
performance, we don't actually parse the comments. Rather, we keep the
source ranges of all of the comments within a large, sorted vector,
then lazily extract comments via a binary search in that vector only
when needed (which never occurs in a "normal" compile).
Comments are written to a precompiled header/AST file as a blob of
source ranges. That blob is only lazily loaded when one requests a
comment for a declaration (this never occurs in a "normal" compile).
The indexer testbed now supports comment extraction. When the
-point-at location points to a declaration with a Doxygen-style
comment, the indexer testbed prints the associated comment
block(s). See test/Index/comments.c for an example.
Some notes:
- We don't actually attempt to parse the comment blocks themselves,
beyond identifying them as Doxygen comment blocks to associate them
with a declaration.
- We won't find comment blocks that aren't adjacent to the
declaration, because we start our search based on the location of
the declaration.
- We don't go through the necessary hops to find, for example,
whether some redeclaration of a declaration has comments when our
current declaration does not. Similarly, we don't attempt to
associate a \param Foo marker in a function body comment with the
parameter named Foo (although that is certainly possible).
- Verification of my "no performance impact" claims is still "to be
done".
llvm-svn: 74704
|
| |
|
|
|
|
|
|
| |
line, and when the pragma is at the end of a file. In this case, the last
token consumed could pop the lexer, invalidating CurPPLexer. Thanks to
Peter Thoman for pointing it out.
llvm-svn: 73689
|
| |
|
|
|
|
|
| |
the file at the point of the pragma. This allows clang to know that all
sourcelocations after the pragma are in a system header.
llvm-svn: 73376
|
| |
|
|
| |
llvm-svn: 71572
|
| |
|
|
|
|
|
|
|
| |
will let us test for multiple different warning modes in the same
file in regression tests.
This implements rdar://2362963, a 10-year old feature request :)
llvm-svn: 69560
|
| |
|
|
|
|
|
|
|
|
| |
support it. I don't know what evaluation method we use for complex
arithmetic, so I don't know whether/if we should warn about use of
CX_LIMITED_RANGE.
This concludes my planned hacking on STDC pragmas, flame away :)
llvm-svn: 69556
|
| |
|
|
| |
llvm-svn: 69554
|
| |
|
|
| |
llvm-svn: 69551
|
| |
|
|
| |
llvm-svn: 69550
|
| |
|
|
| |
llvm-svn: 69547
|