[Patch][ObjC][Proposal] NSValue literals

[jahanian]

On Dec 22, 2014, at 1:33 PM, AlexDenisov <1101.debian at gmail.com> wrote:

> Sorry, but I completely stuck.
>> After you look up the method to use, you should call the getAvailability() on it and if it is unavailable or 
>> not yet introduced, you should issue an appropriate diagnostic (error).
> 
> But
> 
>> Looks like there is policy to not issue diagnostics on not yet introduced methods (grep for AR_NotYetIntroduced in clang).
> 
> Could you, please, describe the expected behaviour more precisely? Thank you.
> 
> 

Do the usual lookup to find the method which implements this syntax. Call Decl::getAvailability on this method. If it returns
anything other than AvailabilityResult::AR_Available issue an appropriate diagnostic. But continue generating
the AST so there will be a valid AST.

- Fariborz


> -- 
> AlexDenisov
> Software Engineer, https://github.com/AlexDenisov
> 
> On 19 Dec 2014 at 18:26:47, jahanian (fjahanian at apple.com) wrote:
> 
>> 
>> On Dec 18, 2014, at 10:28 AM, AlexDenisov <1101.debian at gmail.com> wrote:
>> 
>>> Ok, I got it, but still can’t understand what is desired behaviour? How should compiler behave in this situation?
>>> I tried to find any related functionality at NSNumber/NSString implementation - but, no luck.
>> 
>> After you look up the method to use, you should call the getAvailability() on it and if it is unavailable or 
>> not yet introduced, you should issue an appropriate diagnostic (error). But you probably want to 
>> continue producing the AST, etc. so to cut down on any followup errors which might show up.
>> - Fariborz
>> 
>>> 
>>> P.S. also I’ve found that a few tests are missing and some literals-related diagnostic are weird, so a few patches are coming.
>>> -- 
>>> AlexDenisov
>>> Software Engineer, https://github.com/AlexDenisov
>>> 
>>> On 15 Dec 2014 at 19:59:01, jahanian (fjahanian at apple.com) wrote:
>>> 
>>>> 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/20141223/dcdc9f29/attachment.html>