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