don't call ReadSLocEntryRecord() directly because the entry may have
already been loaded in which case calling ReadSLocEntryRecord()
directly would trigger an assertion in SourceManager.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140052 91177308-0d34-0410-b5e6-96231b3b80d8
-Use an array of offsets for all preprocessed entities
-Get rid of the separate array of offsets for just macro definitions;
for references to macro definitions use an index inside the preprocessed
entities array.
-Deserialize each preprocessed entity lazily, at first request; not in bulk.
Paves the way for binary searching of preprocessed entities that will offer
efficiency and will simplify things on the libclang side a lot.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139809 91177308-0d34-0410-b5e6-96231b3b80d8
to the consumer without being fully deserialized).
The regression was on compiling boost.python and it was too difficult to get a reduced
test case unfortunately.
Also modify the logic of how objc methods are getting passed to the consumer;
codegen depended on receiving objc methods before the implementation decl.
Since the interesting objc methods are ones with a body and such methods only
exist inside an ObjCImplDecl, deserialize and pass to consumer all the methods
of ObCImplDecl when we see one.
Fixes http://llvm.org/PR10922 & rdar://10117105.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139644 91177308-0d34-0410-b5e6-96231b3b80d8
language options. Use that .def file to declare the LangOptions class
and initialize all of its members, eliminating a source of annoying
initialization bugs.
AST serialization changes are next up.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139605 91177308-0d34-0410-b5e6-96231b3b80d8
modifying directly for the preamble.
This avoids an awful, hard to find, bug where "PreprocessorOpts.DisablePCHValidation = true"
would be persistent for subsequent reparses of the translation unit which would result
in defines, present in command-line but not in the PCH, being ignored.
Fixes rdar://9615399.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139512 91177308-0d34-0410-b5e6-96231b3b80d8
Preprocessor reference. Simplify some code along the way, so there is
no separate "initialize the preprocessor" step.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139418 91177308-0d34-0410-b5e6-96231b3b80d8
ASTContext reference. Remove all of the extra checking and logic that
was used to cope with a NULL ASTContext. No effective functionality
change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139413 91177308-0d34-0410-b5e6-96231b3b80d8
identifier, also make them visible in the translation unit," which
isn't needed now that John's eliminated the AST dependency in blocks
CodeGen.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139408 91177308-0d34-0410-b5e6-96231b3b80d8
'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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@139275 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138986 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138943 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138926 91177308-0d34-0410-b5e6-96231b3b80d8
to "when loading a particular module" validation, since it was only
validating local information anyway. This shouldn't change anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138583 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138556 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138496 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138490 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138463 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138225 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138189 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138187 91177308-0d34-0410-b5e6-96231b3b80d8
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 "-".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138030 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137971 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137925 91177308-0d34-0410-b5e6-96231b3b80d8
-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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137923 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137869 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137429 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137395 91177308-0d34-0410-b5e6-96231b3b80d8
No test case, sorry. It's one of those bugs where it's really really hard to make one. rdar://9910862.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137383 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@137373 91177308-0d34-0410-b5e6-96231b3b80d8
Argyrios Kyrtzidis
Douglas Gregor
Jordy Rose
Benjamin Kramer
Chad Rosier