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 ([email protected]) 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 ([email protected]) wrote:


On Dec 9, 2014, at 12:21 AM, AlexDenisov <[email protected]> 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



_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to