| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
top-level module name to a module path (e.g., std.vector). We're still
missing a number of pieces for this actually to do something.
llvm-svn: 145462
|
|
|
|
| |
llvm-svn: 145108
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
C++98 mode. Only the first occurrence of each keyword will produce a warning.
llvm-svn: 141700
|
|
|
|
| |
llvm-svn: 141012
|
|
|
|
|
|
| |
variable.
llvm-svn: 140514
|
|
|
|
| |
llvm-svn: 140478
|
|
|
|
|
|
|
|
|
|
| |
which will do a binary search and return a pair of iterators
for preprocessed entities in the given source range.
Source ranges of preprocessed entities are stored twice currently in
the PCH/Module file but this will be fixed in a subsequent commit.
llvm-svn: 140058
|
|
|
|
|
|
|
| |
#include or #import direcctives of framework headers into module
imports of the corresponding framework module.
llvm-svn: 139860
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 139104
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
and language-specific initialization. Use this to allow ASTUnit to
create a preprocessor object *before* loading the AST file. No actual
functionality change.
llvm-svn: 138983
|
|
|
|
|
|
|
|
|
| |
LangOptions, rather than making distinct copies of
LangOptions. Granted, LangOptions doesn't actually get modified, but
this will eventually make it easier to construct ASTContext and
Preprocessor before we know all of the LangOptions.
llvm-svn: 138959
|
|
|
|
|
|
| |
on Windows.
llvm-svn: 138880
|
|
|
|
|
|
|
|
| |
existing practice with Python extension modules. Not that Python
extension modules should be using a double-underscored identifier
anyway, but...
llvm-svn: 138870
|
|
|
|
|
|
|
|
|
| |
__import__ within the preprocessor, since the prior one foolishly
assumed that Preprocessor::Lex() was re-entrant. We now handle
__import__ at the top level (only), after macro expansion. This should
fix the buildbot failures.
llvm-svn: 138704
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loads the named module. The syntax itself is intentionally hideous and
will be replaced at some later point with something more
palatable. For now, we're focusing on the semantics:
- Module imports are handled first by the preprocessor (to get macro
definitions) and then the same tokens are also handled by the parser
(to get declarations). If both happen (as in normal compilation),
the second one is redundant, because we currently have no way to
hide macros or declarations when loading a module. Chris gets credit
for this mad-but-workable scheme.
- The Preprocessor now holds on to a reference to a module loader,
which is responsible for loading named modules. CompilerInstance is
the only important module loader: it now knows how to create and
wire up an AST reader on demand to actually perform the module load.
- We search for modules in the include path, using the module name
with the suffix ".pcm" (precompiled module) for the file name. This
is a temporary hack; we hope to improve the situation in the
future.
llvm-svn: 138679
|
|
|
|
| |
llvm-svn: 136239
|
|
|
|
|
|
|
|
|
|
| |
PreprocessingRecord::getTotalMemory().
Most of the memory was already reported; but now we report more memory from side data structures.
Fixes <rdar://problem/9379717>.
llvm-svn: 136150
|
|
|
|
| |
llvm-svn: 136054
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variants to 'expand'. This changed a couple of public APIs, including
one public type "MacroInstantiation" which is now "MacroExpansion". The
rest of the codebase was updated to reflect this, especially the
libclang code. Two of the C++ (and thus easily changed) libclang APIs
were updated as well because they pertained directly to the old
MacroInstantiation class.
No functionality changed.
llvm-svn: 135139
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
functionality change.
llvm-svn: 134103
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CXTranslationUnit_NestedMacroInstantiations, which indicates whether
we want to see "nested" macro instantiations (e.g., those that occur
inside other macro instantiations) within the detailed preprocessing
record. Many clients (e.g., those that only care about visible tokens)
don't care about this information, and in code that uses preprocessor
metaprogramming, this information can have a very high cost.
Addresses <rdar://problem/9389320>.
llvm-svn: 130990
|
|
|
|
|
|
|
|
| |
Patch authored by Sohail Somani.
Provide parsing and AST support for Windows structured exception handling.
llvm-svn: 130366
|
|
|
|
|
|
|
| |
in case we want to make a world where we can check intermediate instantiations
for this kind of breadcrumb.
llvm-svn: 127221
|
|
|
|
|
|
| |
SourceLocation.
llvm-svn: 127216
|
|
|
|
| |
llvm-svn: 122394
|
|
|
|
|
|
|
|
|
| |
FileSystemOpts through a ton of apis, simplifying a lot of code.
This also fixes a latent bug in ASTUnit where it would invoke
methods on FileManager without creating one in some code paths
in cindextext.
llvm-svn: 120010
|
|
|
|
|
|
| |
related to.
llvm-svn: 119479
|
|
|
|
|
|
| |
Preprocessor to Lexer where they make more sense.
llvm-svn: 119474
|
|
|
|
| |
llvm-svn: 119472
|
|
|
|
| |
llvm-svn: 119469
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When -working-directory is passed in command line, file paths are resolved relative to the specified directory.
This helps both when using libclang (where we can't require the user to actually change the working directory)
and to help reproduce test cases when the reproduction work comes along.
--FileSystemOptions is introduced which controls how file system operations are performed (currently it just contains
the working directory value if set).
--FileSystemOptions are passed around to various interfaces that perform file operations.
--Opening & reading the content of files should be done only through FileManager. This is useful in general since
file operations will be abstracted in the future for the reproduction mechanism.
FileSystemOptions is independent of FileManager so that we can have multiple translation units sharing the same
FileManager but with different FileSystemOptions.
Addresses rdar://8583824.
llvm-svn: 118203
|
|
|
|
|
|
|
|
|
| |
Now MICache is a linked list (per the FIXME), where we tradeoff between MacroInfo objects being in MICache
and MIChainHead. MacroInfo objects in the MICache chain are already "Destroy()'ed", so they can be reused. When
inserting into MICache, we need to remove them from the regular linked list so that they aren't destroyed more than
once.
llvm-svn: 116869
|
|
|
|
| |
llvm-svn: 116861
|
|
|
|
|
|
|
|
|
|
|
|
| |
the Preprocessor maintain them in a linked
list of allocated MacroInfos. This requires only 1 extra pointer per MacroInfo object, and allows us to blow them
away in one place. This fixes an elusive memory leak with MacroInfos (whose exact location I couldn't still figure
out despite substantial digging).
Fixes <rdar://problem/8361834>.
llvm-svn: 116842
|
|
|
|
|
|
|
|
| |
"#pragma push_macro" uses. This
fixes a potential memory leak.
llvm-svn: 116826
|
|
|
|
|
|
| |
c++ operator token. (radar 8328250).
llvm-svn: 112977
|
|
|
|
|
|
|
| |
operators (and, or, etc.) to be used as selectors
to match g++'s behavior.
llvm-svn: 112935
|
|
|
|
|
|
| |
some issues being sorted out.
llvm-svn: 112493
|
|
|
|
|
|
|
|
|
|
| |
The extra data stored on user-defined literal Tokens is stored in extra
allocated memory, which is managed by the PreprocessorLexer because there isn't
a better place to put it that makes sure it gets deallocated, but only after
it's used up. My testing has shown no significant slowdown as a result, but
independent testing would be appreciated.
llvm-svn: 112458
|
|
|
|
| |
llvm-svn: 112182
|
|
|
|
|
|
|
| |
expect "natural" language and should not provide any completions,
e.g., comments, string literals, #error.
llvm-svn: 112054
|
|
|
|
|
|
| |
e.g., after a "#" we'll suggest #if, #ifdef, etc.
llvm-svn: 111943
|
|
|
|
| |
llvm-svn: 111364
|
|
|
|
| |
llvm-svn: 110807
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|