| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
well-bred compiler like Clang.
llvm-svn: 139442
|
|
|
|
|
|
|
| |
Preprocessor reference. Simplify some code along the way, so there is
no separate "initialize the preprocessor" step.
llvm-svn: 139418
|
|
|
|
|
|
|
|
| |
ASTContext reference. Remove all of the extra checking and logic that
was used to cope with a NULL ASTContext. No effective functionality
change.
llvm-svn: 139413
|
|
|
|
|
|
| |
actually have data for that lexical or visible storage
llvm-svn: 139409
|
|
|
|
|
|
|
|
| |
identifier, also make them visible in the translation unit," which
isn't needed now that John's eliminated the AST dependency in blocks
CodeGen.
llvm-svn: 139408
|
|
|
|
|
|
| |
in the translation unit.
llvm-svn: 139358
|
|
|
|
|
|
| |
for a builtin macro expansion.
llvm-svn: 139298
|
|
|
|
|
|
|
|
|
|
| |
'id' that can be used (only!) via a contextual keyword as the result
type of an Objective-C message send. 'instancetype' then gives the
method a related result type, which we have already been inferring for
a variety of methods (new, alloc, init, self, retain). Addresses
<rdar://problem/9267640>.
llvm-svn: 139275
|
|
|
|
|
|
|
|
|
| |
Preprocessor, eliminating the constructor that was used by ASTUnit
(which didn't provide an ASTContext or Prepreprocessor). Ensuring that
both objects are non-NULL will simplify module loading (but none of
that is done yet).
llvm-svn: 138986
|
|
|
|
|
|
|
|
|
|
|
| |
include guards don't show up as macro definitions in every translation
unit that imports a module. Macro definitions can, however, be
exported with the intentionally-ugly #__export_macro__
directive. Implement this feature by not even bothering to serialize
non-exported macros to a module, because clients of that module need
not (should not) know that these macros even exist.
llvm-svn: 138943
|
|
|
|
|
|
|
|
|
|
|
|
| |
The initial incentive was to fix a crash when PCH chaining categories
to an interface, but the fix was done in the "modules way" that I hear
is popular with the kids these days.
Each module stores the local chain of categories and we combine them
when the interface is loaded. We also warn if non-dependent modules
introduce duplicate named categories.
llvm-svn: 138926
|
|
|
|
|
|
| |
option is ObjCInferRelatedResultType.
llvm-svn: 138793
|
|
|
|
| |
llvm-svn: 138707
|
|
|
|
|
|
| |
are lexically within a particular DeclContext. Test forthcoming.
llvm-svn: 138668
|
|
|
|
|
|
|
| |
a top-level module. This code is still horrible and should go away,
but we're not there yet.
llvm-svn: 138586
|
|
|
|
|
|
|
| |
AST file, rather than waiting until we finish loading the top-level
AST file.
llvm-svn: 138585
|
|
|
|
|
|
|
| |
to "when loading a particular module" validation, since it was only
validating local information anyway. This shouldn't change anything.
llvm-svn: 138583
|
|
|
|
|
|
|
| |
and .cpp files, since ASTReader.cpp was getting way too large. No
functionality change.
llvm-svn: 138582
|
|
|
|
|
|
| |
chain to a proper search.
llvm-svn: 138574
|
|
|
|
|
|
| |
search in ASTReader::ReadPreprocessedEntities().
llvm-svn: 138572
|
|
|
|
|
|
|
|
|
| |
given selector, rather than walking the chain backwards. Teach its
visitor how to merge multiple result sets into a single result set,
combining the results of selector lookup in several different modules
into a single result set.
llvm-svn: 138556
|
|
|
|
|
|
|
|
|
|
| |
table when serializing an AST file. This was a holdover from the days
before chained PCH, and is a complete waste of time and storage
now. It's a good thing it's useless, because I have no idea how I
would have implemented MaterializeVisibleDecls efficiently in the
presence of modules.
llvm-svn: 138496
|
|
|
|
|
|
|
|
|
|
|
|
| |
which supports both pre-order and post-order traversal via a visitor
mechanism. Use this depth-first search with a post-order traversal to
give predictable ordering semantics when walking all of the lexical
declarations in the translation unit.
Eventually, module imports will occur in the source code rather than
at the beginning, and we'll have to revisit this walk.
llvm-svn: 138490
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
module DAG-based lookup scheme. This required some reshuffling, so
that each module stores its own mapping from DeclContexts to their
lexical and visible sets for those DeclContexts (rather than one big
"chain").
Overall, this allows simple qualified name lookup into the translation
unit to gather results from multiple modules, with the lookup results
in module B shadowing the lookup results in module A when B imports A.
Walking all of the lexical declarations in a module DAG is still a
mess; we'll end up walking the loaded module list backwards, which
works fine for chained PCH but doesn't make sense in a DAG. I'll
tackle this issue as a separate commit.
llvm-svn: 138463
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
different modules) more robust. It already handled (simple) merges of
the set of declarations attached to that identifier, so add a test
case that shows us getting two different declarations for the same
identifier (one struct, one function) from different modules, and are
able to use both of them.
llvm-svn: 138189
|
|
|
|
| |
llvm-svn: 138188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
modules (those that no other module depends on) and performs a search
over all of the modules, visiting a new module only when all of the
modules that depend on it have already been visited. The visitor can
abort the search for all modules that a module depends on, which
allows us to minimize the number of lookups necessary when performing
a search.
Switch identifier lookup from a linear walk over the set of modules to
this module visitation operation. The behavior is the same for simple
PCH and chained PCH, but provides the proper search order for
modules. Verified with printf debugging, since we don't have enough in
place to actually test this.
llvm-svn: 138187
|
|
|
|
| |
llvm-svn: 138079
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
has already been loaded before allocating a new Module structure. If
the module has already been loaded (uniquing based on file name), then
just return the existing module rather than trying to load it again.
This allows us to load a DAG of modules. Introduce a simple test case
that forms a diamond-shaped module graph, and illustrates that a
source file importing the bottom of the diamond can see declarations
in all four of the modules that make up the diamond.
Note that this version moves the file-opening logic into the module
manager, rather than splitting it between the module manager and the
AST reader. More importantly, it properly handles the
weird-but-possibly-useful case of loading an AST file from "-".
llvm-svn: 138030
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Teach ModuleManager::addModule() to check whether a particular module
has already been loaded before allocating a new Module structure. If
the module has already been loaded (uniquing based on file name), then
just return the existing module rather than trying to load it again.
This allows us to load a DAG of modules. Introduce a simple test case
that forms a diamond-shaped module graph, and illustrates that a
source file importing the bottom of the diamond can see declarations
in all four of the modules that make up the diamond.
llvm-svn: 137971
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
has already been loaded before allocating a new Module structure. If
the module has already been loaded (uniquing based on file name), then
just return the existing module rather than trying to load it again.
This allows us to load a DAG of modules. Introduce a simple test case
that forms a diamond-shaped module graph, and illustrates that a
source file importing the bottom of the diamond can see declarations
in all four of the modules that make up the diamond.
llvm-svn: 137925
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-import-module) vs. loaded because some other module depends on
them. As part of doing this, pass down the module that caused a module
to be loaded directly, rather than assuming that we're loading a
chain. Finally, write out all of the directly-loaded modules when
serializing an AST file (using the new IMPORTS record), so that an AST
file can depend on more than one other AST file, all of which will be
loaded when that AST file is loaded. This allows us to form and load a
tree of modules, but we can't yet load a DAG of modules.
llvm-svn: 137923
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
all AST files have a normal METADATA record that has the same form
regardless of whether we refer to a chained PCH or any other kind of
AST file.
Introduce the IMPORTS record, which describes all of the AST files
that are imported by this AST file, and how (as a module, a PCH file,
etc.). Currently, we emit at most one entry to this record, to support
chained PCH.
llvm-svn: 137869
|
|
|
|
|
|
|
| |
in the AST format, which are built lazily by the ASTContext when
requested.
llvm-svn: 137437
|
|
|
|
|
|
|
| |
AST file format, lazily generating the actual declaration in
ASTContext as needed.
llvm-svn: 137434
|
|
|
|
|
|
|
| |
AST file format, lazily generating the actual declaration in
ASTContext as needed.
llvm-svn: 137431
|
|
|
|
|
|
|
|
|
| |
type over into the AST context, then make that declaration a
predefined declaration in the AST format. This ensures that different
AST files will at least agree on the (global) declaration ID for 'id',
and eliminates one of the "special" types in the AST file format.
llvm-svn: 137429
|
|
|
|
|
|
|
|
|
|
| |
declaration that never actually gets serialized. Instead, serialize
the various kinds of update records (lexical decls, visible decls, the
addition of an anonymous namespace) for the translation unit, even if
we're not chaining. This way, we won't have to deal with multiple
loaded translation unit declarations.
llvm-svn: 137395
|
|
|
|
|
|
|
|
| |
map was getting modified.
No test case, sorry. It's one of those bugs where it's really really hard to make one. rdar://9910862.
llvm-svn: 137383
|
|
|
|
|
|
|
|
| |
either "special" type has already been initialized. Previously, we did
this check based on just the first special type (__builtin_va_list),
but now we have some NULL special type entries to content with.
llvm-svn: 137373
|
|
|
|
|
|
| |
Objective-C types
llvm-svn: 137366
|
|
|
|
|
|
|
|
| |
enumerations from the ASTContext into CodeGen, so that we don't need
to serialize it to AST files. This appears to be the last of the
low-hanging fruit for SpecialTypes.
llvm-svn: 137124
|
|
|
|
|
|
|
| |
types to AST files; they're only used by debug info generation anyway,
and shouldn't ever exist in the AST anyway.
llvm-svn: 137122
|
|
|
|
|
|
|
|
| |
layout of a constant NSString from the ASTContext over to CodeGen,
since this is solely CodeGen's responsibility. Eliminates one of the
unnecessary "special" types that we serialize.
llvm-svn: 137121
|
|
|
|
|
|
|
| |
AutoRRefDeductTy from the "special types" block to predefined
types. The latter behaves better when loading multiple AST files.
llvm-svn: 137120
|
|
|
|
|
|
| |
ReadAST multiple times does not immediately throw an error.
llvm-svn: 136995
|
|
|
|
|
|
|
| |
clearly called out, and add the missing local -> global selector map
output.
llvm-svn: 136903
|
|
|
|
|
|
|
|
|
| |
the last of the ID/offset/index mappings that I know
of. Unfortunately, the "gap" method of testing doesn't work here due
to the way the preprocessing record performs iteration. We'll do more
testing once multi-AST loading is possible.
llvm-svn: 136902
|
|
|
|
|
|
| |
ASTReader::ReadMacroRecord(). No functionality change.
llvm-svn: 136893
|