When checking if block types are compatible, we are checking for
compatibility their return types and parameters' types. As these types
have different variance, we need to check them in different order.
rdar://problem/52788423
Reviewers: erik.pilkington, arphaman
Reviewed By: arphaman
Subscribers: jkorous, dexonsmith, ributzka, cfe-commits
Differential Revision: https://reviews.llvm.org/D66831
llvm-svn: 370130
Only honour format_arg attributes on -[NSBundle localizedStringForKey] when its
argument has a format specifier in it, otherwise its likely to just be a key to
fetch localized strings.
Fixes rdar://23622446
Differential revision: https://reviews.llvm.org/D27165
llvm-svn: 368878
This patch adds the SVE built-in types defined by the Procedure Call
Standard for the Arm Architecture:
https://developer.arm.com/docs/100986/0000
It handles the types in all relevant places that deal with built-in types.
At the moment, some of these places bail out with an error, including:
(1) trying to generate LLVM IR for the types
(2) trying to generate debug info for the types
(3) trying to mangle the types using the Microsoft C++ ABI
(4) trying to @encode the types in Objective C
(1) and (2) are fixed by follow-on patches but (unlike this patch)
they deal mostly with target-specific LLVM details, so seemed like
a logically separate change. There is currently no spec for (3) and
(4), so reporting an error seems like the correct behaviour for now.
The intention is that the types will become sizeless types:
http://lists.llvm.org/pipermail/cfe-dev/2019-June/062523.html
The main purpose of the sizeless type extension is to diagnose
impossible or dangerous uses of the types, such as any that would
require sizeof to have a meaningful defined value.
Until then, the patch sets the alignments of the types to the values
specified in the link above. It also sets the sizes of the types to
zero, which is chosen to be consistently wrong and shouldn't affect
correctly-written code (i.e. code that would compile even with the
sizeless type extension).
The patch adds the common subset of functionality needed to test the
sizeless type extension on the one hand and to provide SVE intrinsic
functions on the other. After this patch, the two pieces of work are
essentially independent.
The patch is based on one by Graham Hunter:
https://reviews.llvm.org/D59245
Differential Revision: https://reviews.llvm.org/D62960
llvm-svn: 368413
This reverts commit r365985.
Prior to r365985, clang used to mark C union fields that have
non-trivial ObjC ownership qualifiers as unavailable if the union was
declared in a system header. r365985 stopped doing so, which caused the
swift compiler to crash when it tried to import a non-trivial union.
I have a patch that fixes the crash (https://reviews.llvm.org/D65256),
but I'm temporarily reverting the original patch until we can decide on
whether it's taking the right approach.
llvm-svn: 367076
non-trivial C union types
This patch diagnoses uses of non-trivial C unions and structs/unions
containing non-trivial C unions in the following contexts, which require
default-initialization, destruction, or copying of the union objects,
instead of disallowing fields of non-trivial types in C unions, which is
what we currently do:
- function parameters.
- function returns.
- assignments.
- compound literals.
- block captures except capturing of `__block` variables by non-escaping
blocks.
- local and global variable definitions.
- lvalue-to-rvalue conversions of volatile types.
See the discussion in https://reviews.llvm.org/D62988 for more background.
rdar://problem/50679094
Differential Revision: https://reviews.llvm.org/D63753
llvm-svn: 365985
This reverts r365382 (git commit 8b1becf2e3)
Appears to regress this semi-reduced fragment of valid code from windows
SDK headers:
#define InterlockedIncrement64 _InterlockedIncrement64
extern "C" __int64 InterlockedIncrement64(__int64 volatile *Addend);
#pragma intrinsic(_InterlockedIncrement64)
unsigned __int64 InterlockedIncrement(unsigned __int64 volatile *Addend) {
return (unsigned __int64)(InterlockedIncrement64)((volatile __int64 *)Addend);
}
Found on a buildbot here, but no mail was sent due to it already being
red:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/48067
llvm-svn: 365393
If the type didn't exist, we used to emit a really bad error:
t.m:3:12: error: expected ')'
-(nullable NoSuchType)foo3;
^
rdar://50925632
llvm-svn: 364489
Swift requires certain classes to be not just initialized lazily on first
use, but actually allocated lazily using information that is only available
at runtime. This is incompatible with ObjC class initialization, or at least
not efficiently compatible, because there is no meaningful class symbol
that can be put in a class-ref variable at load time. This leaves ObjC
code unable to access such classes, which is undesirable.
objc_class_stub says that class references should be resolved by calling
a new ObjC runtime function with a pointer to a new "class stub" structure.
Non-ObjC compilers (like Swift) can simply emit this structure when ObjC
interop is required for a class that cannot be statically allocated,
then apply this attribute to the `@interface` in the generated ObjC header
for the class.
This attribute can be thought of as a generalization of the existing
`objc_runtime_visible` attribute which permits more efficient class
resolution as well as supporting the additon of categories to the class.
Subclassing these classes from ObjC is currently not allowed.
Patch by Slava Pestov!
llvm-svn: 362054
Nullability attributes weren't being stripped for AttributedTypes that
were wrapped in a MacroQualifiedType. This fix adds a check for this
type and a test.
llvm-svn: 361205
The warning isn't very useful when the function is an ObjC method.
rdar://problem/41561853
Differential Revision: https://reviews.llvm.org/D61147
llvm-svn: 359864
If an address_space attribute is defined in a macro, print the macro instead
when diagnosing a warning or error for incompatible pointers with different
address_spaces.
We allow this for all attributes (not just address_space), and for multiple
attributes declared in the same macro.
Differential Revision: https://reviews.llvm.org/D51329
llvm-svn: 359826
We correct some typos in `ActOnArraySubscriptExpr` and
`ActOnOMPArraySectionExpr`, so when their result is `ExprError`, we can
end up correcting delayed typos in the same expressions again. In
general it is OK but when `NumTypos` is incorrect, we can hit the
assertion
> Assertion failed: (Entry != DelayedTypos.end() && "Failed to get the state for a TypoExpr!"), function getTypoExprState, file clang/lib/Sema/SemaLookup.cpp, line 5219.
Fix by replacing some subscript `ExprResult` with typo-corrected expressions
instead of keeping the original expressions. Thus if original expressions
contained `TypoExpr`, we'll use corrected expressions instead of trying to
correct them again.
rdar://problem/47403222
Reviewers: rsmith, erik.pilkington, majnemer
Reviewed By: erik.pilkington
Subscribers: jkorous, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D60848
llvm-svn: 359713
of an auto"
This commit changed the initializer expression passed into
initialization (stripping off an enclosing pair of parentheses or
braces) and subtly changing the meaning of programs, typically by
inserting bogus calls to copy constructors.
See the added testcase in test/SemaCXX/cxx1y-init-captures.cpp for an
example of the breakage.
llvm-svn: 359066
retaining block and all of the enclosing blocks are non-escaping.
If the block implicitly retaining self doesn't escape, there is no risk
of creating retain cycles, so clang shouldn't diagnose it and force
users to add self-> to silence the diagnostic.
Also, fix a bug where clang was failing to diagnose an implicitly
retained self inside a c++ lambda nested inside a block.
rdar://problem/25059955
Differential Revision: https://reviews.llvm.org/D60736
llvm-svn: 358624
We want to make objc_nonlazy_class apply to implementations, but ran into this.
There doesn't seem to be any reason that this isn't supported.
Differential revision: https://reviews.llvm.org/D60542
llvm-svn: 358200
This test was duplicated, and the last declaration had some syntax errors since
the invalid attribute caused the @implementation to be skipped by the parser.
llvm-svn: 358136
moveAttrFromListToList only makes sense when moving an attribute to a list with
a pool that's either equivalent, or has a shorter lifetime. Therefore, using it
to move a ParsedAttr from a declarator to a declaration specifier doesn't make
sense, since the declaration specifier's pool outlives the declarator's. The
patch adds a new function, ParsedAttributes::takeOneFrom, which transfers the
attribute from one pool to another, fixing the use-after-deallocate.
rdar://49175426
Differential revision: https://reviews.llvm.org/D60101
llvm-svn: 357516
We were allocating the implicit attribute in the declarator's attribute pool,
but putting into the declaration specifier's ParsedAttributesView. If there are
multiple declarators, then we'll use the attribute from the declaration
specifier after clearing out the declarators attribute pool. Fix this by
allocating the attribute in the declaration specifier's pool.
rdar://48529718
Differential revision: https://reviews.llvm.org/D59327
llvm-svn: 356187
expression inside the parentheses is a valid UTF-8 string literal.
Previously clang emitted an expression like @("abc") as a message send
to stringWithUTF8String. This commit makes clang emit the boxed
expression as a compile-time constant instead.
This commit also has the effect of silencing the nullable-to-nonnull
conversion warning clang started emitting after r317727, which
originally motivated this commit (see https://oleb.net/2018/@keypath).
rdar://problem/42684601
Differential Revision: https://reviews.llvm.org/D58729
llvm-svn: 355662
declaring an unavailable method in the subclass's extension that
overrides the designated initializer in the base class.
r243676 made changes to allow declaring the unavailable method in the
subclass interface to silence the warning. This commit additionally
allows declaring the unavailable method in the class extension.
rdar://problem/42731306
llvm-svn: 355175
Fixes the warning about incompatible pointer types on assigning to a
subclass of type argument an expression of type `__kindof TypeParam`.
We already have a mechanism in `ASTContext::canAssignObjCInterfaces`
that handles `ObjCObjectType` with `__kindof`. But it wasn't triggered
because during type substitution `__kindof TypeParam` was represented as
`AttributedType` with attribute `ObjCKindOf` and equivalent type
`TypeArg`. For assignment type checking we use canonical types so
attributed type was desugared and the attribute was ignored.
The fix is in checking transformed `AttributedType` and pushing
`__kindof` down into `ObjCObjectType` when necessary.
rdar://problem/38514910
Reviewers: ahatanak, erik.pilkington, doug.gregor
Reviewed By: doug.gregor
Subscribers: jkorous, dexonsmith, manmanren, jordan_rose, doug.gregor, cfe-commits
Differential Revision: https://reviews.llvm.org/D57076
llvm-svn: 354189
`QualType::substObjCTypeArgs` doesn't go past non-canonical types and as
the result misses some of the substitutions like `ObjCTypeParamType`.
Update `SimpleTransformVisitor` to traverse past the type sugar.
Reviewers: ahatanak, erik.pilkington
Reviewed By: erik.pilkington
Subscribers: jkorous, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D57270
llvm-svn: 354164
We were warning on valid ObjC property reference exprs, and passing
in the wrong arguments to DiagnoseFloatingImpCast (leading to a badly
worded diagnostic).
rdar://47644670
Differential revision: https://reviews.llvm.org/D58145
llvm-svn: 354074
This fixes a regression that was caused by r335084, which reversed
the order that attributes are applied. objc_method_family can change
whether a method is an init method, so the order that these
attributes are applied matters. The commit fixes this by delaying the
init check until after all attributes have been applied.
rdar://47829358
Differential revision: https://reviews.llvm.org/D58152
llvm-svn: 353976
This patch fixes a bug where clang doesn’t reject union fields of
non-trivial C struct types. For example:
```
// This struct is non-trivial under ARC.
struct S0 {
id x;
};
union U0 {
struct S0 s0; // clang should reject this.
struct S0 s1; // clang should reject this.
};
void test(union U0 a) {
// Previously, both 'a.s0.x' and 'a.s1.x' were released in this
// function.
}
```
rdar://problem/46677858
Differential Revision: https://reviews.llvm.org/D55659
llvm-svn: 353459
A non-lazy class will be initialized eagerly when the Objective-C runtime is
loaded. This is required for certain system classes which have instances allocated in
non-standard ways, such as the classes for blocks and constant strings.
Adding this attribute is essentially equivalent to providing a trivial
+load method but avoids the (fairly small) load-time overheads associated
with defining and calling such a method.
Differential Revision: https://reviews.llvm.org/D56555
llvm-svn: 353116
attributes from declaration over attributes from '#pragma clang attribute'
Before this commit users had an issue when using #pragma clang attribute with
availability attributes:
The explicit attribute that's specified next to the declaration is not
guaranteed to be preferred over the attribute specified in the pragma.
This commit fixes this by introducing a priority field to the availability
attribute to control how they're merged. Attributes with higher priority are
applied over attributes with lower priority for the same platform. The
implicitly inferred attributes are given the lower priority. This ensures that:
- explicit attributes are preferred over all other attributes.
- implicitly inferred attributes that are inferred from an explicit attribute
are discarded if there's an explicit attribute or an attribute specified
using a #pragma for the same platform.
- implicitly inferred attributes that are inferred from an attribute in the
#pragma are not used if there's an explicit, explicit #pragma, or an
implicit attribute inferred from an explicit attribute for the declaration.
This is the resulting ranking:
`platform availability > platform availability from pragma > inferred availability > inferred availability from pragma`
rdar://46390243
Differential Revision: https://reviews.llvm.org/D56892
llvm-svn: 352084
declared in a parent class from within the @implementation context
This commit extends r350768 and allows the use of methods marked as unavailable
that are declared in a parent class/category from within the @implementation of
the class where the method is marked as unavailable.
This allows users to call init that's marked as unavailable even if they don't
define it.
rdar://47134898
Differential Revision: https://reviews.llvm.org/D56816
llvm-svn: 351459
Mention the deployment target, and don't say "partial" which doesn't
really mean anything to users.
rdar://problem/33601513
Differential revision: https://reviews.llvm.org/D56523
llvm-svn: 351108
variable during auto type deduction, use the rewritten initializer when
performing initialization of the variable.
This silences spurious -Warc-repeated-use-of-weak warnings that are
issued when the initializer uses a weak ObjC pointer.
Differential Revision: https://reviews.llvm.org/D55662
llvm-svn: 350917
placeholder expressions while an unevaluated context is still on the
expression evaluation context stack.
This prevents recordUseOfWeek from being called when a weak variable is
used as an operand of a decltype or a typeof expression and fixes
spurious -Warc-repeated-use-of-weak warnings.
rdar://problem/45742525
Differential Revision: https://reviews.llvm.org/D55662
llvm-svn: 350887
the @implementation context
In Objective-C, it's common for some frameworks to mark some methods like init
as unavailable in the @interface to prohibit their usage. However, these
frameworks then often implemented said method and refer to it in another method
that acts as a factory for that object. The recent change to how messages to
self are type checked in clang (r349841) introduced a regression which started
to prohibit this pattern with an X is unavailable error. This commit addresses
the aforementioned regression.
rdar://47134898
Differential Revision: https://reviews.llvm.org/D56469
llvm-svn: 350768
This attribute, called "objc_externally_retained", exposes clang's
notion of pseudo-__strong variables in ARC. Pseudo-strong variables
"borrow" their initializer, meaning that they don't retain/release
it, instead assuming that someone else is keeping their value alive.
If a function is annotated with this attribute, implicitly strong
parameters of that function aren't implicitly retained/released in
the function body, and are implicitly const. This is useful to expose
for performance reasons, most functions don't need the extra safety
of the retain/release, so programmers can opt out as needed.
This attribute can also apply to declarations of local variables,
with similar effect.
Differential revision: https://reviews.llvm.org/D55865
llvm-svn: 350422
use the pointer to the class as the result type of the message
Prior to this commit, messages to self in class methods were treated as instance
methods to a Class value. When these methods returned instancetype the compiler
only saw id through the instancetype, and not the Interface *. This caused
problems when that return value was a receiver in a message send, as the
compiler couldn't select the right method declaration and had to rely on a
selection from the global method pool.
This commit modifies the semantics of such message sends and uses class messages
that are dispatched to the interface that corresponds to the class that contains
the class method. This ensures that instancetypes are correctly interpreted by
the compiler. This change is safe under ARC (as self can't be reassigned),
however, it also applies to MRR code as we are assuming that the user isn't
doing anything unreasonable.
rdar://20940997
Differential Revision: https://reviews.llvm.org/D36790
llvm-svn: 349841
This moves everything primarily testing the functionality of -ast-dump and -ast-print into their own directory, rather than leaving the tests spread around the testing directory.
llvm-svn: 348017
A mask type is a 1 to 8-byte string that follows the "mask." annotation
in the format string. This enables obfuscating data in the event the
provided privacy level isn't enabled.
rdar://problem/36756282
llvm-svn: 346211
Previously we supported these in C++, ObjC, and C with -fms-extensions.
rdar://43831380
Differential revision: https://reviews.llvm.org/D52339
llvm-svn: 343360
When defined in NSObject, +new will call -init. If -init has been marked
unavailable, diagnose uses of +new.
rdar://18335828
Differential revision: https://reviews.llvm.org/D51189
llvm-svn: 341874
This is a warning about using 'assign' instead of 'unsafe_unretained'
in Objective-C property declarations. It's off by default because there
isn't consensus in the Objective-C steering group that this is the right
thing to do, but we're nonetheless okay with adding it because there's a
substantial pool of Objective-C programmers who will appreciate the warning.
Patch by Alfred Zien!
llvm-svn: 341489
Volodymyr Sapsai