History log of /llvm-project/clang/lib/Parse/ParseObjc.cpp (Results 101 – 125 of 499)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 387ff7f8 26-Jan-2016 Manman Ren <manman.ren@gmail.com>

Class Property: parse property attribute (class).

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

Class Property: parse property attribute (class).

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

show more ...


Revision tags: llvmorg-3.8.0-rc1
# efdccaa9 15-Jan-2016 David Blaikie <dblaikie@gmail.com>

OpaquePtr: Use nullptr construction for ParsedType OpaquePtr typedef

llvm-svn: 257958


# 0403cb11 15-Jan-2016 David Blaikie <dblaikie@gmail.com>

OpaquePtr: Use nullptr construction for DeclGroupPtrTy OpaquePtr typedef

llvm-svn: 257956


# d4336e01 24-Dec-2015 Craig Topper <craig.topper@gmail.com>

[Sema] ArrayRef-ize BuildObjCDictionaryLiteral. NFC

llvm-svn: 256398


# 883dd332 24-Dec-2015 Craig Topper <craig.topper@gmail.com>

[Sema] ArrayRef-ize ParseObjCStringLiteral and CodeCompleteObjCProtocolReferences. NFC

llvm-svn: 256397


# 8ebd580c 16-Dec-2015 Akira Hatanaka <ahatanaka@apple.com>

[Objective-c] Fix a crash that occurs when ObjCTypeParamList::back() is
called on an empty list.

This commit makes Parser::parseObjCTypeParamListOrProtocolRefs return
nullptr if it sees an invalid t

[Objective-c] Fix a crash that occurs when ObjCTypeParamList::back() is
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

show more ...


# 9dd25b76 10-Dec-2015 Douglas Gregor <dgregor@apple.com>

Objective-C properties: merge attributes when redeclaring 'readonly' as 'readwrite' in an extension.

r251874 stopped back-patching the AST when an Objective-C 'readonly'
property is redeclared in a

Objective-C properties: merge attributes when redeclaring 'readonly' as 'readwrite' in an extension.

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

show more ...


Revision tags: llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1
# 3110a5cb 14-Nov-2015 Craig Topper <craig.topper@gmail.com>

Minor formatting fixes. NFC

llvm-svn: 253135


# e301ba2b 11-Nov-2015 Richard Smith <richard-llvm@metafoo.co.uk>

Add support for GCC's '__auto_type' extension, per the GCC manual:
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html

Differences from the GCC extension:
* __auto_type is also permitted in C++ (but onl

Add support for GCC's '__auto_type' extension, per the GCC manual:
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

show more ...


# 3df3f1d2 03-Nov-2015 Richard Smith <richard-llvm@metafoo.co.uk>

Switch to using an explicit scope object to ensure we don't forget to pop ObjC
type parameters off the scope, and fix the cases where we failed to do so.

llvm-svn: 251875


# 0f723bb9 22-Oct-2015 Craig Topper <craig.topper@gmail.com>

Convert ActOnForwardProtocolDeclaration to take an ArrayRef and use a range-based for loop. NFC

llvm-svn: 250990


# a9247eb2 22-Oct-2015 Craig Topper <craig.topper@gmail.com>

Change FindProtocolDeclaration to take an ArrayRef and use a range-based for loop. NFC

llvm-svn: 250988


Revision tags: llvmorg-3.7.0, llvmorg-3.7.0-rc4
# b9fa9964 21-Aug-2015 Richard Smith <richard-llvm@metafoo.co.uk>

[modules] When we see a definition of a function for which we already have a
non-visible definition, skip the new definition to avoid ending up with a
function with multiple definitions.

llvm-svn: 2

[modules] When we see a definition of a function for which we already have a
non-visible definition, skip the new definition to avoid ending up with a
function with multiple definitions.

llvm-svn: 245664

show more ...


Revision tags: llvmorg-3.7.0-rc3, studio-1.4, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1
# cedcd9f8 07-Jul-2015 Douglas Gregor <dgregor@apple.com>

[libclang] Implement proper code-completion in an ObjC type parameter position.

rdar://19670303

llvm-svn: 241561


# 1ac1b63c 07-Jul-2015 Douglas Gregor <dgregor@apple.com>

Implement variance for Objective-C type parameters.

Introduce co- and contra-variance for Objective-C type parameters,
which allows us to express that (for example) an NSArray is covariant
in its ty

Implement variance for Objective-C type parameters.

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

show more ...


# 10dc9d80 07-Jul-2015 Douglas Gregor <dgregor@apple.com>

Warn when an intended Objective-C specialization was actually a useless protocol qualification.

Warn in cases where one has provided redundant protocol qualification
that might be a typo for a speci

Warn when an intended Objective-C specialization was actually a useless protocol qualification.

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

show more ...


# 9bda6cff 07-Jul-2015 Douglas Gregor <dgregor@apple.com>

C++ support for Objective-C lightweight generics.

Teach C++'s tentative parsing to handle specializations of Objective-C
class types (e.g., NSArray<NSString *>) as well as Objective-C
protocol quali

C++ support for Objective-C lightweight generics.

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

show more ...


# e83b9564 07-Jul-2015 Douglas Gregor <dgregor@apple.com>

Substitute type arguments into uses of Objective-C interface members.

When messaging a method that was defined in an Objective-C class (or
category or extension thereof) that has type parameters, su

Substitute type arguments into uses of Objective-C interface members.

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

show more ...


# e9d95f1e 07-Jul-2015 Douglas Gregor <dgregor@apple.com>

Handle Objective-C type arguments.

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

Handle Objective-C type arguments.

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

show more ...


# 85f3f951 07-Jul-2015 Douglas Gregor <dgregor@apple.com>

Parsing, semantic analysis, and AST for Objective-C type parameters.

Produce type parameter declarations for Objective-C type parameters,
and attach lists of type parameters to Objective-C classes,

Parsing, semantic analysis, and AST for Objective-C type parameters.

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

show more ...


# aea7afdc 24-Jun-2015 Douglas Gregor <dgregor@apple.com>

Replace __double_underscored type nullability qualifiers with _Uppercase_underscored

Addresses a conflict with glibc's __nonnull macro by renaming the type
nullability qualifiers as follows:

__no

Replace __double_underscored type nullability qualifiers with _Uppercase_underscored

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

show more ...


Revision tags: llvmorg-3.6.2, llvmorg-3.6.2-rc1
# 5c0870ac 19-Jun-2015 Douglas Gregor <dgregor@apple.com>

Handle 'instancetype' in ParseDeclarationSpecifiers.

...instead of as a special case in ParseObjCTypeName with lots of
duplicated logic. Besides being a nice refactoring, this also allows
"- (instan

Handle 'instancetype' in ParseDeclarationSpecifiers.

...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

show more ...


# bec595a6 19-Jun-2015 Douglas Gregor <dgregor@apple.com>

Check for consistent use of nullability type specifiers in a header.

Adds a new warning (under -Wnullability-completeness) that complains
about pointer, block pointer, or member pointer declarations

Check for consistent use of nullability type specifiers in a header.

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

show more ...


# 2a20bd1a 19-Jun-2015 Douglas Gregor <dgregor@apple.com>

Introduced pragmas for audited nullability regions.

Introduce the clang pragmas "assume_nonnull begin" and "assume_nonnull
end" in which we make default assumptions about the nullability of many
una

Introduced pragmas for audited nullability regions.

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

show more ...


# 849ebc26 19-Jun-2015 Douglas Gregor <dgregor@apple.com>

Implement the 'null_resettable' attribute for Objective-C properties.

'null_resettable' properties are those whose getters return nonnull
but whose setters take nil, to "reset" the property to some

Implement the 'null_resettable' attribute for Objective-C properties.

'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

show more ...


12345678910>>...20