| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 147635
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AST file more lazy, so that we don't eagerly load that information for
all known identifiers each time a new AST file is loaded. The eager
reloading made some sense in the context of precompiled headers, since
very few identifiers were defined before PCH load time. With modules,
however, a huge amount of code can get parsed before we see an
@import, so laziness becomes important here.
The approach taken to make this information lazy is fairly simple:
when we load a new AST file, we mark all of the existing identifiers
as being out-of-date. Whenever we want to access information that may
come from an AST (e.g., whether the identifier has a macro definition,
or what top-level declarations have that name), we check the
out-of-date bit and, if it's set, ask the AST reader to update the
IdentifierInfo from the AST files. The update is a merge, and we now
take care to merge declarations before/after imports with declarations
from multiple imports.
The results of this optimization are fairly dramatic. On a small
application that brings in 14 non-trivial modules, this takes modules
from being > 3x slower than a "perfect" PCH file down to 30% slower
for a full rebuild. A partial rebuild (where the PCH file or modules
can be re-used) is down to 7% slower. Making the PCH file just a
little imperfect (e.g., adding two smallish modules used by a bunch of
.m files that aren't in the PCH file) tips the scales in favor of the
modules approach, with 24% faster partial rebuilds.
This is just a first step; the lazy scheme could possibly be improved
by adding versioning, so we don't search into modules we already
searched. Moreover, we'll need similar lazy schemes for all of the
other lookup data structures, such as DeclContexts.
llvm-svn: 143100
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 140367
|
| |
|
|
|
|
|
|
| |
that this flag must be used only for Microsoft extensions and not emulation; to avoid confusion with the new LangOptions::MicrosoftMode flag.
Many of the code now under LangOptions::MicrosoftExt will eventually be moved under the LangOptions::MicrosoftMode flag.
llvm-svn: 139987
|
| |
|
|
|
|
|
| |
#include or #import direcctives of framework headers into module
imports of the corresponding framework module.
llvm-svn: 139860
|
| |
|
|
|
|
|
|
| |
suppress it in system headers. And it is not a good idea to suppress it in system headers. (This was originally changed in r134996 to implement -MG.)
Fixes <rdar://10041960>. And also brings down the number of warnings without a flag by one :)
llvm-svn: 138842
|
| |
|
|
| |
llvm-svn: 136210
|
| |
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
| |
|
|
| |
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
|