[Patch][ObjC][Proposal] NSValue literals

[AlexDenisov]

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 
Well, I understand this part, it’s pretty obvious. But what I don’t understand is:

issue an appropriate diagnostic.
What is appropriate diagnostic for AR_NotYetIntroduced?

Should I introduce this diagnostic? Or just show warning/error for Deprecated/Unavailable and ignore NotYetIntroduced AR?

Please, take my apologies for annoying questions.
-- 
AlexDenisov
Software Engineer, https://github.com/AlexDenisov

On 24 Dec 2014 at 00:13:12, jahanian (fjahanian at apple.com) wrote:


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/20141224/de4341cd/attachment.html>