| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
in addition of receiver having static type, but also when
receiver has dynamic type (of 'id' variety) as well as when
receiver is of 'Class' type vareity. // rdar://7853549
llvm-svn: 184195
|
|
|
|
|
|
| |
is sent to a receiver object. This is wip. // rdar://7853549
llvm-svn: 184086
|
|
|
|
|
|
|
|
| |
random checks for ObjC object return types to SemaType.cpp.
Fixes issue with ObjC method type checking reported on cfe-dev.
llvm-svn: 184006
|
|
|
|
| |
llvm-svn: 183372
|
|
|
|
|
|
| |
for -Wundeclared-selector warnings. // rdar://14039037
llvm-svn: 183331
|
|
|
|
| |
llvm-svn: 182966
|
|
|
|
|
|
|
|
| |
which diagnoses type mismatches of identical
selectors declared in classes throughout.
// rdar://14007194
llvm-svn: 182964
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
synthesize a property getter method that overrides
a method definition named 'retain' and the like.
Fixes // rdar://13885083
llvm-svn: 182039
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.
One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).
llvm-svn: 181869
|
|
|
|
|
|
|
|
|
| |
recovery form duplicate method definition error thus
preventing doc parsing to loop trying to find comment
for the invalid redefinition in a previous declaration.
// rdar://13836387
llvm-svn: 181710
|
|
|
|
|
|
| |
provided.
llvm-svn: 181039
|
|
|
|
| |
llvm-svn: 180651
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
2 methods (with a particular selector) inside categories.
This is done by extending ObjCMethodList (which is only used by the global method pool) to have 2 extra bits of information.
We will later take advantage of this info in global method pool for the overridden methods calculation.
llvm-svn: 179652
|
|
|
|
|
|
| |
semantics as __thread for now.
llvm-svn: 179424
|
|
|
|
|
|
|
|
|
|
|
| |
when result type of protocol property and getter method
differ by fixing a more serious problem. When a forward
protocol declaration comes between its definition and
its use in class protocol list, the forward protocol
ast was being used in building the protocol list.
// rdar://12522752
llvm-svn: 179108
|
|
|
|
|
|
|
| |
deprecated typedef to subclass or invoke a class method.
// rdar://13569424
llvm-svn: 178775
|
|
|
|
|
|
|
|
|
| |
of a property just in case the property's getter happens to be +1.
We won't synthesize a getter for such a property, but we will allow
the user to define a +1 method for it.
rdar://13115896
llvm-svn: 178731
|
|
|
|
|
|
|
|
|
|
|
| |
http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green
before it processed the reverted 178663, so it could not have been the culprit.
Revert "Revert 178663."
This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41.
llvm-svn: 178682
|
|
|
|
|
|
|
|
|
|
| |
Looks like it broke http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb
Revert "Don't compute a patched/semantic storage class."
This reverts commit 8f187f62cb0487d31bc4afdfcd47e11fe9a51d05.
llvm-svn: 178681
|
|
|
|
|
|
|
|
|
|
|
| |
For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.
This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.
llvm-svn: 178663
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously all unimplemented methods for a class were grouped under
a single warning, with all the unimplemented methods mentioned
as notes. Based on feedback from users, most users would like
a separate warning for each method, with a note pointing back to
the original method declaration.
Implements <rdar://problem/13350414>
llvm-svn: 178097
|
|
|
|
|
|
|
|
| |
we expect a related result type.
rdar://12493140
llvm-svn: 177378
|
|
|
|
|
|
| |
definition. Bump some related diagnostics from warning to extension in C++, since they're errors there. Add some missing checks for function specifiers on non-function declarations.
llvm-svn: 177335
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 176469
|
|
|
|
|
|
| |
visible <rdar://problem/13172858>.
llvm-svn: 174648
|
|
|
|
|
|
|
|
|
| |
lexical declarations looking for properties when we could more
efficiently check for property mismatches at property declaration
time. Good for ~1% of -fsyntax-only time when most of the properties
we're checking against come from an AST file.
llvm-svn: 173079
|
|
|
|
|
|
|
|
|
|
| |
did a redundant traversal of the lexical declarations in the
superclass. Instead, when we declare a new property, look into the
superclass to see whether we're redeclaring the property. Goot for 1%
of -fsyntax-only time on Cocoa.h and a little less than 3% on my
modules test case.
llvm-svn: 173073
|
|
|
|
|
|
|
| |
decay the parameter type immediately; let CheckParameter() do its
job. Fixes <rdar://problem/12071218>.
llvm-svn: 172780
|
|
|
|
|
|
|
| |
undefined, and don't find methods or protocols within those protocol
definitions. This completes <rdar://problem/10634711>.
llvm-svn: 172686
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
consider (sub)module visibility.
The bulk of this change replaces myriad hand-rolled loops over the
linked list of Objective-C categories/extensions attached to an
interface declaration with loops using one of the four new category
iterator kinds:
visible_categories_iterator: Iterates over all visible categories
and extensions, hiding any that have their "hidden" bit set. This is
by far the most commonly used iterator.
known_categories_iterator: Iterates over all categories and
extensions, ignoring the "hidden" bit. This tends to be used for
redeclaration-like traversals.
visible_extensions_iterator: Iterates over all visible extensions,
hiding any that have their "hidden" bit set.
known_extensions_iterator: Iterates over all extensions, whether
they are visible to normal name lookup or not.
The effect of this change is that any uses of the visible_ iterators
will respect module-import visibility. See the new tests for examples.
Note that the old accessors for categories and extensions are gone;
there are *Raw() forms for some of them, for those (few) areas of the
compiler that have to manipulate the linked list of categories
directly. This is generally discouraged.
Part two of <rdar://problem/10634711>.
llvm-svn: 172665
|
|
|
|
|
|
|
| |
when the methods are declared in a submodule that has not yet been
imported. Part of <rdar://problem/10634711>.
llvm-svn: 172635
|
|
|
|
|
|
|
|
| |
overriding and overridden method, allow the overridden method to have
a narrower contract (introduced earlier, deprecated/obsoleted later)
than the overriding method. Fixes <rdar://problem/12992023>.
llvm-svn: 172567
|
|
|
|
|
|
|
| |
list of classes, etc., make sure to look into protocol
definitions. // rdar://12958878
llvm-svn: 171777
|
|
|
|
|
|
| |
unavailable due to availability attributes. <rdar://problem/12798237>
llvm-svn: 169903
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
|
| |
of a deprecated method in original class (or category), only
in overrides. // rdar://12717705
llvm-svn: 168270
|
|
|
|
|
|
|
| |
method type in cateogry matches the implementation.
// rdar://12519216
llvm-svn: 166518
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, unify ObjCShouldCallSuperDealloc and ObjCShouldCallSuperFinalize.
The two have identical behavior and will never be active at the same time.
There's one last simplification now, which is that if we see a call to
[super foo] and we are currently in a method named 'foo', we will
/unconditionally/ clear the ObjCShouldCallSuper flag, rather than check
first to see if we're in a method where calling super is required. There's
no reason to pay the extra lookup price here.
llvm-svn: 166285
|
|
|
|
| |
llvm-svn: 166208
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 163833
|
|
|
|
|
|
|
| |
to SemaDeclObjC and apply some simplification per John's
comment. // rdar://12280826
llvm-svn: 163824
|
|
|
|
|
|
| |
// rdar://12280826
llvm-svn: 163813
|
|
|
|
|
|
|
| |
__autoreleasing is explicitely added to param type.
// rdar://12280826
llvm-svn: 163738
|
|
|
|
|
|
| |
annotations. // rdar://6386358
llvm-svn: 163525
|
|
|
|
|
|
|
|
| |
in classes. Use it to flag those method implementations which don't
contain call to 'super' if they have 'super' class and it has the method
with this attribute set. This is wip. // rdar://6386358
llvm-svn: 163434
|