| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
| |
the class
introduces new initializers.
Part of rdar://16568441
llvm-svn: 206409
|
| |
|
|
|
|
|
|
|
|
| |
consider that the ObjC interface of the class
includes its class extensions.
This is follow-up for rdar://16305347
llvm-svn: 205065
|
| |
|
|
|
|
| |
ivar_end() with iterator_range ivars(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203932
|
| |
|
|
|
|
| |
propimpl_end() with iterator_range property_impls(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203930
|
| |
|
|
|
|
| |
protocol_end() with iterator_range protocols(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203922
|
| |
|
|
|
|
| |
protocol_end() with iterator_range protocols(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203863
|
| |
|
|
|
|
| |
known_extensions_end() with iterator_range known_extensions(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203857
|
| |
|
|
|
|
| |
visible_extensions_end() with iterator_range visible_extensions(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203855
|
| |
|
|
|
|
| |
known_categories_end() with iterator_range known_categories(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203854
|
| |
|
|
|
|
| |
visible_categories_end() with iterator_range visible_categories(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203851
|
| |
|
|
|
|
| |
all_referenced_protocol_begin() and all_referenced_protocol_end() with iterator_range all_referenced_protocols(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203848
|
| |
|
|
|
|
|
|
| |
protocol_end() with iterator_range protocols(). Updating all of the usages of the iterators with range-based for loops.
Drive-by fixing some incorrect types where a for loop would be improperly using ObjCInterfaceDecl::protocol_iterator. No functional changes in these cases.
llvm-svn: 203842
|
| |
|
|
|
|
| |
instmeth_end() with iterator_range instance_methods(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203839
|
| |
|
|
|
|
| |
for clarity.
llvm-svn: 203835
|
| |
|
|
|
|
| |
with iterator_range props(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203830
|
| |
|
|
|
|
| |
as it can commonly happen. // rdar://16261494
llvm-svn: 203598
|
| |
|
|
|
|
| |
iterator_range redecls(). Updating all of the usages of the iterators with range-based for loops, which allows the begin/end forms to be removed entirely.
llvm-svn: 203179
|
| |
|
|
|
|
|
| |
This simplifies my last patch a bit. No change in
functionality.
llvm-svn: 202906
|
| |
|
|
|
|
| |
These were set into deprecation in r199773.
llvm-svn: 200086
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
llvm-svn: 199686
|
| |
|
|
|
|
|
|
| |
user, and attributes implicitly generated to assist in bookkeeping by the compiler. This is done so by table generating a CreateImplicit method for each attribute.
Additionally, remove the optional nature of the spelling list index when creating attributes. This is supported by table generating a Spelling enumeration when the spellings for an attribute are distinct enough to warrant it.
llvm-svn: 199378
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
warning.
- Remove the additions to ObjCMethodDecl & ObjCIVarDecl that were getting de/serialized and consolidate
all functionality for the checking for this warning in Sema::DiagnoseUnusedBackingIvarInAccessor
- Don't check immediately after the method body is finished, check when the @implementation is finished.
This is so we can see if the ivar was referenced by any other method, even if the method was defined after the accessor.
- Don't silence the warning if any method is called from the accessor silence it if the accessor delegates to another method via self.
rdar://15727325
llvm-svn: 198432
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'objc_protocol_requires_explicit_implementation'.
That's a mouthful, and not necessarily the final name. This also
reflects a semantic change where this attribute is now on the
protocol itself instead of a class. This attribute will require
that a protocol, when adopted by a class, is explicitly implemented
by the class itself (instead of walking the super class chain).
Note that this attribute is not "done". This should be considered
a WIP.
llvm-svn: 196955
|
| |
|
|
|
|
|
|
| |
instead of lookupMethod().
lookupMethod also goes through categories, which we don't need there.
llvm-svn: 196942
|
| |
|
|
|
|
|
|
|
|
|
| |
introduces at least one new initializer,
don't assume that it inherits the designated initializers from the super class.
If the assumption was wrong because a new initializer was a designated one that was not marked as such,
we will emit misleading warnings for subclasses of the interface.
llvm-svn: 196476
|
| |
|
|
|
|
|
|
|
|
|
| |
super another initializer and when the implementation does not delegate to
another initializer via a call on 'self'.
A secondary initializer is an initializer method not marked as a designated
initializer within a class that has at least one initializer marked as a
designated initializer.
llvm-svn: 196318
|
| |
|
|
|
|
|
|
| |
calls on
super an initializer that is not a designated one or any initializer on self.
llvm-svn: 196317
|
| |
|
|
|
|
|
|
| |
does not chain to
an init method that is a designated initializer for the superclass.
llvm-svn: 196316
|
| |
|
|
|
|
|
|
|
|
| |
designated initializers of an interface.
If the interface declaration does not have methods marked as designated
initializers then the interface inherits the designated initializers of
its super class.
llvm-svn: 196315
|
| |
|
|
| |
llvm-svn: 195561
|
| |
|
|
|
|
| |
into a helper.
llvm-svn: 195559
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
renamed).
This is still an experimental attribute, but I wanted it in tree
for review. It may still get yanked.
This attribute can only be applied to a class @interface, not
a class extension or category. It does not change the type
system rules for Objective-C, but rather the implementation checking
for Objective-C classes that explicitly conform to a protocol.
During protocol conformance checking, clang recursively searches
up the class hierarchy for the set of methods that compose
a protocol. This attribute will cause the compiler to not consider
the methods contributed by a super class, its categories, and those
from its ancestor classes. Thus this attribute is used to force
subclasses to redeclare (and hopefully re-implement) methods if
they decide to explicitly conform to a protocol where some of those
methods may be provided by a super class.
This attribute intentionally leaves out properties, which are associated
with state. This attribute only considers methods (at least right now)
that are non-property accessors. These represent methods that "do something"
as dictated by the protocol. This may be further refined, and this
should be considered a WIP until documentation gets written or this
gets removed.
llvm-svn: 195533
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
argument.
This enables a micro-optimization in protocol conformance checking
to not examine the class hierarchy twice per method.
As part of this change, remove the default arguments from lookupInstanceMethod()
and lookupClassMethod(). It was becoming very redundant. For clients
needing the default arguments, have them use the full API instead of
these convenience methods.
llvm-svn: 195532
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
can't accidentally be allocated the wrong way (missing prefix data for decls
from AST files, for instance) and simplifies the CreateDeserialized functions a
little. An extra DeclContext* parameter to the not-from-AST-file operator new
allows us to ensure that we don't accidentally call the wrong one when
deserializing (when we don't have a DeclContext), allows some extra checks, and
prepares for some planned modules-related changes to Decl allocation.
No functionality change intended.
llvm-svn: 195426
|
| |
|
|
|
|
|
|
|
|
|
| |
conformance for a class."
After implementing this patch, a few concerns about the language
feature itself emerged in my head that I had previously not considered.
I want to resolve those design concerns first before having
a half-designed language feature in the tree.
llvm-svn: 195328
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for a class.
The idea is to allow a class to stipulate that its methods (and those
of its parents) cannot be used for protocol conformance in a subclass.
A subclass is then explicitly required to re-implement those methods
of they are present in the class marked with this attribute.
Currently the attribute can only be applied to an @interface, and
not a category or class extension. This is by design. Unlike
protocol conformance, where a category can add explicit conformance
of a protocol to class, this anti-conformance really needs to be
observed uniformly by all clients of the class. That's because
the absence of the attribute implies more permissive checking of
protocol conformance.
This unfortunately required changing method lookup in ObjCInterfaceDecl
to take an optional protocol parameter. This should not slow down
method lookup in most cases, and is just used for protocol conformance.
llvm-svn: 195323
|
| |
|
|
|
|
|
| |
backing warning is not used in one of its accessor methods.
// rdar://14989999
llvm-svn: 193439
|
| |
|
|
|
|
| |
Every other function in Redeclarable.h was using Decl instead of Declaration.
llvm-svn: 192900
|
| |
|
|
|
|
|
|
|
|
|
|
| |
migrate to 'copy attribute if Object
class implements NSCopying otherwise
assume implied 'strong'. Remove
lifetime qualifier on property as it has
moved to property's attribute. Added TODO
comment for future work by poking into
setter implementation.
llvm-svn: 186037
|
| |
|
|
|
|
|
|
|
|
|
| |
ObjMethodDecl, resulting from invalid code.
Check for invalid decls in ObjCMethodDecl::getNextRedeclaration(); otherwise if we start from an invalid redeclaration
of an @implementation we would move to the @interface and not reach the original declaration again.
Fixes rdar://14024851
llvm-svn: 182951
|
| |
|
|
|
|
|
|
| |
protocols that declare the same property of incompatible
types, issue a warning when class implementation synthesizes
the property. // rdar://13075400
llvm-svn: 182316
|
| |
|
|
|
|
|
|
| |
constructor from None
Patch by Robert Wilhelm.
llvm-svn: 181139
|
| |
|
|
|
|
| |
provided.
llvm-svn: 181039
|
| |
|
|
|
|
|
|
|
|
| |
patch -n r180198.
When reporting on missing property accessor implementation in
categories, do not report when they are declared in primary class,
class's protocol, or one of it super classes or in of the other
categories. // rdar://13713098
llvm-svn: 180580
|
| |
|
|
|
|
|
|
| |
categories, do not report when they are declared in primary class,
class's protocol, or one of it super classes. This is because,
its class is going to implement them. // rdar://13713098
llvm-svn: 180198
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
overridden methods.
When we are in a implementation, we check the global method pool whether there were category
methods with the same selector. If there were none (common case) we don't need to do lookups for
overridden methods again.
Note that for an interface method (if we don't encounter its implementation), it is considered that
it overrides methods that were declared before it, not for category methods introduced after it.
This is tradeoff in favor of performance, since it is expensive to do lookups in case there was a
category, and moving the global method pool to ASTContext (so we can check it) would increase complexity.
rdar://13508196
llvm-svn: 179654
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit r179436.
Due to caching, it was possible that we could miss overridden methods that
were introduced by categories later on.
Along with reverting the commit I also included a test case that would have caught this.
llvm-svn: 179547
|
| |
|
|
|
|
|
| |
Use an newly introduce ASTContext::getBaseObjCCategoriesAfterInterface() which caches its
results instead of re-calculating the categories multiple times.
llvm-svn: 179436
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When using modules we should not ignore overridden methods from
categories that are hidden because the module is not visible.
This will give more consistent results (when imports change) and it's more
correct since the methods are indeed overridden even if they are not "visible"
for lookup purposes.
rdar://13350796
llvm-svn: 178374
|