On Fri, Jun 14, 2013 at 5:40 AM, Faisal Vali <[email protected]> wrote: > Hi Richard, > please let me know if you're ok with me committing the attached patch with > the following log: > A quick fix to allow return type deduction on member templates > by ensuring DiagnoseUseOfDecl is called both on the found decl and the > decl being used > (i.e the specialization in the case of member templates) whenever they > are different. > Per the exchange captured in > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130610/081636.html > a more comprehensive fix that allows both decls to be passed > into DiagnoseUseOfDecl is (or should be) forthcoming relatively soon.
Yes, this is fine. > Faisal Vali > > > > On Thu, Jun 13, 2013 at 7:38 PM, Richard Smith <[email protected]> wrote: >> On Thu, Jun 13, 2013 at 5:11 PM, Faisalv <[email protected]> wrote: >>> Also can i just check if the founddecl and the decl being used are >>> different - and if so, call diagnoseusedecl on both - or does one have to >>> be a specialization of the other? (do u have an example in mind where it is >>> not a specilaization) >> >> It should be fine to call DiagnoseUseOfDecl on both if they're >> different; they're both "used" in some sense. >> >>> On Jun 13, 2013, at 8:03 PM, Faisalv <[email protected]> wrote: >>> >>>> >>>> >>>> Sent from my iPhone >>>> >>>> On Jun 13, 2013, at 7:36 PM, Richard Smith <[email protected]> wrote: >>>> >>>>> On Thu, Jun 13, 2013 at 3:40 PM, Faisalv <[email protected]> wrote: >>>>>> >>>>>> >>>>>> On Jun 13, 2013, at 4:30 PM, Richard Smith <[email protected]> wrote: >>>>>> >>>>>>> Hi Faisal, >>>>>>> >>>>>>> On Thu, Jun 13, 2013 at 11:30 AM, Faisal Vali <[email protected]> wrote: >>>>>>>> While implementing return type deduction for generic lambdas, I >>>>>>>> stumbled upon >>>>>>>> a bug which led to clang mishandling the following code: >>>>>>>> >>>>>>>> struct Lambda { >>>>>>>> template<class T> auto operator()(T t) { >>>>>>>> return 5; >>>>>>>> } >>>>>>>> template<class T> auto foo(T t) { return t; } >>>>>>>> }; >>>>>>>> void test() { >>>>>>>> Lambda L; >>>>>>>> int i = L(3); >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> The issue (as i understand it) was that in some contexts only the >>>>>>>> function template (and not the specialization) would get passed to >>>>>>>> DiagnoseUseOfDecl (which deduces the return type of the function). So >>>>>>>> the specialization would flow through to Codegen with auto as its >>>>>>>> return type. >>>>>>>> >>>>>>>> So, with that in mind, this patch implements a trivial fix. >>>>>>>> >>>>>>>> What do you think Richard? Is there a better way to address this bug? >>>>>>> >>>>>>> I was aware of this issue, but got snowed under with other things. >>>>>>> This bug is not limited to 'auto' type deduction; the other code in >>>>>>> DiagnoseUseOfDecl suffers the same way. For instance: >>>>>>> >>>>>>> struct Lambda { >>>>>>> template<class T> static __attribute__((unused)) int foo(T) { >>>>>>> return 5; >>>>>>> } >>>>>>> }; >>>>>>> int bar() { >>>>>>> Lambda L; >>>>>>> return L.foo(3); >>>>>>> } >>>>>>> >>>>>>> ... does not warn that the function is marked 'unused' but is used, >>>>>>> but if you call it as Lambda::foo(3), it does warn. >>>>>>> >>>>>>> I think the right fix here is to pass both the declaration found by >>>>>>> name lookup and the declaration that is actually used into >>>>>>> DiagnoseUseOfDecl. >>>>>>> >>>>>> >>>>>> What if i just call diagnoseuseofdecl again on the used specialization >>>>>> instead of adding a parameter to it? >>>>> >>>>> If this is the only call which has the problem, then that would be OK. >>>>> I suspect there are other cases, though, and there are probably cases >>>>> which have the opposite bug (passing only the used decl and not the >>>>> found decl). As a quick fix, making two calls would work, but it's >>>>> probably not what we want in the longer term. >>>> >>>> >>>> If its ok w u, for now id rather do the quick fix, place the appropriate >>>> fixmes - and then try and return to this once generic lambdas are starting >>>> to be reasonably usable (plus i still have to figure out that pesky >>>> non-odr use, rvalue emission issue - which also i'm going to deprioritize >>>> a lil in favor of usable generic lambdas for now). Thoughts? _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
