This reverts commit r334224.
This is causing buildbot failures on Windows, presumably because some
tests don't specify a triple. I'll test this on Windows locally and
recommit with the tests fixed.
llvm-svn: 334240
The body of a `@finally` needs to be executed on both exceptional and
non-exceptional paths. On landingpad platforms, this is straightforward:
the `@finally` body is emitted as a normal (non-exceptional) cleanup,
and then a catch-all is emitted which branches to that cleanup (the
cleanup has code to conditionally re-throw based on a flag which is set
by the catch-all).
Unfortunately, we can't use the same approach for MSVC exceptions, where
the catch-all will be emitted as a catchpad. We can't just branch to the
cleanup from within the catchpad, since we can only exit it via a
catchret, at which point the exception is destroyed and we can't
rethrow. We could potentially emit the finally body inside the catchpad
and have the normal cleanup path somehow branch into it, but that would
require some new IR construct that could branch into a catchpad.
Instead, after discussing it with Reid Kleckner, we decided that
frontend outlining was the best approach, similar to how SEH `__finally`
works today. We decided to use CapturedStmt (which was also suggested by
Reid) rather than CaptureFinder (which is what `__finally` uses) since
the latter doesn't handle a lot of cases we care about, e.g. self
accesses, property accesses, block captures, etc. Extending
CaptureFinder to handle those additional cases proved unwieldy, whereas
CapturedStmt already took care of all of those. In theory `__finally`
could also be moved over to CapturedStmt, which would remove some
existing limitations (e.g. the inability to capture this), although
CaptureFinder would still be needed for SEH filters.
The one case supported by `@finally` but not CapturedStmt (or
CaptureFinder for that matter) is arbitrary control flow out of the
`@finally`, e.g. having a return statement inside a `@finally`. We can
add that support as a follow-up, but in practice we've found it to be
used very rarely anyway.
Differential Revision: https://reviews.llvm.org/D47564
llvm-svn: 334224
-Warc-repeated-use-of-weak may trigger a segmentation fault when the Decl
being checked is outside of a function scope, leaving the current function
info pointer null. This adds a check before using the function info.
llvm-svn: 333471
Summary:
Remove the call to DiagnoseUseOfDecl in LookupMemberExpr because:
1. LookupMemberExpr eagerly lookup both getter and setter, reguardless
if they are used or not. It causes wrong diagnostics if you are only
using getter.
2. LookupMemberExpr only diagnoses getter, but not setter.
3. ObjCPropertyOpBuilder already DiagnoseUseOfDecl when building getter
and setter. Doing it again in LookupMemberExpr causes duplicated
diagnostics.
rdar://problem/38479756
Reviewers: erik.pilkington, arphaman, doug.gregor
Reviewed By: arphaman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D47280
llvm-svn: 333148
E. g. use "10.11" instead of "10_11".
We are maintaining backward compatibility by parsing underscore-delimited version tuples but no longer keep track of the separator and using dot format for output.
Differential Revision: https://reviews.llvm.org/D46747
rdar://problem/39845032
llvm-svn: 332598
The fixit is actively harmful, as it encourages developers to ignore the
warning and to write unsafe code.
It is almost impossible to write safe code while capturing autoreleasing
variables in the block, as in order to check that the block is never
called in the autoreleasing pool the developer has to check the
transitive closure of all potential callers of the block.
Differential Revision: https://reviews.llvm.org/D46778
llvm-svn: 332288
the method declaration is unavailable for an app extension platform
Rationale:
Classes are often shared between an app extension code and
non-app extension code. There's no way to remove the implementation
using preprocessor when building the app extension, so we should not warn here.
rdar://38150617
llvm-svn: 331421
Issue a warning when non-trivial C structs are copied or initialized by
calls to memset, bzero, memcpy, or memmove.
rdar://problem/36124208
Differential Revision: https://reviews.llvm.org/D45310
llvm-svn: 330202
Summary:
There are some functions/methods that run when the application launches
or the library loads. Those functions will run reguardless the OS
version as long as it satifies the minimum deployment target. Annotate
them with availability attributes doesn't really make sense because they
are essentially available on all targets since minimum deployment
target.
rdar://problem/36093384
Reviewers: arphaman, erik.pilkington
Reviewed By: erik.pilkington
Subscribers: erik.pilkington, cfe-commits
Differential Revision: https://reviews.llvm.org/D45699
llvm-svn: 330166
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
structs.
r326307 and r327870 made changes that allowed using non-trivial C
structs with fields qualified with __strong or __weak. This commit makes
the following C++ triviality type traits available to non-trivial C
structs:
__has_trivial_assign
__has_trivial_move_assign
__has_trivial_copy
__has_trivial_move_constructor
__has_trivial_constructor
__has_trivial_destructor
This reapplies r328680. This commit fixes a bug where the copy/move
__has_trivial_* traits would return false when a volatile type was being
passed. Thanks to Richard Smith for pointing out the mistake.
rdar://problem/33599681
Differential Revision: https://reviews.llvm.org/D44913
llvm-svn: 329289
It unintentionally caused the values of the __has_* type traits to change in
C++ for trivially-copyable classes with volatile members.
llvm-svn: 329247
Deprecation replacement can be any text but if it looks like a name of
ObjC method and has the same number of arguments as original method,
replace all slot names so after applying a fix-it you have valid code.
rdar://problem/36660853
Reviewers: aaron.ballman, erik.pilkington, rsmith
Reviewed By: erik.pilkington
Subscribers: cfe-commits, jkorous-apple
Differential Revision: https://reviews.llvm.org/D44589
llvm-svn: 328807
The AST for the fragment
```
@interface I
@end
template <typename>
void decode(I *p) {
for (I *k in p) {}
}
void decode(I *p) {
decode<int>(p);
}
```
differs heavily when templatized and non-templatized:
```
|-FunctionTemplateDecl 0x7fbfe0863940 <line:4:1, line:7:1> line:5:6 decode
| |-TemplateTypeParmDecl 0x7fbfe0863690 <line:4:11> col:11 typename depth 0 index 0
| |-FunctionDecl 0x7fbfe08638a0 <line:5:1, line:7:1> line:5:6 decode 'void (I *__strong)'
| | |-ParmVarDecl 0x7fbfe08637a0 <col:13, col:16> col:16 referenced p 'I *__strong'
| | `-CompoundStmt 0x7fbfe0863b88 <col:19, line:7:1>
| | `-ObjCForCollectionStmt 0x7fbfe0863b50 <line:6:3, col:20>
| | |-DeclStmt 0x7fbfe0863a50 <col:8, col:13>
| | | `-VarDecl 0x7fbfe08639f0 <col:8, col:11> col:11 k 'I *const __strong'
| | |-ImplicitCastExpr 0x7fbfe0863a90 <col:16> 'I *' <LValueToRValue>
| | | `-DeclRefExpr 0x7fbfe0863a68 <col:16> 'I *__strong' lvalue ParmVar 0x7fbfe08637a0 'p' 'I *__strong'
| | `-CompoundStmt 0x7fbfe0863b78 <col:19, col:20>
| `-FunctionDecl 0x7fbfe0863f80 <line:5:1, line:7:1> line:5:6 used decode 'void (I *__strong)'
| |-TemplateArgument type 'int'
| |-ParmVarDecl 0x7fbfe0863ef8 <col:13, col:16> col:16 used p 'I *__strong'
| `-CompoundStmt 0x7fbfe0890cf0 <col:19, line:7:1>
| `-ObjCForCollectionStmt 0x7fbfe0890cc8 <line:6:3, col:20>
| |-DeclStmt 0x7fbfe0890c70 <col:8, col:13>
| | `-VarDecl 0x7fbfe0890c00 <col:8, col:11> col:11 k 'I *__strong' callinit
| | `-ImplicitValueInitExpr 0x7fbfe0890c60 <<invalid sloc>> 'I *__strong'
| |-ImplicitCastExpr 0x7fbfe0890cb0 <col:16> 'I *' <LValueToRValue>
| | `-DeclRefExpr 0x7fbfe0890c88 <col:16> 'I *__strong' lvalue ParmVar 0x7fbfe0863ef8 'p' 'I *__strong'
| `-CompoundStmt 0x7fbfe0863b78 <col:19, col:20>
```
Note how in the instantiated version ImplicitValueInitExpr unexpectedly appears.
While objects are auto-initialized under ARC, it does not make sense to
have an initializer for a for-loop variable, and it makes even less
sense to have such a different AST for instantiated and non-instantiated
version.
Digging deeper, I have found that there are two separate Sema* files for
dealing with templates and for dealing with non-templatized code.
In a non-templatized version, an initialization was performed only for
variables which are not loop variables for an Objective-C loop and not
variables for a C++ for-in loop:
```
if (FRI && (Tok.is(tok::colon) || isTokIdentifier_in())) {
bool IsForRangeLoop = false;
if (TryConsumeToken(tok::colon, FRI->ColonLoc)) {
IsForRangeLoop = true;
if (Tok.is(tok::l_brace))
FRI->RangeExpr = ParseBraceInitializer();
else
FRI->RangeExpr = ParseExpression();
}
Decl *ThisDecl = Actions.ActOnDeclarator(getCurScope(), D);
if (IsForRangeLoop)
Actions.ActOnCXXForRangeDecl(ThisDecl);
Actions.FinalizeDeclaration(ThisDecl);
D.complete(ThisDecl);
return Actions.FinalizeDeclaratorGroup(getCurScope(), DS, ThisDecl);
}
SmallVector<Decl *, 8> DeclsInGroup;
Decl *FirstDecl = ParseDeclarationAfterDeclaratorAndAttributes(
D, ParsedTemplateInfo(), FRI);
```
However the code in SemaTemplateInstantiateDecl was inconsistent,
guarding only against C++ for-in loops.
rdar://38391075
Differential Revision: https://reviews.llvm.org/D44989
llvm-svn: 328749
The diagnostic system for Clang can already handle many AST nodes. Instead
of converting them to strings first, just hand the AST node directly to
the diagnostic system and let it handle the output. Minor changes in some
diagnostic output.
llvm-svn: 328688
structs.
r326307 and r327870 made changes that allowed using non-trivial C
structs with fields qualified with __strong or __weak. This commit makes
the following C++ triviality type traits available to non-trivial C
structs:
__has_trivial_assign
__has_trivial_move_assign
__has_trivial_copy
__has_trivial_move_constructor
__has_trivial_constructor
__has_trivial_destructor
rdar://problem/33599681
Differential Revision: https://reviews.llvm.org/D44913
llvm-svn: 328680
When we have a category implementation without a corresponding interface
(which is an error by itself), semantic checks for property accesses
will attempt to access a null interface declaration and then segfault.
Error out in such cases instead.
Differential Revision: https://reviews.llvm.org/D44916
llvm-svn: 328654
ARC mode.
Declaring __strong pointer fields in structs was not allowed in
Objective-C ARC until now because that would make the struct non-trivial
to default-initialize, copy/move, and destroy, which is not something C
was designed to do. This patch lifts that restriction.
Special functions for non-trivial C structs are synthesized that are
needed to default-initialize, copy/move, and destroy the structs and
manage the ownership of the objects the __strong pointer fields point
to. Non-trivial structs passed to functions are destructed in the callee
function.
rdar://problem/33599681
Differential Revision: https://reviews.llvm.org/D41228
llvm-svn: 326307
This ensures that any availability attributes are attached to the
category before the availability for the referenced protocols is checked.
rdar://37829755
llvm-svn: 325994
iteration bot.
This commit reverts r315639, which was causing clang to print
diagnostics that weren't printed before. Instead, it declares
OverrideSearch::Overridden as a SmallSetVector to fix the
non-deterministic behavior r315639 was trying to fix.
rdar://problem/36445528
llvm-svn: 324425
a warning
This commit separates out the warn_nsconsumed_attribute_mismatch and
warn_nsreturns_retained_attribute_mismatch diagnostic into a warning and error.
This is needed to avoid a module import regression introduced by r313717 that
turned these errors into warnings and started promoting them only when needed,
which caused an error when importing a module as it had different warning
settings.
rdar://36265651
llvm-svn: 321775
This also clarifies some terminology used by the diagnostic (methods -> Objective-C methods, fields -> non-static data members, etc).
Many of the tests needed to be updated in multiple places for the diagnostic wording tweaks. The first instance of the diagnostic for that attribute is fully specified and subsequent instances cut off the complete list (to make it easier if additional subjects are added in the future for the attribute).
llvm-svn: 319002
Block literals can have a type with attributes in its signature, e.g.
ns_returns_retained. The code that inspected the type loc of the block when
declaring its parameters didn't account for this fact, and only looked through
paren type loc. This commit ensures that getAsAdjusted is used instead of
IgnoreParens to find the block's FunctionProtoTypeLoc. This ensures that
block parameters are declared correctly in the block and avoids the
'undeclared identifier' error.
rdar://35416160
llvm-svn: 317736
Objective-C NSString has a class method stringWithUTF8String that creates a new
NSString from a C string. Objective-C box expression @(...) can be used to
create an NSString instead of invoking the stringWithUTF8String method directly
(The compiler lowers it down to the invocation though). This commit ensures that
the type of @(string-value) gets the same nullability attributes as the return
type of stringWithUTF8String to ensure that the diagnostics are consistent
between the two.
rdar://33847186
Differential Revision: https://reviews.llvm.org/D39762
llvm-svn: 317727
Allow Obj-C ivars with incomplete array type but only as the last ivar.
Also add a requirement for ivars that contain a flexible array member to
be at the end of class too. It is possible to add in a subclass another
ivar at the end but we'll emit a warning in this case. Also we'll emit a
warning if a variable sized ivar is declared in class extension or in
implementation because subclasses won't know they should avoid adding
new ivars.
In ARC incomplete array objects are treated as __unsafe_unretained so
require them to be marked as such.
Prohibit synthesizing ivars with flexible array members because order of
synthesized ivars is not obvious and tricky to control. Spelling out
ivar explicitly gives control to developers and helps to avoid surprises
with unexpected ivar ordering.
For C and C++ changed diagnostic to tell explicitly a field is not the
last one and point to the next field. It is not as useful as in Obj-C
but it is an improvement and it is consistent with Obj-C. For C for
unions emit more specific err_flexible_array_union instead of generic
err_field_incomplete.
rdar://problem/21054495
Reviewers: rjmccall, theraven
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38773
llvm-svn: 316381
overridden methods when compiling for non-ARC.
Previously, clang would error out when compiling for ARC, but didn't
print any diagnostics when compiling for non-ARC.
This was pointed out in the patch review for attribute noescape:
https://reviews.llvm.org/D32210
llvm-svn: 313717
Specifically, typo correction should be done before dispatching between
different kinds of binary operations like pseudo-object assignment,
overloaded binary operation, etc.
Without this change we hit an assertion
Assertion failed: (!LHSExpr->hasPlaceholderType(BuiltinType::PseudoObject)), function CheckAssignmentOperands
when in Objective-C we reference a property without `self` and there are
2 equally good typo correction candidates: ivar and a class name. In
this case LHS expression in `BuildBinOp` is
CXXDependentScopeMemberExpr
`-TypoExpr
and instead of handling Obj-C property assignment as pseudo-object
assignment, we call `CreateBuiltinBinOp` which corrects typo to
ObjCPropertyRefExpr '<pseudo-object type>'
but cannot handle pseudo-objects and asserts about it (indirectly,
through `CheckAssignmentOperands`).
rdar://problem/33102722
Reviewers: rsmith, ahatanak, majnemer
Reviewed By: ahatanak
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37322
llvm-svn: 313323
-Wobjc-messaging-id is a new, non-default warning that warns about
message sends to unqualified id in Objective-C. This warning is useful
for projects that would like to avoid any potential future compiler
errors/warnings, as the system frameworks might add a method with the same
selector which could make the message send to id ambiguous.
rdar://33303354
llvm-svn: 311779
This commit fixes a bug introduced in r307903. The attribute ambiguity checker
that was introduced in r307903 checked all property attributes, which caused
errors for source-compatible properties, like:
@property (nonatomic, readonly) NSObject *prop;
@property (nonatomic, readwrite) NSObject *prop;
because the readwrite property would get implicit 'strong' attribute. The
ambiguity checker should be concerned about explicitly specified attributes
only.
rdar://33748089
llvm-svn: 311443
This made it awkward to switch over an enum where some entries
are partial and is unlikley to catch any bugs.
Differential revision: https://reviews.llvm.org/D36777
llvm-svn: 311191
We do not meaningfully track object const-ness of Objective-C object
types. Silence the -Wcast-qual warning that is issued when casting to or
from Objective-C object types results in losing const qualification.
rdar://problem/33807915
llvm-svn: 310672
'#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files
The second recommit (r309106) was reverted because the "non-default #pragma
pack value chages the alignment of struct or union members in the included file"
warning proved to be too aggressive for external projects like Chromium
(https://bugs.chromium.org/p/chromium/issues/detail?id=749197). This recommit
makes the problematic warning a non-default one, and gives it the
-Wpragma-pack-suspicious-include warning option.
The first recommit (r308441) caused a "non-default #pragma pack value might
change the alignment of struct or union members in the included file" warning
in LLVM itself. This recommit tweaks the added warning to avoid warnings for
#includes that don't have any records that are affected by the non-default
alignment. This tweak avoids the previously emitted warning in LLVM.
Original message:
This commit adds a new -Wpragma-pack warning. It warns in the following cases:
- When a translation unit is missing terminating #pragma pack (pop) directives.
- When entering an included file if the current alignment value as determined
by '#pragma pack' directives is different from the default alignment value.
- When leaving an included file that changed the state of the current alignment
value.
rdar://10184173
Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 309386
The warning fires on non-suspicious code in Chromium. Reverting until a
solution is figured out.
> Recommit r308327 2nd time: Add a warning for missing
> '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files
>
> The first recommit (r308441) caused a "non-default #pragma pack value might
> change the alignment of struct or union members in the included file" warning
> in LLVM itself. This recommit tweaks the added warning to avoid warnings for
> #includes that don't have any records that are affected by the non-default
> alignment. This tweak avoids the previously emitted warning in LLVM.
>
> Original message:
>
> This commit adds a new -Wpragma-pack warning. It warns in the following cases:
>
> - When a translation unit is missing terminating #pragma pack (pop) directives.
> - When entering an included file if the current alignment value as determined
> by '#pragma pack' directives is different from the default alignment value.
> - When leaving an included file that changed the state of the current alignment
> value.
>
> rdar://10184173
>
> Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 309186
'#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files
The first recommit (r308441) caused a "non-default #pragma pack value might
change the alignment of struct or union members in the included file" warning
in LLVM itself. This recommit tweaks the added warning to avoid warnings for
#includes that don't have any records that are affected by the non-default
alignment. This tweak avoids the previously emitted warning in LLVM.
Original message:
This commit adds a new -Wpragma-pack warning. It warns in the following cases:
- When a translation unit is missing terminating #pragma pack (pop) directives.
- When entering an included file if the current alignment value as determined
by '#pragma pack' directives is different from the default alignment value.
- When leaving an included file that changed the state of the current alignment
value.
rdar://10184173
Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 309106
This seems to have broken the sanitizer-x86_64-linux buildbot. Reverting until
it's fixed, especially since this landed just before the 5.0 branch.
> This commit adds a new -Wpragma-pack warning. It warns in the following cases:
>
> - When a translation unit is missing terminating #pragma pack (pop) directives.
> - When entering an included file if the current alignment value as determined
> by '#pragma pack' directives is different from the default alignment value.
> - When leaving an included file that changed the state of the current alignment
> value.
>
> rdar://10184173
>
> Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 308455
and suspicious uses of '#pragma pack' in included files
This commit adds a new -Wpragma-pack warning. It warns in the following cases:
- When a translation unit is missing terminating #pragma pack (pop) directives.
- When entering an included file if the current alignment value as determined
by '#pragma pack' directives is different from the default alignment value.
- When leaving an included file that changed the state of the current alignment
value.
rdar://10184173
Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 308441
of '#pragma pack' in included files
This commit adds a new -Wpragma-pack warning. It warns in the following cases:
- When a translation unit is missing terminating #pragma pack (pop) directives.
- When entering an included file if the current alignment value as determined
by '#pragma pack' directives is different from the default alignment value.
- When leaving an included file that changed the state of the current alignment
value.
rdar://10184173
Differential Revision: https://reviews.llvm.org/D35484
llvm-svn: 308327
be shared without warnings. Build AttributedTypes to leave breadcrumbs
for tools like the static analyzer. Warn about attempting to use the
attribute with incompatible return types.
llvm-svn: 308092
property and check for incompatible attributes
This commit changes the way ambiguous property synthesis (i.e. when synthesizing
a property that's declared in multiple protocols) is performed. Previously,
Clang synthesized the first property that was found. This lead to problems when
the property was synthesized in a class that conformed to two protocols that
declared that property and a second protocols had a 'readwrite' declaration -
the setter was not synthesized so the class didn't really conform to the second
protocol and user's code would crash at runtime when they would try to set the
property.
This commit ensures that a first readwrite property is selected. This is a
semantic change that changes users code in this manner:
```
@protocol P @property(readonly) int p; @end
@protocol P2 @property(readwrite) id p; @end
@interface I <P2> @end
@implementation I
@syntesize p; // Users previously got a warning here, and Clang synthesized
// readonly 'int p' here. Now Clang synthesizes readwrite 'id' p..
@end
```
To ensure that this change is safe, the warning about incompatible types is
promoted to an error when this kind of readonly/readwrite ambiguity is detected
in the @implementation. This will ensure that previous code that had this subtle
bug and ignored the warning now will fail to compile with an error, and users
should not get suprises at runtime once they resolve the error.
The commit also extends the ambiguity checker, and now it can detect conflicts
among the different property attributes. An error diagnostic is used for
conflicting attributes, to ensure that the user won't get "suprises" at runtime.
ProtocolPropertyMap is removed in favour of a a set + vector because the map's
order of iteration is non-deterministic, so it couldn't be used to select the
readwrite property.
rdar://31579994
Differential Revision: https://reviews.llvm.org/D35268
llvm-svn: 307903
Objective-C subscript expressions report errors when a subscript method is not
declared in the base class. However, prior to this commit, qualified id types
were not checked. This commit ensures that an appropriate error is reported
when a subscript method is not declared in any of the protocols that are
included in the qualified id type.
rdar://33213924
llvm-svn: 307642
requirements in protocol/class/category declarations
The unguarded availability warnings in the protocol requirements of a protocol
/class/category declaration can be avoided. This matches the behaviour of
Swift's diagnostics. The warnings for deprecated/unavailable protocols are
preserved.
rdar://33156429
Differential Revision: https://reviews.llvm.org/D35061
llvm-svn: 307368
The new compiler warning -Wunguarded-availability-new is a subset of
-Wunguarded-availability. It is on by default. It only warns about uses of APIs
that have been introduced in macOS >= 10.13, iOS >= 11, watchOS >= 4 and
tvOS >= 11. We decided to use this kind of solution as we didn't want to turn
on -Wunguarded-availability by default, because we didn't want our users to get
warnings about uses of old APIs in their existing projects.
rdar://31054725
Differential Revision: https://reviews.llvm.org/D34264
llvm-svn: 306033
These diagnostics can't be disabled, and can't actually catch any bugs.
rdar://32427296
Differential revision: https://reviews.llvm.org/D33661
llvm-svn: 304306
This is an initial commit to allow using it with constant expressions, a follow-up commit will enable full support for it in ObjC methods.
llvm-svn: 303712
As discovered by ChenWJ and listed on cfe-dev, the error for Objective C
return type ended up being wrong. This fixes that. Additionally, as a
"while we're there", the other usages of this error and the usage of the
FP above both use a FixItHint, so I'll add it here.
Differential Revision: https://reviews.llvm.org/D32759
llvm-svn: 302720
`__builtin_available`
This commit allows us to use the macOS/iOS/tvOS/watchOS platform names in
`@available`/`__builtin_available`.
rdar://32067795
Differential Revision: https://reviews.llvm.org/D33000
llvm-svn: 302540
whose introduced version is lower than the allowed version.
We should just rely on the target version as this introduced version can lead
to false positives (e.g. deprecated declarations).
rdar://31964333
llvm-svn: 302250
for iOS < 9 and OS X < 10.11 X86 targets
This commit adds a new error that disallows methods that have parameters/return
values with a vector type for some older X86 targets. This diagnostic is
needed because objc_msgSend doesn't support SIMD vector registers/return values
on X86 in iOS < 9 and OS X < 10.11. Note that we don't necessarily know if the
vector argument/return value will use a SIMD register, so instead we chose to
be conservative and prohibit all vector types.
rdar://21662309
Differential Revision: https://reviews.llvm.org/D28670
llvm-svn: 301532
blocks and lambdas
Prior to this commit Clang emitted the old "partial availability" warning for
expressions that referred to declarations that were not yet introduced in
blocks and lambdas that were not in a function/method. This commit ensures that
top-level blocks and lambdas use the new unguarded availability checks.
rdar://31835952
llvm-svn: 301409
Summary: clang should produce the same errors Objective-C classes that cannot be assigned to weak pointers under both -fobjc-arc and -fobjc-weak. Check for ObjCWeak along with ObjCAutoRefCount when analyzing pointer conversions. Add an -fobjc-weak pass to the existing arc-unavailable-for-weakref test cases to verify the behavior is the same.
Reviewers: rsmith, doug.gregor, rjmccall
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31006
llvm-svn: 299014
Summary: -Warc-repeated-use-of-weak should produce the same warnings with -fobjc-weak as it does with -objc-arc. Also check for ObjCWeak along with ObjCAutoRefCount when recording the use of an evaluated weak variable. Add a -fobjc-weak run to the existing arc-repeated-weak test case and adapt it slightly to work in both modes.
Reviewers: rsmith, doug.gregor, jordan_rose, rjmccall
Reviewed By: rjmccall
Subscribers: arphaman, rjmccall, cfe-commits
Differential Revision: https://reviews.llvm.org/D31005
llvm-svn: 299011
Correct class-template deprecation behavior
Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;
This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.
Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.
Previous DiffRev: https://reviews.llvm.org/D27486, was reverted.
This patch fixes the issues brought up here by the reverter: https://reviews.llvm.org/rL298410
Differential Revision: https://reviews.llvm.org/D31245
llvm-svn: 298634
that became supported after r297019
The commit r297019 expanded the performSelector ObjC method family heuristic
to ensure that -Wobjc-unsafe-perform-selector covers all performSelector
variations. However, this made the -Warc-performSelector-leaks too noisy, as
that warning produces mostly false positives since the selector is unknown.
This commit reverts the ObjC method family heuristics introduced in r297019.
This ensures that -Warc-performSelector-leaks isn't too noisy. The commit still
preserves the coverage of -Wobjc-unsafe-perform-selector.
rdar://31124629
llvm-svn: 298587
Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case:
template<typename T> [[deprecated]] class Foo{}; Foo<int> f;
This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute.
Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute.
Differential Revision: https://reviews.llvm.org/D27486
llvm-svn: 298410
The instance method 'self' does not actually return an over-retained object,
so we shouldn't report an error when it's used with 'performSelector'.
rdar://31071620
llvm-svn: 297961
instance of a qualified Class object when that instance method comes from
a protocol that's implemented by NSObject
Instance methods from a root class like NSObject are also class methods because
the metaclass of root class derives from that root class. Therefore, we can
avoid the warning for instances of qualified Class objects that point to classes
that derive from NSObject. Note that we actually don't know if a Class instance
points to a class that derives from NSObject at compile-time, so we have to
make a reasonable assumption that the majority of instances will do so.
rdar://22812517
llvm-svn: 297862
that return record or vector types
The performSelector family of methods from Foundation use objc_msgSend to
dispatch the selector invocations to objects. However, method calls to methods
that return record types might have to use the objc_msgSend_stret as the return
value won't find into the register. This is also supported by this sentence from
performSelector documentation: "The method should not have a significant return
value and should take a single argument of type id, or no arguments". This
commit adds a new warning that warns when a selector which corresponds to a
method that returns a record type is passed into performSelector.
rdar://12056271
Differential Revision: https://reviews.llvm.org/D30174
llvm-svn: 297019
Using the constructed name for the class properties with dot syntax may
yield an inappropriate selector (i.e. if it is specified via property
attributes). Prefer the declaration for the selector, falling back to
the constructed name otherwise.
Patch by David Herzka!
llvm-svn: 295683
Turning on the warning by default helps the users as it's a common
mistake to capture out-parameters in a block without ensuring the object
assigned doesn't get released.
rdar://problem/30200058
llvm-svn: 293199
even in the presence of nullability qualifiers.
This commit fixes bugs in r285031 where -Wblock-capture-autoreleasing
wouldn't issue warnings when the function parameters were annotated
with nullability qualifiers. Specifically, look through the sugar and
see if there is an AttributedType of kind attr_objc_ownership to
determine whether __autoreleasing was explicitly specified or implicitly
added by the compiler.
rdar://problem/30193488
llvm-svn: 293194
This change avoids the -Wstrict-prototypes warning for block literals with an
empty argument list or without argument lists.
rdar://15060615
Differential Revision: https://reviews.llvm.org/D28296
llvm-svn: 291231
In r267772, we had set the PS4's default dialect for both C and
Objective-C to gnu99. Make that change only for C; we don't really
support Objective-C/C++ so there's no point fiddling the dialect.
llvm-svn: 289625
of a method that was declared in an invalid interface
This commit fixes an infinite loop that occurs when clang tries to iterate over
redeclaration of a method that was declared in an invalid @interface. The
existing validity checks don't catch this as that @interface is a duplicate of
a previously declared valid @interface declaration, so we have to verify that
the found redeclaration is in a valid declaration context.
rdar://29220965
Differential Revision: https://reviews.llvm.org/D26664
llvm-svn: 287530
The previous typo correction handling assumed that ivars are only declared in
the interface declaration rather than as a private ivar in the implementation.
Adjust the handling to permit both interfaces. Assert earlier that the
interface has been acquired to ensure that we can identify when both possible
casts have failed.
Addresses PR31040!
llvm-svn: 287238
Since array parameters decay to pointers, '_Nullable' and friends
should be available for use there as well. This is especially
important for parameters that are typedefs of arrays. The unsugared
syntax for this follows the syntax for 'static'-sized arrays in C:
void test(int values[_Nullable]);
This syntax was previously accepted but the '_Nullable' (and any other
attributes) were silently discarded. However, applying '_Nullable' to
a typedef was previously rejected and is now accepted; therefore, it
may be necessary to test for the presence of this feature:
#if __has_feature(nullability_on_arrays)
One important change here is that DecayedTypes don't always
immediately contain PointerTypes anymore; they may contain an
AttributedType instead. This only affected one place in-tree, so I
would guess it's not likely to cause problems elsewhere.
This commit does not change -Wnullability-completeness just yet. I
want to think about whether it's worth doing something special to
avoid breaking existing clients that compile with -Werror. It also
doesn't change '#pragma clang assume_nonnull' behavior, which
currently treats the following two declarations as equivalent:
#pragma clang assume_nonnull begin
void test(void *pointers[]);
#pragma clang assume_nonnull end
void test(void * _Nonnull pointers[]);
This is not the desired behavior, but changing it would break
backwards-compatibility. Most likely the best answer is going to be
adding a new warning.
Part of rdar://problem/25846421
llvm-svn: 286519
Expose a warning flag for warn_duplicate_protocol_def. This allows control
over the severity of duplicate protocol definitions.
For example -Werror=duplicate-protocol or
#pragma clang diagnostic ignored "-Wduplicate-protocol".
Patch provided by Dave Lee!
Differential Revision: https://reviews.llvm.org/D26406
llvm-svn: 286487
This is done so that the following compiles with no warnings:
int fn(type_10_12) __attribute__((availability(macos, introduced=10.12)));
Differential revision: https://reviews.llvm.org/D25284
llvm-svn: 285457
This patch adds an objc_subclassing_restricted attribute into clang. This
attribute acts similarly to 'final' - Objective-C classes with this attribute
can't be subclassed. However, @interface declarations that have
objc_subclassing_restricted but don't have @implementation are allowed to
inherit other @interface declarations with objc_subclassing_restricted. This is
needed to describe the Swift class hierarchy in clang while making sure that
the Objective-C classes cannot subclass the Swift classes.
This attribute is already implemented in a fork of clang that's used for Swift
(https://github.com/apple/swift-clang) and this patch moves that code to the
upstream clang repository.
rdar://28937548
Differential Revision: https://reviews.llvm.org/D25993
llvm-svn: 285391
The problem with the original commit was that some of Apple's headers depended
on an incorrect behaviour, this commit adds a temporary workaround until those
headers are fixed.
llvm-svn: 285098
Shoaib Meenai