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

[Richard Smith]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140508/f1630b02/attachment.html>