[PATCH] Fix return type deduction for member templates

[Faisalv]

Sent from my iPhone

On Jun 13, 2013, at 7:36 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Thu, Jun 13, 2013 at 3:40 PM, Faisalv <faisalv at gmail.com> wrote:
>> 
>> 
>> On Jun 13, 2013, at 4:30 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>> 
>>> Hi Faisal,
>>> 
>>> On Thu, Jun 13, 2013 at 11:30 AM, Faisal Vali <faisalv at gmail.com> 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?