| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
indicates that a declaration is only visible within the module it is
declared in.
llvm-svn: 139348
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
needed for implicit move constructors and move assignment
operators. Fixes PR10847.
llvm-svn: 139144
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
builtin types (When requested). This is another step toward making
ASTUnit build the ASTContext as needed when loading an AST file,
rather than doing so after the fact. No actual functionality change (yet).
llvm-svn: 138985
|
| |
|
|
|
|
| |
in the face of buffering C++/ObjC method bodies.
llvm-svn: 138972
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 138936
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 138855
|
| |
|
|
|
|
|
|
| |
sure that all of the CXXConversionDecls go into the same
bucket. Otherwise, name lookup might not find them all. Fixes
<rdar://problem/10041960>.
llvm-svn: 138824
|
| |
|
|
|
|
|
|
|
|
|
| |
Remove
-setClassInterface
-setNextClassCategory
-insertNextClassCategory
and combine them in the Create function.
llvm-svn: 138817
|
| |
|
|
|
|
|
| |
Empty lookups can occur in the DeclContext map when we are chaining PCHs, where
the empty lookup indicates that we already looked in ExternalASTSource.
llvm-svn: 138816
|
| |
|
|
|
|
| |
option is ObjCInferRelatedResultType.
llvm-svn: 138793
|
| |
|
|
|
|
|
|
|
|
| |
, such as list of forward @class decls, in a DeclGroup
node. Deal with its consequence throught clang. This
is in preparation for more Sema work ahead. // rdar://8843851.
Feel free to reverse if it breaks something important
and I am unavailable.
llvm-svn: 138709
|
| |
|
|
| |
llvm-svn: 138707
|
| |
|
|
|
|
| |
are lexically within a particular DeclContext. Test forthcoming.
llvm-svn: 138668
|
| |
|
|
| |
llvm-svn: 138596
|
| |
|
|
|
|
|
|
|
| |
from the given source. -emit-module behaves similarly to -emit-pch,
except that Sema is somewhat more strict about the contents of
-emit-module. In the future, there are likely to be more interesting
differences.
llvm-svn: 138595
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
redeclarations of a particular entity would occur in source
order. Friend declarations that occur within class templates (or
member classes thereof) do not follow this, nor would modules. Big
thanks to Erik Verbruggen for reducing this problem from the Very
Large Qt preamble testcase he found.
llvm-svn: 138557
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Caught by the static analyzer!
llvm-svn: 137878
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 137799
|
| |
|
|
|
|
| |
a macro arg expansion or not.
llvm-svn: 137792
|
| |
|
|
| |
llvm-svn: 137653
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Microsoft mode. A new AST node is introduced: ClassScopeFunctionSpecialization. This node holds a FunctionDecl that is not yet specialized; then during the class template instantiation the ClassScopeFunctionSpecialization will spawn the actual function specialization.
Example:
template <class T>
class A {
public:
template <class U> void f(U p) { }
template <> void f(int p) { } // <== class scope specialization
};
This extension is necessary to parse MSVC standard C++ headers, MFC and ATL code.
BTW, with this feature in, clang can parse (-fsyntax-only) all the MSVC 2010 standard header files without any error.
llvm-svn: 137573
|
| |
|
|
|
|
|
| |
in the AST format, which are built lazily by the ASTContext when
requested.
llvm-svn: 137437
|