| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
doing Objective-C subscript access. // rdar://16842487
PR19682.
llvm-svn: 210565
|
|
|
|
|
|
|
| |
'NSCopying' protocol when diagnosing block to ObjC pointer conversion.
// rdar://16739120
llvm-svn: 210491
|
|
|
|
|
|
|
| |
an Objective-C object type other than 'id'.
// rdar://16739120
llvm-svn: 209906
|
|
|
|
|
|
|
| |
now deprecated, ObjC containers instead of crashing.
// rdar://16859666
llvm-svn: 209758
|
|
|
|
|
|
|
| |
in Objective-C container declarations (but not
in their definitions. // rdar://10414277
llvm-svn: 209751
|
|
|
|
|
|
|
| |
same framework after complaining about duplicate class definition.
// rdar://17024681
llvm-svn: 209672
|
|
|
|
|
|
|
| |
only when named selector is declared in TU and it is not declared in a system
header. rdar://16600230
llvm-svn: 208443
|
|
|
|
|
|
|
|
|
|
|
| |
The thread safety analysis isn't very useful in ObjC (you can't annotate
ObjC classes or methods) but we can still analyze the actual code and
show violations in usage of C/C++ functions.
Fixes PR19541, which does not use thread safety attributes but crashes
with -Weverything.
llvm-svn: 208436
|
|
|
|
|
|
| |
which is a more correct and consistent term.
llvm-svn: 208142
|
|
|
|
|
|
| |
// rdar://16737117
llvm-svn: 207542
|
|
|
|
|
|
|
|
|
|
| |
are no
designated initializers in the super class hierarchy then it should return false.
rdar://16692535
llvm-svn: 207332
|
|
|
|
|
|
|
| |
'typeof' to extract type of an @encode expression used
in an initializer. // rdar://16655340
llvm-svn: 207004
|
|
|
|
|
|
|
|
| |
on CF type is not sufficient and bridge casting is
still required for proper ownership semantics.
// rdar://16650445
llvm-svn: 206910
|
|
|
|
|
|
|
| |
objects to fund root class's instance methods.
// rdar://16650575
llvm-svn: 206781
|
|
|
|
|
|
|
| |
This tests for broad compatibility with platform SDK headers using the clang
driver and so belongs alongside the other header ingtegration tests.
llvm-svn: 206687
|
|
|
|
|
|
|
|
| |
subclasses do not call [super init] on their initializers.
Part of rdar://16568441
llvm-svn: 206410
|
|
|
|
|
|
|
|
|
|
| |
the class
introduces new initializers.
Part of rdar://16568441
llvm-svn: 206409
|
|
|
|
|
|
|
| |
when bridged Objective-C type conforms to the protocols in CF types's
Objective-C class. // rdar://16393330
llvm-svn: 205659
|
|
|
|
|
|
| |
on a function.
llvm-svn: 205255
|
|
|
|
|
|
|
|
|
|
|
| |
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
|
|
|
|
| |
llvm-svn: 205074
|
|
|
|
|
|
|
| |
default until we provide a work-around for warning
suppression.
llvm-svn: 205066
|
|
|
|
|
|
|
|
|
|
| |
consider that the ObjC interface of the class
includes its class extensions.
This is follow-up for rdar://16305347
llvm-svn: 205065
|
|
|
|
|
|
|
|
|
|
|
| |
-Wselector-type-mismatch default again. After
internal discussions, we think that in most cases
it has helped our developers find hard to detect
undefined behaviors. We are going to provide a syntax
(and fix-it) to suppress the warning in remaining of
false positive cases.
llvm-svn: 205024
|
|
|
|
|
|
|
| |
an opt-in option under -Wselector-type-mismatch.
// rdar://16445728
llvm-svn: 204965
|
|
|
|
|
|
|
|
| |
selectors because we were not going through entire
elements in list of all implemented selectors.
// rdar://16428638
llvm-svn: 204852
|
|
|
|
|
|
| |
expressions of loops.
llvm-svn: 204430
|
|
|
|
|
|
|
|
| |
in class extension is being implemented in primary class implementation
(no overriding is involved).
// rdar://16249335
llvm-svn: 204093
|
|
|
|
|
|
|
|
| |
warnings (warning or lack there of) as well since
blocks are another pattern for envoking other
designated initializers. // rdar://16323233
llvm-svn: 204081
|
|
|
|
|
|
|
|
| |
class method with the same selctor but different argument
types having one of them in class extension.
// rdar://16312105
llvm-svn: 204065
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent work on -Wunreachable-code has focused on suppressing uninteresting
unreachable code that center around "configuration values", but
there are still some set of cases that are sometimes interesting
or uninteresting depending on the codebase. For example, a dead
"break" statement may not be interesting for a particular codebase,
potentially because it is auto-generated or simply because code
is written defensively.
To address these workflow differences, -Wunreachable-code is now
broken into several diagnostic groups:
-Wunreachable-code: intended to be a reasonable "default" for
most users.
and then other groups that turn on more aggressive checking:
-Wunreachable-code-break: warn about dead break statements
-Wunreachable-code-trivial-return: warn about dead return statements
that return "trivial" values (e.g., return 0). Other return
statements that return non-trivial values are still reported
under -Wunreachable-code (this is an area subject to more refinement).
-Wunreachable-code-aggressive: supergroup that enables all these
groups.
The goal is to eventually make -Wunreachable-code good enough to
either be in -Wall or on-by-default, thus finessing these warnings
into different groups helps achieve maximum signal for more users.
TODO: the tests need to be updated to reflect this extra control
via diagnostic flags.
llvm-svn: 203994
|
|
|
|
|
|
|
|
| |
'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
llvm-svn: 203966
|
|
|
|
|
|
|
| |
initializers; but only those declared in class extensions
(not in implementations). // rdar://16305347
llvm-svn: 203954
|
|
|
|
|
|
| |
in an @selector expression. // rdar://15794055
llvm-svn: 203693
|
|
|
|
|
|
| |
as it can commonly happen. // rdar://16261494
llvm-svn: 203598
|
|
|
|
| |
llvm-svn: 203588
|
|
|
|
|
|
|
| |
when a class adopts a protocol that inherits from
undefined protocols. // rdar://16111182
llvm-svn: 203586
|
|
|
|
|
|
|
| |
This includes special casing 'YES' and 'NO', which are constants
defined as macros.
llvm-svn: 203380
|
|
|
|
|
|
|
| |
synthesizing protocol properties if class's super class
implements them. // rdar://16089191
llvm-svn: 203028
|
|
|
|
|
|
| |
'objc_protocol_requires_explicit_implementation' conformance.
llvm-svn: 203024
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inherited protocols and protocols already conformed in the class hierarchy.
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.
llvm-svn: 202948
|
|
|
|
|
|
| |
rdar://14309030
llvm-svn: 202941
|
|
|
|
|
|
|
|
|
| |
'objc_protocol_requires_explicit_implementation'.
This test also illustrates that checking for properties is not working properly with
this attribute, as we are missing a diagnostic for a property not being implemented.
llvm-svn: 202335
|
|
|
|
|
|
|
|
| |
Also assert that we never create non-array string literals again.
PR18939.
llvm-svn: 202147
|
|
|
|
|
|
|
|
|
|
|
| |
behave correctly with default property synthesis.
In particular, if we see an @property within the @interface of a class
conforming to a protocol with this attribute, we treat that as
if the implementation were available, per the rules of default
property synthesis.
llvm-svn: 201911
|
|
|
|
|
|
| |
'objc_protocol_requires_explicit_implementation' can only be applied to protocol definitions.
llvm-svn: 201899
|
|
|
|
|
|
| |
'objc_protocol_requires_explicit_implementation'.
llvm-svn: 201880
|
|
|
|
|
|
|
|
| |
mismatches the one declared in current class; in addition to
those that are directly overridden.
// rdar://15967517
llvm-svn: 201446
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to r199467, __attribute__((nonnull)) (without arguments) can apply
directly to parameters, instead of being applied to the whole function.
However, the old form of nonnull (with an argument index) could also apply
to the arguments of function and block pointers, and both of these can be
passed as parameters.
Now, if 'nonnull' with an argument is found on a parameter, /and/ the
parameter is a function or block pointer, it is handled the old way.
PR18795
llvm-svn: 201162
|
|
|
|
|
|
| |
internal discussions. // rdar://16006401
llvm-svn: 200986
|