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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
