| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
of their own (or are syntheszed), use prperty's comment.
for them. // rdar://12791315
llvm-svn: 172278
|
|
|
|
|
|
| |
related to // rdar://12958878
llvm-svn: 171792
|
|
|
|
|
|
|
| |
list of classes, etc., make sure to look into protocol
definitions. // rdar://12958878
llvm-svn: 171777
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
per review discussion in r170365
This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).
Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)
llvm-svn: 170482
|
|
|
|
|
|
|
|
|
| |
pull in all the generated Attr code.
Required to pull some functions out of line, but this shouldn't have a perf impact.
No functionality change.
llvm-svn: 169092
|
|
|
|
| |
llvm-svn: 167091
|
|
|
|
|
|
| |
This would make it possible for the analyzer to use the function.
llvm-svn: 166210
|
|
|
|
|
|
|
|
|
| |
Currently, Objective-C does not support class properties, even though it
allows calling class methods with dot syntax.
No intended functionality change; purely optimization.
llvm-svn: 165716
|
|
|
|
|
|
|
|
|
|
| |
methods looking for documentation on a particular base
class inherited by any method that overrides the base class.
In case of redeclaration, as when objc method is defined
in the implementation, it also looks up for documentation
in class/class extension being redeclared.
llvm-svn: 165643
|
|
|
|
|
|
|
|
| |
Then, switch users of PropertyIfSetterOrGetter and LookupPropertyDecl
(the latter by name) over to findPropertyDecl. This actually makes
-Wreceiver-is-weak a bit stronger than it was before.
llvm-svn: 165628
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This more accurately reflects its use: this flag is set when a method
matches the getter or setter name for a property in the same class,
and does not actually specify whether or not the definition of the method
will be synthesized (either implicitly or explicitly with @synthesize).
This renames the setter and backing field as well, and changes the
(soon-to-be-obsolete?) XML dump format to use 'property_accessor'
instead of 'synthesized'.
llvm-svn: 165626
|
|
|
|
|
|
|
|
| |
ASTContext to the ObjCMethodDecl, and have the more generic
ASTContext::getOverriddenMethods() use the ObjCMethodDecl::getOverriddenMethods()
function.
llvm-svn: 165518
|
|
|
|
|
|
|
|
|
|
| |
whether that function/method already has a body (loaded from some
other AST file), as introduced in r165137. Delay this check until
after the redeclaration chains have been wired up.
While I'm here, make the loading of method bodies lazy.
llvm-svn: 165513
|
|
|
|
| |
llvm-svn: 164789
|
|
|
|
| |
llvm-svn: 160989
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, fix a subtle bug, which occurred due to lookupPrivateMethod
defined in DeclObjC.h not looking up the method inside parent's
categories.
Note, the code assumes that Class's parent object has the same methods
as what's in the Root class of a the hierarchy, which is a heuristic
that might not hold for hierarchies which do not descend from NSObject.
Would be great to fix this in the future.
llvm-svn: 160885
|
|
|
|
|
|
|
|
| |
previous ResetObjCLayout calls since this is now handled in Sema.
Part of rdar://11842763
llvm-svn: 160527
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
method definition that has its '{' attached to the method name without
a space.
With a method like:
-(id)meth{
.....
}
the logic in ObjCMethodDecl that determined the selector locations got
confused because it was initialized based on an end location for '{' but
that end location changed to '}' after the method was finished.
Fix this by having an immutable end location for the declarator and
for getLocEnd() get the end location from the body itself.
Fixes rdar://11659739.
llvm-svn: 158583
|
|
|
|
| |
llvm-svn: 158565
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
value_type
In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I would've omitted them entirely but
std::distance likes them to be there even if it doesn't use them.
This rolls back r155808 and r155869.
Review by Doug Gregor incorporating feedback from Chandler Carruth.
llvm-svn: 158104
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
filter_decl_iterator had a weird mismatch where both op* and op-> returned T*
making it difficult to generalize this filtering behavior into a reusable
library of any kind.
This change errs on the side of value, making op-> return T* and op* return
T&.
(reviewed by Richard Smith)
llvm-svn: 155808
|
|
|
|
|
|
|
| |
declared in its adopted protocol when another category declares it
because that category will implement it. // rdar://11186449
llvm-svn: 154132
|
|
|
|
|
|
|
|
|
| |
iterators instead of
ObjCInterfaceDecl::getReferencedProtocols(), because the iterators are safe to use
even if the caller did not check that the interface is a definition.
llvm-svn: 152597
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
|
|
|
|
|
|
| |
@class I;
@implementation I(cat) // crashes here
@end
rdar://10968158
llvm-svn: 151931
|
|
|
|
|
|
|
| |
have matching user defined setter/getter and a warning is issued.
In this case, a fixit note is displayed. // rdar://10267155
llvm-svn: 151766
|
|
|
|
|
|
|
| |
modern meta-data translation by commenting out private ivar
declarations in user source. Also, added several tests.
llvm-svn: 150985
|
|
|
|
|
|
|
|
| |
has been declared in its primary class, superclass,
or in one of their protocols, no need to issue unimplemented method.
// rdar://10823023
llvm-svn: 150206
|
|
|
|
|
|
| |
consistency with NamedDecls.
llvm-svn: 149981
|
|
|
|
|
|
|
| |
moving it from a "special type" to a predefined declaration, as we do
for id, Class, and SEL.
llvm-svn: 148313
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
protocol, record the definition pointer in the canonical declaration
for that entity, and then propagate that definition pointer from the
canonical declaration to all other deserialized declarations. This
approach works well even when deserializing declarations that didn't
know about the original definition, which can occur with modules.
A nice bonus from this definition-deserialization approach is that we
no longer need update records when a definition is added, because the
redeclaration chains ensure that the if any declaration is loaded, the
definition will also get loaded.
llvm-svn: 148223
|
|
|
|
|
|
|
| |
go through a central allocation routine
Decl::AllocateDeserializedDecl(). No actual functionality change (yet).
llvm-svn: 147614
|
|
|
|
|
|
| |
They are no longer needed
llvm-svn: 147419
|
|
|
|
|
|
| |
ObjCProtocolDecl modules forward declarations properly.
llvm-svn: 147415
|
|
|
|
|
|
|
| |
forward declarations and definitions of an Objective-C protocol are
represented within a single chain of ObjCProtocolDecls.
llvm-svn: 147412
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for Objective-C protocols, including:
- Using the first declaration as the canonical declaration
- Using the definition as the primary DeclContext
- Making sure that all declarations have a pointer to the definition
data, and that we know which declaration is the definition
- Serialization support for redeclaration chains and for adding
definitions to already-serialized declarations.
However, note that we're not taking advantage of much of this code
yet, because we're still re-using ObjCProtocolDecls.
llvm-svn: 147410
|
|
|
|
|
|
|
|
|
| |
separately-allocated DefinitionData structure. Introduce various
functions that will help with the separation of declarations from
definitions (isThisDeclarationADefinition(), hasDefinition(),
getDefinition()).
llvm-svn: 147408
|
|
|
|
|
|
|
| |
covers both declarations (@class) and definitions (@interface) of an
Objective-C class.
llvm-svn: 147299
|
|
|
|
|
|
|
| |
building related objc ASTs which require a class definition AST.
These were uncovered when testing objc rewriter.
llvm-svn: 147210
|
|
|
|
|
|
| |
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
llvm-svn: 146959
|
|
|
|
| |
llvm-svn: 146763
|
|
|
|
|
|
| |
from the corresponding ObjCInterfaceType
llvm-svn: 146740
|
|
|
|
| |
llvm-svn: 146722
|
|
|
|
|
|
|
|
|
|
| |
declarations and definitions) as ObjCInterfaceDecls within the same
redeclaration chain. This new representation matches what we do for
C/C++ variables/functions/classes/templates/etc., and makes it
possible to answer the query "where are all of the declarations of
this class?"
llvm-svn: 146679
|
|
|
|
|
|
|
| |
definition, and implement ObjCInterfaceDecl::getDefinition()
efficiently based on that.
llvm-svn: 146669
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
redeclaration chain for Objective-C classes, including:
- Using the first declaration as the canonical declaration.
- Using the definition as the primary DeclContext
- Making sure that all declarations have a pointer to the definition
data, and the definition knows that it is the definition.
- Serialization support for when a definition gets added to a
declaration that comes from an AST file.
However, note that we're not taking advantage of much of this code
yet, because we're still re-using ObjCInterfaceDecls.
llvm-svn: 146667
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
separately-allocated DefinitionData structure, which we manage the
same way as CXXRecordDecl::DefinitionData. This prepares the way for
making ObjCInterfaceDecls redeclarable, to more accurately model
forward declarations of Objective-C classes and eliminate the mutation
of ObjCInterfaceDecl that causes us serious trouble in the AST reader.
Note that ObjCInterfaceDecl's accessors are fairly robust against
being applied to forward declarations, because Clang (and Sema in
particular) doesn't perform RequireCompleteType/hasDefinition() checks
everywhere it has to. Each of these overly-robust cases is marked with
a FIXME, which we can tackle over time.
llvm-svn: 146644
|
|
|
|
|
|
|
| |
members into ObjCClassDecl, saving ourselves one pointer per forward
declaration.
llvm-svn: 146564
|
|
|
|
| |
llvm-svn: 146213
|
|
|
|
|
|
|
|
| |
'ImplicitInterfaceDecl',
no need to store it in another field.
llvm-svn: 144624
|