[PATCH] Fix return type deduction for member templates (revised)

[Faisal Vali]

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.

thank you!

Faisal Vali



On Thu, Jun 13, 2013 at 7:38 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Thu, Jun 13, 2013 at 5:11 PM, Faisalv <faisalv at gmail.com> 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 <faisalv at gmail.com> wrote:
>>
>>>
>>>
>>> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-return-type-deduction-for-member-templates-2.patch
Type: application/octet-stream
Size: 3443 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130614/fd1c6610/attachment.obj>