[Patch][ObjC][Proposal] NSValue literals

[jahanian]

Looks like there is policy to not issue diagnostics on not yet introduced methods
(grep for AR_NotYetIntroduced in clang). So you need to handle this 
yourself by making the call to Decl::getAvailability.
- Fariborz

On Dec 13, 2014, at 10:08 AM, AlexDenisov <1101.debian at gmail.com> wrote:

> Well, I started implementation of warnings regarding availability and faced with an issue:
> I decided to check how clang behaves and what kind of diagnostics it shows in that situation, 
> but I've found that clang just compiles the code without any warnings.
> 
> I've run this command:
> 
> clang main.m -fsyntax-only -fmodules -Weverything
> 
> with this code:
> 
> //main.m
> @import Foundation;
> 
> @interface Future : NSObject
> + (instancetype)newFuture __attribute__((availability(macosx,introduced=10.10)));
> @end
> 
> @implementation Future
> + (instancetype)newFuture { return nil; }
> @end
> 
> int main(int argc, const char * argv[]) {
>   Future *f = [Future newFuture];
>   return f == nil;
> }
> 
> And everything was just fine (excerpt of unused variables argc/argv).
> 
> So the question is: what is expected behaviour regarding boxed expressions and availability?
> I can’t even find such tests for NSNumber/NSString.
> 
> I would appreciate any suggestions or advice.
> 
> Best regards, Alex.
> -- 
> AlexDenisov
> Software Engineer, https://github.com/AlexDenisov
> 
> On 11 Dec 2014 at 22:12:06, AlexDenisov (1101.debian at gmail.com) wrote:
> 
>> > there is a good chance we won’t be adding boxing of pointers. 
>> 
>> Do you mean pointers to void (valueWithPointer) or all the pointers, like NSObject * (valueWithNonretainedObject)?
>> 
>> Anyway, should I get rid of that functionality before submitting updated patch or keep it and, probably, drop later?
>> 
>> -- 
>> AlexDenisov
>> Software Engineer, https://github.com/AlexDenisov
>> 
>> On 10 Dec 2014 at 23:00:38, jahanian (fjahanian at apple.com) wrote:
>> 
>>> 
>>>> On Dec 9, 2014, at 12:21 AM, AlexDenisov <1101.debian at gmail.com> wrote:
>>>> 
>>>> 
>>>> >> Also, why can’t place this under the umbrella objc_boxed_expressions?
>>>> 
>>>> Version 3.5, for example, supports objc_boxed_expression but not NSValue+boxed_expressions, 
>>>> which might cause weird compilation fails. Or did I get it wrong?
>>> No wrong :).
>>> 
>>>> 
>>>> +        // Otherwise, require a declaration of NSValue.
>>>> +        S.Diag(Loc, diag::err_undeclared_nsvalue);
>>>> +        return nullptr;
>>>> +      }
>>>> +    } else if (!S.NSValueDecl->hasDefinition()) {
>>>> +      S.Diag(Loc, diag::err_undeclared_nsvalue);
>>>> 
>>>> >> Maybe we should have a clearer diagnostic here.
>>>> 
>>>> Makes sense, I used NSNumber' implementation here. I'd appreciate any suggestions or advice on 
>>>> how to improve diagnostic here (and, probably, for NSNumber)
>>> 
>>> Probably should allude to NSValue (or NSNumber) having no definition (only forward declared).  
>>> But, it is not something I strongly argue for.
>>> 
>>> P.S. there is a good chance we won’t be adding boxing of pointers. 
>>> 
>>> Thanks, Fairborz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141215/e33e9183/attachment.html>