| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
override where at least a declaration of a designated initializer is in a super
class and not necessarily in the current class. rdar://19653785.
llvm-svn: 231700
|
|
|
|
|
|
| |
change.
llvm-svn: 230928
|
|
|
|
|
|
|
| |
results. No-one was ever modifying a lookup result, and it would not be
reasonable to do so.
llvm-svn: 230123
|
|
|
|
|
|
| |
Same functionality, but hoists the vector growth out of the loop.
llvm-svn: 229508
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two years ago I added a compile-time "optimization" to
ObjCMethodDecl::findPropertyDecl: exit early if the current method is part
of a special Objective-C method family (like 'new' or 'init'). However, if a
property (declared with @property) has a name that matches a method family,
the getter picks up that family despite being declared by the property. The
early exit then made ObjCMethodDecl::findPropertyDecl decide that there
was no associated property, despite the method itself being marked as an
accessor. This corrects that by removing the early exit.
This does /not/ change the fact that such a getter is considered to return a
value with a +1 retain count. The best way to eliminate this is by adding the
objc_method_family(none) attribute to the getter, but unlike the existing
ns_returns_not_retained that can't be applied directly to the property -- you
have to redeclare the getter instead.
(It'd be nice if @property just implied objc_method_family(none) for its
getter, but that would be a backwards-incompatible change.)
rdar://problem/19038838
llvm-svn: 226338
|
|
|
|
| |
llvm-svn: 224695
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 222392
|
|
|
|
|
|
|
|
|
|
| |
into primary class's named categories before looking
into their protocols. This is because categories are
part of the public interface and , just as primary class,
preference should be given to them before class
(and category) protocols. // rdar://18013929
llvm-svn: 216610
|
|
|
|
|
|
|
| |
to +initilize as this results in an extra call
to this method. rdar://16628028
llvm-svn: 216271
|
|
|
|
|
|
| |
highlights the attribute and the faulty nonpointer type when possible.
llvm-svn: 214507
|
|
|
|
|
|
| |
for my last patch. // rdar://17631257
llvm-svn: 213185
|
|
|
|
|
|
|
|
|
| |
to be applied to class or protocols. This will direct IRGen
for Objective-C metadata to use the new name in various places
where class and protocol names are needed.
rdar:// 17631257
llvm-svn: 213167
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ensure that querying the first declaration for its most recent declaration
checks for redeclarations from the imported module.
This works as follows:
* The 'most recent' pointer on a canonical declaration grows a pointer to the
external AST source and a generation number (space- and time-optimized for
the case where there is no external source).
* Each time the 'most recent' pointer is queried, if it has an external source,
we check whether it's up to date, and update it if not.
* The ancillary data stored on the canonical declaration is allocated lazily
to avoid filling it in for declarations that end up being non-canonical.
We'll still perform a redundant (ASTContext) allocation if someone asks for
the most recent declaration from a decl before setPreviousDecl is called,
but such cases are probably all bugs, and are now easy to find.
Some finessing is still in order here -- in particular, we use a very general
mechanism for handling the DefinitionData pointer on CXXRecordData, and a more
targeted approach would be more compact.
Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was
addressing only a corner of the full problem space here. That's not covered
by this patch.
Early performance benchmarks show that this makes no measurable difference to
Clang performance without modules enabled (and fixes a major correctness issue
with modules enabled). I'll revert if a full performance comparison shows any
problems.
llvm-svn: 209046
|
|
|
|
| |
llvm-svn: 208517
|
|
|
|
|
|
| |
make getNextRedeclaration follow the pattern of its friends getPreviousDecl and getMostRecentDecl.
llvm-svn: 208467
|
|
|
|
|
|
|
|
|
|
| |
are no
designated initializers in the super class hierarchy then it should return false.
rdar://16692535
llvm-svn: 207332
|
|
|
|
| |
llvm-svn: 206411
|
|
|
|
|
|
|
|
|
|
| |
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
|