On Dec 22, 2014, at 1:33 PM, AlexDenisov <[email protected]> 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 ([email protected]) wrote: > >> >> 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
