[Patch] BUG 19551 explicit instantiation confusion for a function with a deduced return type already been instantiated

[Richard Smith]

On Thu, May 8, 2014 at 2:20 PM, suyog sarda <sardask01 at gmail.com> wrote:

> Thanks Richard for your review.
>
> Just to be sure, clarifying things. In our test case :
>
> *template<typename T> auto f(T) { return 0; }   // Line 1*
> *int k = f(0); // Line 2*
> *template auto f(int); // Line 3*
> *template int f(int); // Line 4*
>
> Do you mean that we should compare the declared return type i.e return
> type declared in
> template declaration (i.e the line 1) with declared return type in
> explicit instantiation(line 3)?
> And those we will get from type source info for both ?
>

What I mean is, we should compare the return type in the type source info
(getTypeSourceInfo) not the return type in the type (getType) of the
function. The former should have 'auto' in it, the latter will have an
actual type. The types in the type source info should be the same; the
types in the declaration might not be.


> Also is this the right way to compare two auto types - *(A->getContainedAutoType()
> && B->getContainedAutoType()) ?*
> *Context.hasSameType* for both being auto don't return true, probably
> because two auto's will not necessarily deduce to same type.
>

hasSameType is the right check, once you get hold of the declared/undeduced
type. Note that 'auto *' and 'const auto &' will both have a contained auto
type, so your comparison won't do the right thing there.

(If true, ArgFunctionType passed in the function as argument is already
> from TypeSource info of the instantiation, so we need only return type from
> type source info of template declaration, and compare them for auto type.)
>
> Thanks again for quick review.
>
>
>
>
> On Fri, May 9, 2014 at 2:17 AM, Richard Smith <richard at metafoo.co.uk>wrote:
>
>> The patch isn't correct. It allows a return type of 'auto' to match a
>> return type of 'auto *', for instance.
>>
>> The right thing to do here is to compare the declared return type
>> (obtained from the type source info on the function declaration), not the
>> actual return type. (If the declared return type is missing the 'auto',
>> that's a bug.)
>>
>> On Thu, May 8, 2014 at 12:12 PM, suyog sarda <sardask01 at gmail.com> wrote:
>>
>>>
>>> Hi,
>>>
>>> Attaching Patch for bug 19551. Please help in reviewing it.
>>>
>>> I am checking for return type as auto in template declaration and
>>> explicit template instantiation. This patch resolves bug 19551 and has no
>>> regressions. I am not sure though if this is the correct approach.
>>>
>>> Please help in reviewing and corrections.
>>>
>>>
>>> On Wed, May 7, 2014 at 10:32 PM, suyog sarda <sardask01 at gmail.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> I was looking at Bug 19551.
>>>>
>>>> The test case is as follows :
>>>>
>>>> *template<typename T> auto f(T) { return 0; }
>>>> int k = f(0); // #1
>>>> template auto f(int); // #2
>>>> template int f(int); // #3*
>>>>
>>>> Without line #1, clang accept #2 and reject #3.
>>>> With line #1, clang reject #2 and accept #3.
>>>>
>>>> I debug this code and found following :
>>>>
>>>> 1. When the function template is instantiated (#1), clang visits functions
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Sema::AddTemplateOverloadCandidate	       Sema::DeduceTemplateArguments		           Sema::FinishTemplateArgumentDeduction*
>>>>
>>>> In *Sema::FinishTemplateArgumentDeduction* function, it creates a Specialization of the functiontemplate :
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *          Specialization = cast_or_null<FunctionDecl>(                      SubstDecl(FunctionTemplate->getTemplatedDecl(), Owner,                         MultiLevelTemplateArgumentList(*DeducedArgumentList)));*
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The return type of the created Specialization is 'auto' at this point. After this,
>>>> it completes deduction of TemplateArguments and adds this Specialization as overloaded
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> candidate. The return type still remains 'auto'.
>>>>
>>>> 2. When clang process #2 (explicit instantiation), clang visits following function :
>>>>
>>>>
>>>> *Sema::ActOnExplicitInstantiation          Sema::DeduceTemplateArguments*
>>>>
>>>>
>>>>
>>>>
>>>> *               Sema::FinishTemplateArgumentDeduction	*
>>>>
>>>> Again clang creates Specialization as in point 1 above, but strangely,
>>>> this time the return type of Specialization is 'int' though the return type of
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> FunctionTemplate remains 'auto'. Since this return type 'int' does not match with
>>>> return type of explicit instantiation i.e. 'auto', the DeduceTemplateArguments return
>>>> failure.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *    Sema::DeduceTemplateArguments{          .................          ................
>>>>           ..................         *
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *else if(!InOverloadResolution && !AT &&            !Context.hasSameType(Specialization->getType(), ArgFunctionType)) //ArgFunctionType - auto
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                                                                               // SpecializationType - int      return TDK_MiscellaneousDeductionFailure;}*
>>>>
>>>> Hence, we get error for line #2. For Line #3, the Specialization Type and ArgFunctionType
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> both are 'int'*, *hence we get no error for Line #3.
>>>>
>>>> If there is no prior instantiation, Line #2 will succeed while Line #3 will throw error.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Do we deduce return type during function template instantiation along with template parameters?
>>>>
>>>> ( Which i guess we should not but we are probably doing it as evident as the return type of second Specialization becomes 'int')
>>>>
>>>>
>>>> How should we prevent deduction of return type for second Specialization? (I tried a lot but couldn't find a way).
>>>>
>>>> GCC 4.8.2 is also behaving same as clang as described in the bug.
>>>>
>>>> Richard, any comment/help ? This bug was filed by you :)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> With regards,
>>>> Suyog Sarda
>>>>
>>>
>>>
>>> --
>>> With regards,
>>> Suyog Sarda
>>>
>>
>>
>
>
> --
> With regards,
> Suyog Sarda
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140508/b56d11cb/attachment.html>