| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 140407
|
|
|
|
| |
llvm-svn: 140367
|
|
|
|
|
|
| |
Use ASTTemplateArgumentListInfo instead.
llvm-svn: 140331
|
|
|
|
| |
llvm-svn: 140268
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 139644
|
|
|
|
| |
llvm-svn: 139600
|
|
|
|
|
|
|
|
|
| |
than having CodeGen check whether a declaration comes from an AST file
(which it shouldn't know or care about), make sure that the AST writer and
reader pass along "interesting" declarations that CodeGen needs to
know about.
llvm-svn: 139441
|
|
|
|
|
|
| |
whether a Decl was deserialized from an AST file (any AST file).
llvm-svn: 139438
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
indicates that a declaration is only visible within the module it is
declared in.
llvm-svn: 139348
|
|
|
|
|
|
|
| |
needed for implicit move constructors and move assignment
operators. Fixes PR10847.
llvm-svn: 139144
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
Remove
-setClassInterface
-setNextClassCategory
-insertNextClassCategory
and combine them in the Create function.
llvm-svn: 138817
|
|
|
|
|
|
|
|
|
|
| |
, 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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 137799
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
the C++0x 'constexpr' keyword.
llvm-svn: 137230
|
|
|
|
|
|
|
|
| |
IDs will never cross module boundaries, since they're tied to the
CXXDefinitionData, so just use a local mapping throughout. Eliminate
the global -> local tables and supporting data.
llvm-svn: 136847
|
|
|
|
|
|
| |
reader. Tested with the usual "gaps" method.
llvm-svn: 136839
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reader, to allow AST files to be loaded with their declarations
remapped to different ID numbers. Fix a number of places where we were
either failing to map local declaration IDs into global declaration
IDs or where interpreting the local declaration IDs within the wrong
module.
I've tested this via the usual "random gaps" method. It works well
except for the preamble tests, because our handling of the precompiled
preamble requires declaration and preprocessed entity to be stable
when parsing code and then loading that back into memory. This
property will hold in general, but my randomized testing naturally
breaks this property to get more coverage. In the future, I expect
that the precompiled preamble logic won't need this property.
I am very unhappy with the current handling of the translation unit,
which is a rather egregious hack. We're going to have to do something
very different here for loading multiple AST files, because we don't
want to have to cope with merging two translation units. Likely, we'll
just handle translation units entirely via "update" records, and
predefine a single, fixed declaration ID for the translation
unit. That will come later.
llvm-svn: 136779
|
|
|
|
|
|
|
|
|
| |
were (Module*, Offset) with equivalent maps whose value type is just a
Module*. The offsets have moved into corresponding "Base" fields
within the Module itself, where they will also be helpful for
local->global translation (eventually).
llvm-svn: 136441
|
|
|
|
|
|
| |
IDs properly, although the mapping itself is still trivial.
llvm-svn: 136391
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
|
|
|
| |
of ASTReader so it can become its own full-fledged class
(eventually). No functionality change.
llvm-svn: 135767
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so that we have one, simple way to map from global bit offsets to
local bit offsets. Eliminates a number of loops over the chain, and
generalizes for more interesting bit remappings.
Also, as an amusing oddity, we were computing global bit offsets
*backwards* for preprocessed entities (e.g., the directly included PCH
file in the chain would start at offset zero, rather than the original
PCH that occurs first in translation unit). Even more amusingly, it
made precompiled preambles work, because we were forgetting to adjust
the local bit offset to a global bit offset when storing preprocessed
entity offsets in the ASTUnit. Two wrongs made a right, and now
they're both right.
llvm-svn: 135750
|
|
|
|
|
|
|
|
| |
type IDs into a single place, and make sure that all of the callers
use the appropriate functions to do the mapping. Since the mapping is
still the identity function, this is essentially a no-op.
llvm-svn: 135733
|
|
|
|
|
|
| |
within the ASTReader (I hope).
llvm-svn: 135720
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
such that every declaration ID loaded from an AST file will go through
a central local -> global mapping function. At present, this change
does nothing, since the local -> global mapping function is the
identity function.
This is the mechanical part of the refactoring; a follow-up patch will
address a few remaining areas where it's not obvious whether we're
dealing with local or global IDs.
llvm-svn: 135711
|
|
|
|
|
|
|
|
| |
AST reader down to the AST file + local ID within that file, rather
than lamely walking the PCH chain. There's no actual functionality
change now, but this is cleaner and more general.
llvm-svn: 135548
|
|
|
|
|
|
|
|
|
|
|
|
| |
they should still be officially __strong for the purposes of errors,
block capture, etc. Make a new bit on variables, isARCPseudoStrong(),
and set this for 'self' and these enumeration-loop variables. Change
the code that was looking for the old patterns to look for this bit,
and change IR generation to find this bit and treat the resulting
variable as __unsafe_unretained for the purposes of init/destroy in
the two places it can come up.
llvm-svn: 133243
|
|
|
|
| |
llvm-svn: 132878
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Related result types apply Cocoa conventions to the type of message
sends and property accesses to Objective-C methods that are known to
always return objects whose type is the same as the type of the
receiving class (or a subclass thereof), such as +alloc and
-init. This tightens up static type safety for Objective-C, so that we
now diagnose mistakes like this:
t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
with an
expression of type 'NSArray *' [-Wincompatible-pointer-types]
NSSet *array = [[NSArray alloc] init];
^ ~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
note:
instance method 'init' is assumed to return an instance of its
receiver
type ('NSArray *')
- (id)init;
^
It also means that we get decent type inference when writing code in
Objective-C++0x:
auto array = [[NSMutableArray alloc] initWithObjects:@"one", @"two",nil];
// ^ now infers NSMutableArray* rather than id
llvm-svn: 132868
|
|
|
|
|
|
| |
ObjCIvarDecl, TypedefDecl, VarDecl and FieldDecl and improve support for ParmVarDecl.
llvm-svn: 132604
|
|
|
|
|
|
|
| |
constant, also consider whether it's a class type that has any mutable
fields. If so, it can't be a global constant.
llvm-svn: 131276
|
|
|
|
| |
llvm-svn: 131260
|
|
|
|
|
|
|
|
| |
Yes, I'm aware that the diagnostics are awful.
Tests to follow.
llvm-svn: 131203
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hasTrivialDefaultConstructor() really really means it now.
Also implement a fun standards bug regarding aggregates. Doug, if you'd
like, I can un-implement that bug if you think it is truly a defect.
The bug is that non-special-member constructors are never considered
user-provided, so the following is an aggregate:
struct foo {
foo(int);
};
It's kind of bad, but the solution isn't obvious - should
struct foo {
foo (int) = delete;
};
be an aggregate or not?
Lastly, add a missing initialization to FunctionDecl.
llvm-svn: 131101
|
|
|
|
|
|
|
| |
modify the semantics slightly to accomodate default constructors (I
hope).
llvm-svn: 131087
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- New isDefined() function checks for deletedness
- isThisDeclarationADefinition checks for deletedness
- New doesThisDeclarationHaveABody() does what
isThisDeclarationADefinition() used to do
- The IsDeleted bit is not propagated across redeclarations
- isDeleted() now checks the canoncial declaration
- New isDeletedAsWritten() does what it says on the tin.
- isUserProvided() now correct (thanks Richard!)
This fixes the bug that we weren't catching
void foo() = delete;
void foo() {}
as being a redefinition.
llvm-svn: 131013
|
|
|
|
| |
llvm-svn: 130953
|
|
|
|
|
|
|
| |
scope depth overlaps with the ObjCDeclQualifier, dropping
memory usage back to previous levels.
llvm-svn: 130671
|
|
|
|
|
|
|
|
|
|
| |
parameter node and use this to correctly mangle parameter
references in function template signatures.
A follow-up patch will improve the storage usage of these
fields; here I've just done the lazy thing.
llvm-svn: 130669
|
|
|
|
|
|
|
| |
devirtualize Decl (because bits can't get laid out in base
classes if the base is POD).
llvm-svn: 130632
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
accompanying fixes to make it work today.
The core of this patch is to provide a link from a TemplateTypeParmType
back to the TemplateTypeParmDecl node which declared it. This in turn
provides much more precise information about the type, where it came
from, and how it functions for AST consumers.
To make the patch work almost a year after its first attempt, it needed
serialization support, and it now retains the old getName() interface.
Finally, it requires us to not attempt to instantiate the type in an
unsupported friend decl -- specifically those coming from template
friend decls but which refer to a specific type through a dependent
name.
A cleaner representation of the last item would be to build
FriendTemplateDecl nodes for these, storing their template parameters
etc, and to perform proper instantation of them like any other template
declaration. They can still be flagged as unsupported for the purpose of
access checking, etc.
This passed an asserts-enabled bootstrap for me, and the reduced test
case mentioned in the original review thread no longer causes issues,
likely fixed at somewhere amidst the 24k revisions that have elapsed.
llvm-svn: 130628
|