[cfe-dev] [Patch] BUG 19551 explicit instantiation confusion for a function with a deduced return type already been instantiated
suyog sarda
sardask01 at gmail.com
Fri May 9 16:26:33 PDT 2014
Hi Richard,
As per your comments, I am now comparing return type from type source info.
By this way we are able to catch hold of ' auto ' as return type of
declared function.
If the return types from type source info do not match, then error is
emitted.
I am doing this only for auto types, as there can be return type of
template
parameter of the declared template (in which, we do not compare as template
parameter can equal actual return type).
*Patch Code highlight:*
*TypeSourceInfo *TI = Function->getTypeSourceInfo(); QualType
FuncReturnType = TI->getType()->castAs<FunctionType>()->getReturnType();
if (isa<FunctionType>(ArgFunctionType)){ QualType
ArgFunctionReturnType =
ArgFunctionType->getAs<FunctionType>()->getReturnType();*
*// We check for auto contained type to eliminate checking template
parameter as return type if
(FuncReturnType->getContainedAutoType()){ if
(!Context.hasSameType(ArgFunctionReturnType,FuncReturnType))
return TDK_MiscellaneousDeductionFailure; else return
TDK_Success; } }*
Bug 19551 gets resolved with this patch.
*Test case :*
*template<typename T> auto f(T) { return 0; }int k = f(0); // #1template
auto f(int); // #2 template int f(int); // #3*
*Output with patch :*
*suyog at suyog-Inspiron-N5010:~$ llvm/llvm/build/bin/clang bug_19551.C
-std=c++1ybug_19551.C:4:14: error: explicit instantiation of 'f' does not
refer to a function template, variable template, member function, member
class, or static data membertemplate int f(int); // #3
^bug_19551.C:1:27: note: candidate template ignored: failed template
argument deductiontemplate<typename T> auto f(T) { return 0; }
^1 error generated.*
This patch also differentiates between ' auto ' and ' auto* ' and throws
error for such case too.
However, I am getting 1 regression in file
test/SemaCXX/cxx1y-deduced-return-type.cpp.
It contains cases where return types are same and we also need to check if
Specialization type
matches with ArgFunction Type - which is exactly opposite to our test case
(Specialization type doesn't match with ArgFunction Type in our test case
19551). Its like trying to validate true and false
at the same time.
I am attaching patch for the reference. (test case excluded for a while).
Your comment will be a great help to resolve this. Thanks !
On Fri, May 9, 2014 at 6:02 AM, Richard Smith <richard at metafoo.co.uk> wrote:
> 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
>>
>
>
--
With regards,
Suyog Sarda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140510/8e0bcfde/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 19551.patch
Type: text/x-patch
Size: 2960 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140510/8e0bcfde/attachment.bin>
More information about the cfe-dev
mailing list