This patch ensures that the typo fixit for the @try/@finally/@autoreleasepool {}
directive is shown only when we're parsing an actual statement where such
directives can actually be present.
rdar://19669565
Differential Revision: https://reviews.llvm.org/D26916
llvm-svn: 288334
The ObjC class protocol list assumes there is an associated location for each protocol but no location is provided
when the protocol list comes from a typedef, and we end up with a buffer overflow when trying to get locations for the protocol names.
Fixes crash of rdar://28980278.
llvm-svn: 286331
Fix a crash-on-invalid.
When parsing type arguments and protocols,
parseObjCTypeArgsOrProtocolQualifiers() calls ParseTypeName(), which tries to
find matching tokens for '[', '(', etc whenever they appear among potential
type names. If unmatched, ParseTypeName() yields a tok::eof token stream. This
leads to crashes since the parsing at this point is not expected to go beyond
the param list closing '>'.
Fix that by properly handling tok::eof in
parseObjCTypeArgsOrProtocolQualifiers() callers.
Differential Revision: https://reviews.llvm.org/D23852
rdar://problem/25063557
llvm-svn: 281383
into ParseDeclOrFunctionDefInternal() (which is called by
MaybeParseMicrosoftAttributes()), so that the attributes can be stored in
the DeclSpec. No behavior change yet, part of https://reviews.llvm.org/D23895
llvm-svn: 280574
Sema actions on ObjCDictionaryLiteral and ObjCArryLiteral are currently
done as a side-effect of Sema upon parent expressions, which incurs of
delayed typo corrections for such literals to be performed by TypoTransforms
upon the ObjCDictionaryLiteral and ObjCArryLiteral themselves instead of
its elements individually.
This is specially bad because it was not designed to act on several
elements; searching through all possible combinations of corrections for
several elements is very expensive. Additionally, when one of the
elements has no correction candidate, we still explore all options and
at the end emit no typo corrections whatsoever.
Do the proper sema actions by acting on each element alone during appropriate
literal parsing time to get proper diagonistics and decent compile time
behavior.
Differential Revision: http://reviews.llvm.org/D22183
rdar://problem/21046678
llvm-svn: 276020
This patch adds a new AST node: ObjCAvailabilityCheckExpr, and teaches the
Parser and Sema to generate it. This node represents an availability check of
the form:
@available(macos 10.10, *);
Which will eventually compile to a runtime check of the host's OS version. This
is the first patch of the feature I proposed here:
http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html
Differential Revision: https://reviews.llvm.org/D22171
llvm-svn: 275654
- In functions with try { } catch { }, only the try block would be
skipped, not the catch blocks
- The template functions would still be parsed.
- The initializers within a constructor would still be parsed.
- The inline functions within class would still be stored, only to be
discared later.
- Invalid code with try would assert (as in "int foo() try assert_here")
This attempt to do even less while skipping function bodies.
Differential Revision: http://reviews.llvm.org/D20821
llvm-svn: 272963
Instead of setting DeclSpec's range end to point to the next token
after the DeclSpec, we use getLocForEndOfToken to insert fix-it after a type
name.
Before this fix, fix-it will change
^(NSView view) to ^(*NSView view)
This commit correctly updates the source to ^(NSView* view).
rdar://21042144
Differential Revision: http://reviews.llvm.org/D20844
llvm-svn: 271448
constructor's definition is in an implementation block.
Without this commit, ptr doesn't get initialized to null in the
following code:
struct S {
S();
void *ptr = nullptr;
};
@implementation I
S::S() {}
@end
rdar://problem/25693624
llvm-svn: 266645
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
llvm-svn: 266245
While this won't help fix things like the bug that r260219 addressed, it
seems like good tidy up to have anyway.
(it might be nice if "makeArrayRef" always produced a MutableArrayRef &
let it decay to an ArrayRef when needed - then I'd use that for the
MutableArrayRefs in this patch)
If we had std::dynarray I'd use that instead of unique_ptr+size_t,
ideally (but then it'd have to be threaded down through the Preprocessor
all the way - no idea how painful that would be)
llvm-svn: 260246
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
called on an empty list.
This commit makes Parser::parseObjCTypeParamListOrProtocolRefs return
nullptr if it sees an invalid type parameter (e.g., __kindof) in the
type parameter list.
rdar://problem/23068920
Differential Revision: http://reviews.llvm.org/D15463
llvm-svn: 255754
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
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Differences from the GCC extension:
* __auto_type is also permitted in C++ (but only in places where
it could appear in C), allowing its use in headers that might
be shared across C and C++, or used from C++98
* __auto_type can be combined with a declarator, as with C++ auto
(for instance, "__auto_type *p")
* multiple variables can be declared in a single __auto_type
declaration, with the C++ semantics (the deduced type must be
the same in each case)
This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).
This also fixes PR25449.
Patch by Nicholas Allegra!
llvm-svn: 252690
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.
llvm-svn: 241549
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.
llvm-svn: 241547
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.
llvm-svn: 241545
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
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.
llvm-svn: 241542
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.
llvm-svn: 241541
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
...instead of as a special case in ParseObjCTypeName with lots of
duplicated logic. Besides being a nice refactoring, this also allows
"- (instancetype __nonnull)self" in addition to "- (nonnull instancetype)self".
rdar://problem/19924646
llvm-svn: 240188
Adds a new warning (under -Wnullability-completeness) that complains
about pointer, block pointer, or member pointer declarations that have
not been annotated with nullability information (directly or inferred)
within a header that contains some nullability annotations. This is
intended to be used to help maintain the completeness of nullability
information within a header that has already been audited.
Note that, for performance reasons, this warning will underrepresent
the number of non-annotated pointers in the case where more than one
pointer is seen before the first nullability type specifier, because
we're only tracking one piece of information per header. Part of
rdar://problem/18868820.
llvm-svn: 240158
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
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
llvm-svn: 235276
in debugger mode) to accept @import declarations
and pass them to the debugger.
In the preprocessor, accept import declarations
if the debugger is enabled, but don't actually
load the module, just pass the import path on to
the preprocessor callbacks.
In the Objective-C parser, if it sees an import
declaration in statement context (usual for LLDB),
ignore it and return a NullStmt.
llvm-svn: 223855
Sema::ActOnIdExpression to use the new functionality.
Among other things, this allows recovery in several cases where it
wasn't possible before (e.g. correcting a mistyped static_cast<>).
llvm-svn: 222464
than one method with mismatched type of same selector name.
clang issues a warning to point this out since it may cause
undefined behavior. There are cases though that some APIs
don't care about user methods and such warnings are perceived as
noise. This patch allows users to add paren delimiters around
selector name to turn off such warnings. So, @selector((save:)) will
turn off the warning. It also provides 'fixit' so user knows
what to do. // rdar://16458579
llvm-svn: 211611
Alex Lorenz