summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaObjC
Commit message (Collapse)AuthorAgeFilesLines
...
* Don't define __has_feature(objc_fixed_enum) in non-objc modeErik Pilkington2019-01-301-0/+2
| | | | | | | This is only a formal language feature in ObjC, otherwise its just an extension. Making this change was also an ABI break. llvm-svn: 352672
* Add a priority field to availability attributes to prioritize explicitAlex Lorenz2019-01-241-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ObjC] Follow-up r350768 and allow the use of unavailable methods that areAlex Lorenz2019-01-172-4/+22
| | | | | | | | | | | | | | | | 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
* Improve a -Wunguarded-availability noteErik Pilkington2019-01-144-36/+37
| | | | | | | | | | | 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
* [Sema] If CheckPlaceholderExpr rewrites the initializer of an autoAkira Hatanaka2019-01-111-2/+14
| | | | | | | | | | | | 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
* [Sema] Call CheckPlaceholderExpr to resolve typeof or decltypeAkira Hatanaka2019-01-101-0/+3
| | | | | | | | | | | | | | | 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
* [ObjC] Allow the use of implemented unavailable methods from withinAlex Lorenz2019-01-091-0/+68
| | | | | | | | | | | | | | | | | | 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
* [ObjCARC] Add an new attribute, objc_externally_retainedErik Pilkington2019-01-042-0/+121
| | | | | | | | | | | | | | | | | | | | 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
* [ObjC] Messages to 'self' in class methods that return 'instancetype' shouldAlex Lorenz2018-12-201-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Generate objc intrinsics instead of runtime calls as the ARC optimizer now ↵Pete Cooper2018-12-181-7/+7
| | | | | | | | | works only on intrinsics Differential Revision: https://reviews.llvm.org/D55802 Reviewers: rjmccall llvm-svn: 349535
* Move AST tests into their own test directory; NFC.Aaron Ballman2018-11-305-125/+0
| | | | | | 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
* os_log: Allow specifying mask type in format string.Akira Hatanaka2018-11-061-0/+4
| | | | | | | | | | 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
* Support enums with a fixed underlying type in all language modes.Erik Pilkington2018-09-281-0/+5
| | | | | | | | | | Previously we supported these in C++, ObjC, and C with -fms-extensions. rdar://43831380 Differential revision: https://reviews.llvm.org/D52339 llvm-svn: 343360
* [Sema][ObjC] Infer availability of +new from availability of -init.Erik Pilkington2018-09-101-0/+58
| | | | | | | | | | | 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
* Add -Wobjc-property-assign-on-object-type.John McCall2018-09-052-2/+21
| | | | | | | | | | | | 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
* [ObjC] Error out when using forward-declared protocol in a @protocolAlex Lorenz2018-08-171-3/+3
| | | | | | | | | | | | | | | | | | | | | | expression Clang emits invalid protocol metadata when a @protocol expression is used with a forward-declared protocol. The protocol metadata is missing protocol conformance list of the protocol since we don't have access to the definition of it in the compiled translation unit. The linker then might end up picking the invalid metadata when linking which will lead to incorrect runtime protocol conformance checks. This commit makes sure that Clang fails to compile code that uses a @protocol expression with a forward-declared protocol. This ensures that Clang does not emit invalid protocol metadata. I added an extra assert in CodeGen to ensure that this kind of issue won't happen in other places. rdar://32787811 Differential Revision: https://reviews.llvm.org/D49462 llvm-svn: 340102
* Clean up and simplify RequireCompleteType.Richard Smith2018-08-071-1/+1
| | | | | | | No functional change intended, except that we will now produce more "declared here" notes. llvm-svn: 339187
* Append new attributes to the end of an AttributeList.Michael Kruse2018-08-031-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit of r335084 after revert in r335516. ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse order, and therefore printed in the wrong order in -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effect, especially on diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attributes' order was changed instead. This unfortunately causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible to each other. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reverse. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 338800
* [Sema][ObjC] Do not propagate the nullability specifier on the receiverAkira Hatanaka2018-07-261-0/+11
| | | | | | | | | | | | | | | | | | to the result type of a message send if the result type cannot have a nullability specifier. Previously, clang would print the following message when the code in nullability.m was compiled: "incompatible integer to pointer conversion initializing 'int *' with an expression of type 'int _Nullable'" This is wrong as 'int' isn't supposed to have any nullability specifiers. rdar://problem/40830514 llvm-svn: 338048
* [Sema] Emit -Wincomplete-implementation for partial methods.Erik Pilkington2018-07-071-0/+7
| | | | | | Fixes rdar://40634455 llvm-svn: 336478
* [Sema] -Wformat-pedantic only for NSInteger/NSUInteger %tu/%td on DarwinAlex Lorenz2018-07-051-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The '%tu'/'%td' as formatting specifiers have been used to print out the NSInteger/NSUInteger values for a long time. Typically their ABI matches, but that's not the case on watchOS. The ABI difference boils down to the following: - Regular 32-bit darwin targets (like armv7) use 'ptrdiff_t' of type 'int', which matches 'NSInteger'. - WatchOS arm target (armv7k) uses 'ptrdiff_t' of type 'long', which doesn't match 'NSInteger' of type 'int'. Because of this ABI difference these specifiers trigger -Wformat warnings only for watchOS builds, which is really inconvenient for cross-platform code. This patch avoids this -Wformat warning for '%tu'/'%td' and NS[U]Integer only, and instead uses the new -Wformat-pedantic warning that JF introduced in https://reviews.llvm.org/D47290. This is acceptable because Darwin guarantees that, despite the watchOS ABI differences, sizeof(ptrdiff_t) == sizeof(NS[U]Integer), and alignof(ptrdiff_t) == alignof(NS[U]Integer) so the warning is therefore noisy for pedantic reasons. I'll update public documentation to ensure that this behaviour is properly communicated. rdar://41739204 Differential Revision: https://reviews.llvm.org/D48852 llvm-svn: 336396
* [Sema] -Wformat-pedantic only for NSInteger/NSUInteger %zu/%zi on DarwinJF Bastien2018-06-221-0/+30
| | | | | | | | | | | | | | | | | | | | | | | Summary: Pick D42933 back up, and make NSInteger/NSUInteger with %zu/%zi specifiers on Darwin warn only in pedantic mode. The default -Wformat recently started warning for the following code because of the added support for analysis for the '%zi' specifier. NSInteger i = NSIntegerMax; NSLog(@"max NSInteger = %zi", i); The problem is that on armv7 %zi is 'long', and NSInteger is typedefed to 'int' in Foundation. We should avoid this warning as it's inconvenient to our users: it's target specific (happens only on armv7 and not arm64), and breaks their existing code. We should also silence the warning for the '%zu' specifier to ensure consistency. This is acceptable because Darwin guarantees that, despite the unfortunate choice of typedef, sizeof(size_t) == sizeof(NS[U]Integer), the warning is therefore noisy for pedantic reasons. Once this is in I'll update public documentation. Related discussion on cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058050.html <rdar://36874921&40501559> Reviewers: ahatanak, vsapsai, alexshap, aaron.ballman, javed.absar, jfb, rjmccall Subscribers: kristof.beyls, aheejin, cfe-commits Differential Revision: https://reviews.llvm.org/D47290 llvm-svn: 335393
* Reapply "[Parse] Use CapturedStmt for @finally on MSVC"Shoaib Meenai2018-06-082-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies r334224 and adds explicit triples to some tests to fix them on Windows (where otherwise they would have run with the default windows-msvc triple, which I'm changing the behavior for). Original commit message: 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: 334251
* Revert "[Parse] Use CapturedStmt for @finally on MSVC"Shoaib Meenai2018-06-071-14/+0
| | | | | | | | | | 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
* [Parse] Use CapturedStmt for @finally on MSVCShoaib Meenai2018-06-071-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Check pointer null-ness before dereferencing it.Richard Trieu2018-05-291-0/+3
| | | | | | | | -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
* [Sema][ObjC] Do not DiagnoseUseOfDecl in LookupMemberExprSteven Wu2018-05-241-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Sema: diagnose invalid catch parameter in ObjCSaleem Abdulrasool2018-05-201-0/+9
| | | | | | | | | Ensure that the type being used has an associated interface when declaring the parameter for `@catch`. Resolves PR37384! llvm-svn: 332821
* Use dotted format of version tuple for availability diagnosticsJan Korous2018-05-171-2/+2
| | | | | | | | | | | | 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
* Remove the fixit for the diagnostics regarding capturing autoreleasing ↵George Karpenkov2018-05-141-13/+7
| | | | | | | | | | | | | | | variables in a block 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
* [ObjC] Supress the 'implementing unavailable method' warning whenAlex Lorenz2018-05-031-0/+24
| | | | | | | | | | | | | 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
* [ObjC] The absence of ownership qualifiers on an ambiguous property leadsAlex Lorenz2018-05-021-0/+35
| | | | | | | | | to synthesis of a valid property even when the selected protocol property has ownership qualifiers rdar://39024725 llvm-svn: 331409
* [Sema] Warn about memcpy'ing non-trivial C structs.Akira Hatanaka2018-04-171-0/+39
| | | | | | | | | | | 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
* Remove GC-related warning terminologyDuncan P. N. Exon Smith2018-04-172-2/+2
| | | | | | | | ObjC-GC isn't used any more; clean up this warning text. rdar://problem/39049693 llvm-svn: 330174
* [Availability] Improve availability to consider functions run at load timeSteven Wu2018-04-161-1/+43
| | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[ObjC] Make C++ triviality type traits available to non-trivial C"Akira Hatanaka2018-04-091-32/+0
| | | | | | | | | | | | | This reverts commit r329289. It was decided that we shouldn't expose the __has_* traits to C since they are deprecated and useless. See the discussion here: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180402/thread.html#223921 llvm-svn: 329608
* Allow equality comparisons between block pointers andJohn McCall2018-04-071-0/+51
| | | | | | | | block-pointer-compatible ObjC object pointer types. Patch by Dustin Howett! llvm-svn: 329508
* Fix typos in clangAlexander Kornienko2018-04-063-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove the temporary availability checking workaround forAlex Lorenz2018-04-051-2/+2
| | | | | | | | the nested declarations in @interface. rdar://28825862 llvm-svn: 329324
* [ObjC] Make C++ triviality type traits available to non-trivial CAkira Hatanaka2018-04-051-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r328680 ("[ObjC] Make C++ triviality type traits available to ↵Richard Smith2018-04-051-25/+0
| | | | | | | | | non-trivial C structs.") It unintentionally caused the values of the __has_* type traits to change in C++ for trivially-copyable classes with volatile members. llvm-svn: 329247
* [Sema] Make deprecation fix-it replace all multi-parameter ObjC method slots.Volodymyr Sapsai2018-03-291-0/+177
| | | | | | | | | | | | | | | | | | 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
* [ast] Do not auto-initialize Objective-C for-loop variables in Objective-C++ ↵George Karpenkov2018-03-291-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in templatized code under ARC 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
* Fix some handling of AST nodes with diagnostics.Richard Trieu2018-03-282-4/+4
| | | | | | | | | 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
* [ObjC] Make C++ triviality type traits available to non-trivial CAkira Hatanaka2018-03-281-0/+25
| | | | | | | | | | | | | | | | | | | | | | 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
* [Sema] Emit -Winteger-overflow for arguments in function calls, ObjC messages.Volodymyr Sapsai2018-03-271-0/+18
| | | | | | | | | | | | | | rdar://problem/35539384 Reviewers: ahatanak, nicholas, rsmith, jkorous-apple Reviewed By: jkorous-apple Subscribers: cfe-commits, jkorous-apple Differential Revision: https://reviews.llvm.org/D42938 llvm-svn: 328671
* [Sema] Avoid crash for category implementation without interfaceShoaib Meenai2018-03-271-0/+9
| | | | | | | | | | | 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
* [ObjC] Allow declaring __strong pointer fields in structs in Objective-CAkira Hatanaka2018-02-283-7/+61
| | | | | | | | | | | | | | | | | | | | | 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
* [Sema][ObjC] Process category attributes before checking protocol usesAlex Lorenz2018-02-231-0/+18
| | | | | | | | | 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
* [Sema][ObjC] Use SmallSetVector to fix a failing test on the reverseAkira Hatanaka2018-02-061-0/+22
| | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud