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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180198 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179654 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179652 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179108 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178731 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178663 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178374 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178097 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173079 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173073 91177308-0d34-0410-b5e6-96231b3b80d8
decay the parameter type immediately; let CheckParameter() do its
job. Fixes <rdar://problem/12071218>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172780 91177308-0d34-0410-b5e6-96231b3b80d8
undefined, and don't find methods or protocols within those protocol
definitions. This completes <rdar://problem/10634711>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172686 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172665 91177308-0d34-0410-b5e6-96231b3b80d8
when the methods are declared in a submodule that has not yet been
imported. Part of <rdar://problem/10634711>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172635 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172567 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166285 91177308-0d34-0410-b5e6-96231b3b80d8
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'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165626 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163434 91177308-0d34-0410-b5e6-96231b3b80d8
method parameter types which are reference to an objective-C
pointer to object with no explicit ownership. // rdar://10907090
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162959 91177308-0d34-0410-b5e6-96231b3b80d8
type of generated call to super dealloc is 'void'
and asserts if user's dealloc is not of 'void type.
This rule must be enforced in clang front-end (with a
fixit) if this is not the case, instead of asserting in CodeGen.
// rdar://11987838
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160993 91177308-0d34-0410-b5e6-96231b3b80d8
diagnostics implemented -- see testcases.
I created a new TableGen file for comment diagnostics,
DiagnosticCommentKinds.td, because comment diagnostics don't logically
fit into AST diagnostics file. But I don't feel strongly about it.
This also implements support for self-closing HTML tags in comment
lexer and parser (for example, <br />).
In order to issue precise diagnostics CommentSema needs to know the
declaration the comment is attached to. There is no easy way to find a decl by
comment, so we match comments and decls in lockstep: after parsing one
declgroup we check if we have any new, not yet attached comments. If we do --
then we do the usual comment-finding process.
It is interesting that this automatically handles trailing comments.
We pick up not only comments that precede the declaration, but also
comments that *follow* the declaration -- thanks to the lookahead in
the lexer: after parsing the declgroup we've consumed the semicolon
and looked ahead through comments.
Added -Wdocumentation-html flag for semantic HTML errors to allow the user to
disable only HTML warnings (but not HTML parse errors, which we emit as
warnings in -Wdocumentation).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160078 91177308-0d34-0410-b5e6-96231b3b80d8
under -Wsuper-class-method-mismatch for method
mismatches in current and suprt class.
// rdar://11793793
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159784 91177308-0d34-0410-b5e6-96231b3b80d8
initializer.
I really feel like Clang should warn about this, but I can't describe
a good reason. GCC will warn on this in some cases under
-Wsequence-point, but it actually seems like a false positive for that
warning....
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159631 91177308-0d34-0410-b5e6-96231b3b80d8
c-functions declared in implementation should have their
parsing delayed until the end so, they can access forward
declared private methods. // rdar://10387088
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159626 91177308-0d34-0410-b5e6-96231b3b80d8
Argyrios Kyrtzidis