On Dec 18, 2014, at 10:28 AM, AlexDenisov <[email protected]> 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 ([email protected]) 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 <[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
