constructs that can do so into the initialization code. This fixes a number
of different cases in which we used to fail to check for abstract types.
Thanks to Tim Shen for inspiring the weird code that uncovered this!
llvm-svn: 289753
objective-c properties.
This fixes an assert in CodeGen that fires when the getter and setter
functions for an objective-c property of type _Atomic(_Bool) are
synthesized.
rdar://problem/26322972
Differential Revision: http://reviews.llvm.org/D20407
llvm-svn: 270808
instance method.
When diagnosing unimplemented class property, make sure we emit
a warning when we only see an instance method with the right selector.
Also warn when we only see a class method for an instance property.
rdar://26141719
llvm-svn: 269968
PropertyMap used to map IdentifierInfo (name of the property) to
ObjcPropertyDecl *. Now that a class property can have the same name as
an instance property, we change PropertyMap to map a pair <IdentifierInfo *,
unsigned> to ObjcPropertyDecl *.
Also update a few places from iterating over instance_properties to
iterating over all properties.
rdar://23891898
llvm-svn: 259119
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
llvm-svn: 259070
This is the third patch in a series of patches to support class properties
in addition to instance properties in objective-c.
rdar://23891898
llvm-svn: 258834
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
llvm-svn: 258824
When determining whether ownership was explicitly written for a
property when it is being synthesized, also consider that the original
property might have come from a protocol. Fixes rdar://problem/23931441.
llvm-svn: 255943
r251874 stopped back-patching the AST when an Objective-C 'readonly'
property is redeclared in a class extension as 'readwrite'. However,
it did not properly handle merging of Objective-C property attributes
(e.g., getter name, ownership, atomicity) to the redeclaration,
leading to bad metadata. Merge (and check!) those property attributes
so we get the right metadata and reasonable ASTs. Fixes
rdar://problem/23823989.
llvm-svn: 255309
r251874 reworked the way we handle properties declared within
Objective-C class extensions, which had the effective of tightening up
property checking in a number of places. In this particular class of
cases, we end up complaining about "atomic" mismatches between an
implicitly-atomic, readonly property and a nonatomic, readwrite
property, which doesn't make sense because "atomic" is essentially
irrelevant to readonly properties.
Therefore, suppress this diagnostic when the readonly property is
implicitly atomic. Fixes rdar://problem/23803109.
llvm-svn: 255174
The code used "isa" to check the type and then "getAs" to look through
sugar; we need to look through the sugar when checking, too, otherwise
any kind of sugar (nullability qualifiers in the example; or a
typedef) will thwart this semantic check. Fixes rdar://problem/23804250.
llvm-svn: 255066
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.
llvm-svn: 251949
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.
llvm-svn: 251874
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
llvm-svn: 251384
Previously, __weak was silently accepted and ignored in MRC mode.
That makes this a potentially source-breaking change that we have to
roll out cautiously. Accordingly, for the time being, actual support
for __weak references in MRC is experimental, and the compiler will
reject attempts to actually form such references. The intent is to
eventually enable the feature by default in all non-GC modes.
(It is, of course, incompatible with ObjC GC's interpretation of
__weak.)
If you like, you can enable this feature with
-Xclang -fobjc-weak
but like any -Xclang option, this option may be removed at any point,
e.g. if/when it is eventually enabled by default.
This patch also enables the use of the ARC __unsafe_unretained qualifier
in MRC. Unlike __weak, this is being enabled immediately. Since
variables are essentially __unsafe_unretained by default in MRC,
the only practical uses are (1) communication and (2) changing the
default behavior of by-value block capture.
As an implementation matter, this means that the ObjC ownership
qualifiers may appear in any ObjC language mode, and so this patch
removes a number of checks for getLangOpts().ObjCAutoRefCount
that were guarding the processing of these qualifiers. I don't
expect this to be a significant drain on performance; it may even
be faster to just check for these qualifiers directly on a type
(since it's probably in a register anyway) than to do N dependent
loads to grab the LangOptions.
rdar://9674298
llvm-svn: 251041
The inference of _Nullable for weak Objective-C properties was broken
in several ways:
* It was back-patching the type information very late in the process
of checking the attributes for an Objective-C property, which is
just wrong.
* It was using ad hoc checks to try to suppress the warning about
missing nullability specifiers (-Wnullability-completeness), which
didn't actual work in all cases (rdar://problem/22985457)
* It was inferring _Nullable even outside of assumes-nonnull regions,
which is wrong.
Putting the inference of _Nullable for weak Objective-C properties in
the same place as all of the other inference logic fixes all of these
ills.
llvm-svn: 249896
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 *).
llvm-svn: 241543
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.
llvm-svn: 240596
Introduce the clang pragmas "assume_nonnull begin" and "assume_nonnull
end" in which we make default assumptions about the nullability of many
unannotated pointers:
- Single-level pointers are inferred to __nonnull
- NSError** in a (function or method) parameter list is inferred to
NSError * __nullable * __nullable.
- CFErrorRef * in a (function or method) parameter list is inferred
to CFErrorRef __nullable * __nullable.
- Other multi-level pointers are never inferred to anything.
Implements rdar://problem/19191042.
llvm-svn: 240156
'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.
llvm-svn: 240155
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.
llvm-svn: 240154
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
As mentioned in the previous commit, if a property (declared with @property)
has a name that matches a special Objective-C method family, the getter picks
up that family despite being declared by the property. The most correct way
to solve this problem is to add the 'objc_method_family' attribute to the
getter with an argument of 'none', which unfortunately requires an explicit
declaration of the getter.
This commit adds a note to the existing error (ARC) or warning (MRR) for
such a poorly-named property that suggests the solution; if there's already
a declaration of the getter, it even includes a fix-it.
llvm-svn: 226339
auto synthesized because it is synthesized in its super
class. locate property declaration in super class
which will default synthesize the property. rdar://18488727
llvm-svn: 219535
in the super class, do not issue the warning about property
in current class's protocol will not be auto synthesized.
// rdar://18179833
llvm-svn: 216769
Do not warn when property declared in class's protocol will be auto-synthesized
by its uper class implementation because super class has also declared this
property while this class has not. Continue to warn if current class
has declared the property also (because this declaration will not result
in a 2nd synthesis).
rdar://18152478
llvm-svn: 216753
This patch adds support for the msvc pragmas section, bss_seg, code_seg,
const_seg and data_seg as well as support for __declspec(allocate()).
Additionally it corrects semantics and adds diagnostics for
__attribute__((section())) and the interaction between the attribute
and the msvc pragmas and declspec. In general conflicts should now be
well diganosed within and among these features.
In supporting the pragmas new machinery for uniform lexing for
msvc pragmas was introduced. The new machinery always lexes the
entire pragma and stores it on an annotation token. The parser
is responsible for parsing the pragma when the handling the
annotation token.
There is a known outstanding bug in this implementation in C mode.
Because these attributes and pragmas apply _only_ to definitions, we
process them at the time we detect a definition. Due to tentative
definitions in C, we end up processing the definition late. This means
that in C mode, everything that ends up in a BSS section will end up in
the _last_ BSS section rather than the one that was live at the time of
tentative definition, even if that turns out to be the point of actual
definition. This issue is not known to impact anything as of yet
because we are not aware of a clear use or use case for #pragma bss_seg
but should be fixed at some point.
Differential Revision=http://reviews.llvm.org/D3065#inline-16241
llvm-svn: 205810
Richard Smith