r265877 tries to put methods that are deprecated or unavailable to the
front of the global pool to emit diagnostics, but it breaks some of
our existing codes that depend on choosing a certain method for id
lookup.
This commit orders the methods with the same declaration with respect
to the availability, but do not order methods with different declaration.
rdar://25707511
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266264 91177308-0d34-0410-b5e6-96231b3b80d8
Under certain conditions clang currently fails to properly diagnostic ObjectC
parameter list when type args and protocols are mixed in the same list. This
happens when the first item in the parameter list is a (1) protocol, (2)
unknown type or (3) a list of protocols/unknown types up to the first type
argument. Fix the problem to report the proper error, example:
NSArray<M, NSValue *, NSURL, NSArray <id <M>>> *foo = @[@"a"];
NSNumber *bar = foo[0];
NSLog(@"%@", bar);
$ clang ...
x.m:7:13: error: angle brackets contain both a type ('NSValue') and a protocol ('M')
NSArray<M, NSValue *, NSURL, NSArray <id <M>>> *foo = @[@"a"];
~ ^
Differential Revision: http://reviews.llvm.org/D18997
rdar://problem/22204367
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266245 91177308-0d34-0410-b5e6-96231b3b80d8
To make kindof lookup work, we need to insert methods with different
context into the global pool, even though they have the same siganture.
Since diagnosis of availability is performed on the best candidate,
which is often the first candidate from the global pool, we prioritize
the methods that are unavaible or deprecated to the head of the list.
Since we now have more methods in the global pool, we need to watch
out for performance impact.
rdar://25635831
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265877 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of searching the global pool multiple times: in
LookupFactoryMethodInGlobalPool, LookupInstanceMethodInGlobalPool,
CollectMultipleMethodsInGlobalPool, and AreMultipleMethodsInGlobalPool,
we now collect the method candidates in CollectMultipleMethodsInGlobalPool
only, and other functions will use the collected method set.
This commit adds parameter "Methods" to AreMultipleMethodsInGlobalPool,
and SelectBestMethod. It also changes the implementation of
CollectMultipleMethodsInGlobalPool to collect the desired kind first, if none is
found, to collect the other kind. This avoids the need to call both
LookupFactoryMethodInGlobalPool and LookupInstanceMethodInGlobalPool.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265711 91177308-0d34-0410-b5e6-96231b3b80d8
The objc_runtime_visible attribute deals with an odd corner case where
a particular Objective-C class is known to the Objective-C runtime
(and, therefore, accessible by name) but its symbol has been hidden
for some reason. For such classes, teach CodeGen to use
objc_lookUpClass to retrieve the Class object, rather than referencing
the class symbol directly.
Classes annotated with objc_runtime_visible have two major limitations
that fall out from places where Objective-C metadata needs to refer to
the class (or metaclass) symbol directly:
* One cannot implement a subclass of an objc_runtime_visible class.
* One cannot implement a category on an objc_runtime_visible class.
Implements rdar://problem/25494092.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265201 91177308-0d34-0410-b5e6-96231b3b80d8
option. Previously these options could both be used to specify that you were
compiling the implementation file of a module, with a different set of minor
bugs in each case.
This change removes -fmodule-implementation-of, and instead tracks a flag to
determine whether we're currently building a module. -fmodule-name now behaves
the same way that -fmodule-implementation-of previously did.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261372 91177308-0d34-0410-b5e6-96231b3b80d8
Add "enum ObjCPropertyQueryKind" to a few APIs that used to only take the name
of the property: ObjCPropertyDecl::findPropertyDecl,
ObjCContainerDecl::FindPropertyDeclaration,
ObjCInterfaceDecl::FindPropertyVisibleInPrimaryClass,
ObjCImplDecl::FindPropertyImplDecl, and Sema::ActOnPropertyImplDecl.
ObjCPropertyQueryKind currently has 3 values:
OBJC_PR_query_unknown, OBJC_PR_query_instance, OBJC_PR_query_class
This extra parameter specifies that we are looking for an instance property with
the given name, or a class property with the given name, or any property with
the given name (if both exist, the instance property will be returned).
rdar://23891898
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259070 91177308-0d34-0410-b5e6-96231b3b80d8
Change a few places where we assume property accessors can only be instance
methods.
rdar://23891898
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258980 91177308-0d34-0410-b5e6-96231b3b80d8
All current properties are instance properties.
This is the second patch in a series of patches to support class properties
in addition to instance properties in objective-c.
rdar://23891898
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258824 91177308-0d34-0410-b5e6-96231b3b80d8
is complete (with an error produced if not) and a function that merely queries
whether the type is complete. Either way we'll trigger instantiation if
necessary, but only the former will diagnose and recover from missing module
imports.
The intent of this change is to prevent a class of bugs where code would call
RequireCompleteType(..., 0) and then ignore the result. With modules, we must
check the return value and use it to determine whether the definition of the
type is visible.
This also fixes a debug info quality issue: calls to isCompleteType do not
trigger the emission of debug information for a type in limited-debug-info
mode. This allows us to avoid emitting debug information for type definitions
in more cases where we believe it is safe to do so.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256049 91177308-0d34-0410-b5e6-96231b3b80d8
Now that the properties created within Objective-C class extensions go
into the extension themselves, we don't need any of the extra
complexity here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251949 91177308-0d34-0410-b5e6-96231b3b80d8
A 'readonly' Objective-C property declared in the primary class can
effectively be shadowed by a 'readwrite' property declared within an
extension of that class, so long as the types and attributes of the
two property declarations are compatible.
Previously, this functionality was implemented by back-patching the
original 'readonly' property to make it 'readwrite', destroying source
information and causing some hideously redundant, incorrect
code. Simplify the implementation to express how this should actually
be modeled: as a separate property declaration in the extension that
shadows (via the name lookup rules) the declaration in the primary
class. While here, correct some broken Fix-Its, eliminate a pile of
redundant code, clean up the ARC migrator's handling of properties
declared in extensions, and fix debug info's naming of methods that
come from categories.
A wonderous side effect of doing this write is that it eliminates the
"AddedObjCPropertyInClassExtension" method from the AST mutation
listener, which in turn eliminates the last place where we rewrite
entire declarations in a chained PCH file or a module file. This
change (which fixes rdar://problem/18475765) will allow us to
eliminate the rewritten-decls logic from the serialization library,
and fixes a crash (rdar://problem/23247794) illustrated by the
test/PCH/chain-categories.m example.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251874 91177308-0d34-0410-b5e6-96231b3b80d8
allow them to be written in certain kinds of user declaration and
diagnose on the use-site instead.
Also, improve and fix some diagnostics relating to __weak and
properties.
rdar://23228631
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251384 91177308-0d34-0410-b5e6-96231b3b80d8
silently ignore them on arguments when they're provided indirectly
(.e.g behind a template argument or typedef).
This is mostly just good language design --- specifying that a
generic argument is __weak doesn't actually do anything --- but
it also prevents assertions when trying to apply a different
ownership qualifier.
rdar://21612439
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248436 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce co- and contra-variance for Objective-C type parameters,
which allows us to express that (for example) an NSArray is covariant
in its type parameter. This means that NSArray<NSMutableString *> * is
a subtype of NSArray<NSString *> *, which is expected of the immutable
Foundation collections.
Type parameters can be annotated with __covariant or __contravariant
to make them co- or contra-variant, respectively. This feature can be
detected by __has_feature(objc_generics_variance). Implements
rdar://problem/20217490.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241549 91177308-0d34-0410-b5e6-96231b3b80d8
Warn in cases where one has provided redundant protocol qualification
that might be a typo for a specialization, e.g., NSArray<NSObject>,
which is pointless (NSArray declares that it conforms to NSObject) and
is likely to be a typo for NSArray<NSObject *>, i.e., an array of
NSObject pointers. This warning is very narrow, only applying when the
base type being qualified is parameterized, has the same number of
parameters as their are protocols listed, all of the names can also
refer to types (including Objective-C class types, of course), and at
least one of those types is an Objective-C class (making this a typo
for a missing '*'). The limitations are partly for performance reasons
(we don't want to do redundant name lookup unless we really need to),
and because we want the warning to apply in very limited cases to
limit false positives.
Part of rdar://problem/6294649.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241547 91177308-0d34-0410-b5e6-96231b3b80d8
Teach C++'s tentative parsing to handle specializations of Objective-C
class types (e.g., NSArray<NSString *>) as well as Objective-C
protocol qualifiers (id<NSCopying>) by extending type-annotation
tokens to handle this case. As part of this, remove Objective-C
protocol qualifiers from the declaration specifiers, which never
really made sense: instead, provide Sema entry points to make them
part of the type annotation token. Among other things, this properly
diagnoses bogus types such as "<NSCopying> id" which should have been
written as "id <NSCopying>".
Implements template instantiation support for, e.g., NSArray<T>*
in C++. Note that parameterized classes are not templates in the C++
sense, so that cannot (for example) be used as a template argument for
a template template parameter. Part of rdar://problem/6294649.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241545 91177308-0d34-0410-b5e6-96231b3b80d8
When messaging a method that was defined in an Objective-C class (or
category or extension thereof) that has type parameters, substitute
the type arguments for those type parameters. Similarly, substitute
into property accesses, instance variables, and other references.
This includes general infrastructure for substituting the type
arguments associated with an ObjCObject(Pointer)Type into a type
referenced within a particular context, handling all of the
substitutions required to deal with (e.g.) inheritance involving
parameterized classes. In cases where no type arguments are available
(e.g., because we're messaging via some unspecialized type, id, etc.),
we substitute in the type bounds for the type parameters instead.
Example:
@interface NSSet<T : id<NSCopying>> : NSObject <NSCopying>
- (T)firstObject;
@end
void f(NSSet<NSString *> *stringSet, NSSet *anySet) {
[stringSet firstObject]; // produces NSString*
[anySet firstObject]; // produces id<NSCopying> (the bound)
}
When substituting for the type parameters given an unspecialized
context (i.e., no specific type arguments were given), substituting
the type bounds unconditionally produces type signatures that are too
strong compared to the pre-generics signatures. Instead, use the
following rule:
- In covariant positions, such as method return types, replace type
parameters with “id” or “Class” (the latter only when the type
parameter bound is “Class” or qualified class, e.g,
“Class<NSCopying>”)
- In other positions (e.g., parameter types), replace type
parameters with their type bounds.
- When a specialized Objective-C object or object pointer type
contains a type parameter in its type arguments (e.g.,
NSArray<T>*, but not NSArray<NSString *> *), replace the entire
object/object pointer type with its unspecialized version (e.g.,
NSArray *).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241543 91177308-0d34-0410-b5e6-96231b3b80d8
Objective-C type arguments can be provided in angle brackets following
an Objective-C interface type. Syntactically, this is the same
position as one would provide protocol qualifiers (e.g.,
id<NSCopying>), so parse both together and let Sema sort out the
ambiguous cases. This applies both when parsing types and when parsing
the superclass of an Objective-C class, which can now be a specialized
type (e.g., NSMutableArray<T> inherits from NSArray<T>).
Check Objective-C type arguments against the type parameters of the
corresponding class. Verify the length of the type argument list and
that each type argument satisfies the corresponding bound.
Specializations of parameterized Objective-C classes are represented
in the type system as distinct types. Both specialized types (e.g.,
NSArray<NSString *> *) and unspecialized types (NSArray *) are
represented, separately.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241542 91177308-0d34-0410-b5e6-96231b3b80d8
Produce type parameter declarations for Objective-C type parameters,
and attach lists of type parameters to Objective-C classes,
categories, forward declarations, and extensions as
appropriate. Perform semantic analysis of type bounds for type
parameters, both in isolation and across classes/categories/extensions
to ensure consistency.
Also handle (de-)serialization of Objective-C type parameter lists,
along with sundry other things one must do to add a new declaration to
Clang.
Note that Objective-C type parameters are typedef name declarations,
like typedefs and C++11 type aliases, in support of type erasure.
Part of rdar://problem/6294649.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241541 91177308-0d34-0410-b5e6-96231b3b80d8
Addresses a conflict with glibc's __nonnull macro by renaming the type
nullability qualifiers as follows:
__nonnull -> _Nonnull
__nullable -> _Nullable
__null_unspecified -> _Null_unspecified
This is the major part of rdar://problem/21530726, but does not yet
provide the Darwin-specific behavior for the old names.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240596 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
'null_resettable' properties are those whose getters return nonnull
but whose setters take nil, to "reset" the property to some
default. Implements rdar://problem/19051334.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240155 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce context-sensitive, non-underscored nullability specifiers
(nonnull, nullable, null_unspecified) for Objective-C method return
types, method parameter types, and properties.
Introduce Objective-C-specific semantics, including computation of the
nullability of the result of a message send, merging of nullability
information from the @interface of a class into its @implementation,
etc .
This is the Objective-C part of rdar://problem/18868820.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240154 91177308-0d34-0410-b5e6-96231b3b80d8
in the context of the container itself.
Otherwise we will emit 'unavailable' errors when referencing an unavailable super class
even though the subclass is also marked 'unavailable'.
rdar://20598702
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235276 91177308-0d34-0410-b5e6-96231b3b80d8
attribute to be placed on Objective-C pointer typedef
to make them strong enough so on their "new" method
family no attempt is made to override these
types. rdar://20255473
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235128 91177308-0d34-0410-b5e6-96231b3b80d8
"multiple methods named '<selector>' found" warning by noting
the method that is actualy used. It also cleans up and refactors
code in this area and selects a method that matches actual arguments
in case of receiver being a forward class object.
rdar://19265430
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235023 91177308-0d34-0410-b5e6-96231b3b80d8
warning when multiple method declarations are found in global pool
with differing types and some are available.
rdar://20408445
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234328 91177308-0d34-0410-b5e6-96231b3b80d8
order based on order of insertion.
This should cause both our warnings about these and the modules
serialization to be deterministic as a consequence.
Found by inspection.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233343 91177308-0d34-0410-b5e6-96231b3b80d8
override where at least a declaration of a designated initializer is in a super
class and not necessarily in the current class. rdar://19653785.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231700 91177308-0d34-0410-b5e6-96231b3b80d8
property accessors in @selector not implemented
because they will be auto-synthesized. rdar://16607480
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229919 91177308-0d34-0410-b5e6-96231b3b80d8
Don't warn when a selector has an unavailable and an available variant,
and the first also has an implementation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224881 91177308-0d34-0410-b5e6-96231b3b80d8
Remove ObjCMethodList::Count, instead store a "has more than one decl" bit in
the low bit of the ObjCMethodDecl pointer, using a PointerIntPair.
Most of this patch is replacing ".Method" with ".getMethod()".
No intended behavior change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224876 91177308-0d34-0410-b5e6-96231b3b80d8
of new warning for deprecated method call for receiver
of type 'id'. This addresses rdar://18960378 where
unintended warnings being issued.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221933 91177308-0d34-0410-b5e6-96231b3b80d8
The MS ABI has a notion of 'required alignment' for fields; this
alignment supercedes pragma pack directives.
MSVC takes into account alignment attributes on typedefs when
determining whether or not a field has a certain required alignment.
Do the same in clang by tracking whether or not we saw such an attribute
when calculating the type's bitwidth and alignment.
This fixes PR20418.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D4714
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214274 91177308-0d34-0410-b5e6-96231b3b80d8
The compilation pipeline doesn't actually need to know about the high-level
concept of diagnostic mappings, and hiding the final computed level presents
several simplifications and other potential benefits.
The only exceptions are opportunistic checks to see whether expensive code
paths can be avoided for diagnostics that are guaranteed to be ignored at a
certain SourceLocation.
This commit formalizes that invariant by introducing and using
DiagnosticsEngine::isIgnored() in place of individual level checks throughout
lex, parse and sema.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211005 91177308-0d34-0410-b5e6-96231b3b80d8
selectors because we were not going through entire
elements in list of all implemented selectors.
// rdar://16428638
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204852 91177308-0d34-0410-b5e6-96231b3b80d8
"No need to issue deprecated warning if deprecated method
in class extension is being implemented in primary class implementation
(no overriding is involved).
// rdar://16249335". No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204159 91177308-0d34-0410-b5e6-96231b3b80d8
in class extension is being implemented in primary class implementation
(no overriding is involved).
// rdar://16249335
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204093 91177308-0d34-0410-b5e6-96231b3b80d8
class method with the same selctor but different argument
types having one of them in class extension.
// rdar://16312105
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204065 91177308-0d34-0410-b5e6-96231b3b80d8
'init' methods which are unavailable. Subclasses of NSObject
have to implement such methods as a common pattern to prevent
user's own implementation. // rdar://16305460
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203984 91177308-0d34-0410-b5e6-96231b3b80d8
'init' methods which are unavailable. Subclasses of NSObject
have to implement such methods as a common pattern to prevent
user's own implementation. // rdar://16305460
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203966 91177308-0d34-0410-b5e6-96231b3b80d8
Per more discussion, 'objc_protocol_requires_explicit_implementation' is
refinement that it mainly adds that requirement that a protocol must be
explicitly satisfied at the moment the first class in the class hierarchy
conforms to it. Any subclasses that also conform to that protocol,
either directly or via conforming to a protocol that inherits that protocol,
do not need to re-implement that protocol.
Doing this requires first doing a pass on the super class hierarchy,
gathering the set of protocols conformed to by the super classes,
and then culling those out when determining conformance. This
two-pass algorithm could be generalized for all protocol checking,
and could possibly be a performance win in some cases. For now
we restrict this change to protocols with this attribute to isolate
the change in logic (especially as the design continues to evolve).
This change needs to be adjusted for properties as well; this
only impacts methods right now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202948 91177308-0d34-0410-b5e6-96231b3b80d8
We're going to extend DiagnoseUnimplementedProperties shortly to look for more cases
that aren't handled by default property synthesis.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201878 91177308-0d34-0410-b5e6-96231b3b80d8
was not being overridden in the category method implementation
resulting in bogus warning. // rdar://15919775
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200342 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200082 91177308-0d34-0410-b5e6-96231b3b80d8
not using backing ivar warning, ignore when
property is not being synthesized (user declared its
implementation @dynamic). // rdar://1583425
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199820 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199378 91177308-0d34-0410-b5e6-96231b3b80d8
which may belong to unrelated classes. It was
primarily intended for miuse of @selector expression.
But warning is too noisy and will be issued when
an actual @selector is used. // rdar://15740134
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198952 91177308-0d34-0410-b5e6-96231b3b80d8
- 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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198432 91177308-0d34-0410-b5e6-96231b3b80d8
backing ivar by not issuing this warning if ivar is referenced
somewhere and accessor makes method calls. // rdar://15727325
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198367 91177308-0d34-0410-b5e6-96231b3b80d8
Manman Ren