- Some documenation were added.
- Usages of OpaquePtr<A>.getAsVal<A>() were replaced by OpaquePtr<A>.get().
- Methods getAs and getAsVal were renamed to getPtrTo and getPtrAs respectively.
llvm-svn: 189346
properties (direct or indirect) setter/getter (or declared
methods as well) are seen by the method implementation type
matching logic before declaration of method in super class
is seen. This fixes the warning coming out of that method mismatch.
// rdar://14650159
llvm-svn: 188438
method declaration into its implementation to
prevent a bogus warning about mismatched attributes.
then make sure the warning about missing call to super comes out
of the method implementation. // rdar://14251387
llvm-svn: 185974
As an optimization, we only kept declared methods with distinct
signatures in the global method pool, to keep the method lists
small. Under modules, however, one could have two different methods
with the same signature that occur in different (sub)modules. If only
the later submodule is important, message sends to 'id' with that
selector would fail because the first method (the only one that got
into the method pool) was hidden. When building a module, keep *all*
of the declared methods.
I did a quick check of both module build time and uses of modules, and
found no performance regression despite this causing us to keep more
methods in the global method pool. Fixes <rdar://problem/14148896>.
llvm-svn: 184504
If we have something like
@class NewImage;
@compatibility_alias OldImage NewImage;
@class OldImage;
the lookup for 'OldImage' will return the 'NewImage' decl ("@class NewImage").
In such a case, when creating the decl for "@class OldImage" use the real declaration name ("NewImage"),
instead of the alias one ("OldImage"), otherwise we will break IdentifierResolver and redecls-chain invariants.
Fixes crash of rdar://14112291.
llvm-svn: 184238
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
llvm-svn: 160993
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).
llvm-svn: 160078
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....
llvm-svn: 159631
c-functions declared in implementation should have their
parsing delayed until the end so, they can access forward
declared private methods. // rdar://10387088
llvm-svn: 159626
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
llvm-svn: 158793
* Escape #, < and @ symbols where Doxygen would try to interpret them;
* Fix several function param documentation where names had got out of sync;
* Delete param documentation referring to parameters that no longer exist.
llvm-svn: 158472
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
that the methods have the same number of parameters, although we
certainly assumed this in many places. Objective-C can be insane
sometimes. Fixes <rdar://problem/11460990>.
llvm-svn: 157025
in ObjCMethodDecl to indicate whether the method does not override any other method,
which is the majority of cases.
That way we can avoid unnecessary work doing lookups, especially when PCH is involved.
rdar://11360082
llvm-svn: 156476
off PartialDiagnostic. PartialDiagnostic is rather heavyweight for
something that is in the critical path and is rarely used. So, switch
over to an abstract-class-based callback mechanism that delays most of
the work until a diagnostic is actually produced. Good for ~11k code
size reduction in the compiler and 1% speedup in -fsyntax-only on the
code in <rdar://problem/11004361>.
llvm-svn: 156176
performing the search for overridden methods. We very rarely see the
same container twice, and in those rare cases we still have the
fallback of the second SmallPtrSet to eliminate duplicates. Good for
~1.5% -fsyntax-only speedup on the code in <rdar://problem/11004361>.
llvm-svn: 156103
folding its one check into the normal path for checking overridden
Objective-C methods. Good for another 3.6% speedup on the test case in
<rdar://problem/11004361>.
llvm-svn: 155961
declared in a subclass has consistent parameter types with a method
having the same selector in a superclass performs a significant number
of lookups into the class hierarchy. In the example in
<rdar://problem/11004361>, we spend 4.7% of -fsyntax-only time in
these lookups.
Optimize away most of the calls to this routine
(Sema::CompareMethodParamsInBaseAndSuper) by first checking whether we
have ever seen *any* method with that selector (using the global
selector table). Since most selectors are unique, we can avoid the
cost of this name lookup in many cases, for a 3.3% speedup.
llvm-svn: 155958
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
The warning this inhibits, -Wobjc-root-class, is opt-in for now. However, all clang unit tests that would trigger
the warning have been updated to use -Wno-objc-root-class. <rdar://problem/7446698>
llvm-svn: 154187
The deferred lookup table building step couldn't accurately tell which Decls
should be included in the lookup table, and consequently built different tables
in some cases.
Fix this by removing lazy building of DeclContext name lookup tables. In
practice, the laziness was frequently not worthwhile in C++, because we
performed lookup into most DeclContexts. In C, it had a bit more value,
since there is no qualified lookup.
In the place of lazy lookup table building, we simply don't build lookup tables
for function DeclContexts at all. Such name lookup tables are not useful, since
they don't capture the scoping information required to correctly perform name
lookup in a function scope.
The resulting performance delta is within the noise on my testing, but appears
to be a very slight win for C++ and a very slight loss for C. The C performance
can probably be recovered (if it is a measurable problem) by avoiding building
the lookup table for the translation unit.
llvm-svn: 152608
serialized
-Don't add methods of invalid objc containers to the global method pool.
This protects us from trying to serialize a method whose container was not
serialized.
Part of rdar://11007039.
llvm-svn: 152566
of the SmallPtrSet way up to avoid commonly reallocating the buffer size.
- I didn't see a good argument against it, so I bumped the limit to cover the
max size we see during parsing Cocoa.h.
llvm-svn: 151698
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
additional data from the external Sema source. This properly copes
with modules that are imported after we have already searched in the
global method pool for a given selector. For PCH, it's a slight
pessimization to be fixed soon.
llvm-svn: 148891
return pre-built lists. Instead, it feeds the methods it deserializes
to Sema so that Sema can unique them, which keeps the chains shorter.
llvm-svn: 148889
separately-allocated DefinitionData structure. Introduce various
functions that will help with the separation of declarations from
definitions (isThisDeclarationADefinition(), hasDefinition(),
getDefinition()).
llvm-svn: 147408
applies to an actual definition. Plus, clarify the purpose of this
field and give the accessor a different name, since getLocEnd() is
supposed to be the same as getSourceRange().getEnd().
llvm-svn: 146694
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
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
to declaresSameEntity(), as a baby step toward tracking forward
declarations of Objective-C classes precisely. Part of
<rdar://problem/10583531>.
llvm-svn: 146618
inside an objc container that "contains" other file-level declarations.
When getting the array of file-level declarations that overlap with a file region,
we failed to report that the region overlaps with an objc container, if
the container had other file-level declarations declared lexically inside it.
Fix this by marking such declarations as "isTopLevelDeclInObjCContainer" in the AST
and handling them appropriately.
llvm-svn: 145109
Objective-C classes. This has two purposes: to consistently provide
"forward declaration here" notes when we hit an incomplete type, and
to give LLDB a chance to complete the type.
RequireCompleteType bits from Sean Callanan!
llvm-svn: 144573
it is going to be rewritten (and the chain will be serialized again), otherwise we may form a cycle in its
categories list when deserializing.
Also introduce ASTMutationListener::CompletedObjCForwardRef to notify that a forward reference
was completed; using Decl's isChangedSinceDeserialization/setChangedSinceDeserialization
is bug inducing and kinda gross, we should phase it out.
Fixes infinite loop in rdar://10418538.
llvm-svn: 144465
top-level declarations that occurred inside an ObjC container.
This is useful to keep track of such decls otherwise when e.g. a function
is declared inside an objc interface, it is not passed to HandleTopLevelDecl
and it is not inside the DeclContext of the interface that is returned.
llvm-svn: 142232
- Remodel Expr::EvaluateAsInt to behave like the other EvaluateAs* functions,
and add Expr::EvaluateKnownConstInt to capture the current fold-or-assert
behaviour.
- Factor out evaluation of bitfield bit widths.
- Fix a few places which would evaluate an expression twice: once to determine
whether it is a constant expression, then again to get the value.
llvm-svn: 141561
Fariborz Jahanian