[cfe-commits] [PATCH] Re: [cfe-dev]Explicit template instantiation, function template specialization, and diagnoses...

[Larisse Voufo]

[A minor correction to the patch. Sorry. This is final.]

On Sat, Aug 27, 2011 at 2:59 PM, Larisse Voufo <lvoufo at cs.indiana.edu>wrote:

> By the way, here is a sample before and after "picture" of error message
> for explicit instantiation failure:
>
> ---------------------------
> Before
> ---------------------------
> $ ~/llvm/Debug+Asserts/bin/clang++ test.cpp -o test
> test.cpp:7:15: error: explicit instantiation of 'func' does not refer to a
> function template, member function, member class, or static
>       data member
> template void func<int>(short); // expected-error {{explicit instantiation
> of 'func' does not refer to a function template}}
>               ^
> 1 error generated.
>
>
> ---------------------------
> After
> ---------------------------
> $ ~/llvm/Debug+Asserts/bin/clang++ test.cpp -o test
> test.cpp:7:15: error: explicit instantiation of 'func' does not refer to a
> function template, member function, member class, or static
>       data member
> template void func<int>(short); // expected-error {{explicit instantiation
> of 'func' does not refer to a function template}}
>               ^
> test.cpp:2:6: note: candidate template ignored: failed template argument
> deduction
> void func(T) { }
>      ^
> 1 error generated.
>
>
>
> -----------------------------------------------------------------------------------------
> The code the the compiler generates the above errors for follows:
>
> -----------------------------------------------------------------------------------------
> template<typename T>
> void func(T) { }
>
> template void func(char);
> template void func(float);
> template void func(int);
> template void func<int>(short);
>
> int main(int argc, char **argv)
> {
>   return 0;
> }
>
> Thanks,
> -- Larisse.
>
>
>
> On Sat, Aug 27, 2011 at 2:46 PM, Larisse Voufo <lvoufo at cs.indiana.edu>wrote:
>
>> Attached is a patch I just made to address the issue below.
>> It basically adds local implementation in SemaTemplate.cpp and updates two
>> regression tests.
>> I hope I applied the LLVM code standard well enough.
>>
>> Basically, to resolve this issue, I had to adapt a reasoning similar to
>> that used for overload resolution (in SemaOverload.cpp). However, I resisted
>> to reuse the implementation directly, as there must be a reason why the vast
>> experience of clang developers (mine being minuscule in comparison) had not
>> done that themselves yet. :)
>> In fact, looking at the C++ Standard, [over.match] precisely,  it appears
>> that the functions that cause explicit instantiations or specializations to
>> cause the template argument deduction failures are not to be considered
>> "candidate functions".
>> Is that correct? If so, does that explain why I shouldn't reuse the
>> implementation directly and simply do what I provide in the patch?
>>
>> One more thing: For now, the patch is reusing the same diagnosis messages
>> as in SemaOverload.cpp, precisely DiagnoseBadDeduction(), with diagnosis id
>> starting with note_ovl_candidate_*. Should I create entirely new diagnosis
>> instead? If so, what about
>> should I express these replacements?
>>
>> Please let me know what you think.
>>
>> Thanks,
>> -- Larisse.
>>
>>
>>
>> On Mon, May 9, 2011 at 12:00 PM, Douglas Gregor <dgregor at apple.com>wrote:
>>
>>>
>>> On May 9, 2011, at 6:13 AM, Larisse Voufo wrote:
>>>
>>> > The current code base, under Sema::ActOnExplicitInstantiation and
>>> Sema::CheckFunctionTemplateSpecialization (in SemaTemplate.cpp), looses
>>> information about why a given template argument deduction fails.
>>> > I need that to not be the case for better diagnoses in concepts-enabled
>>> programs.
>>> > I was wondering what the best approach would be at the moment,
>>> depending on when the Clang community intends to review that part of the
>>> implementation.
>>> > Should I go ahead and modify my off-main-branch concepts
>>> implementation, or
>>> > should I make the change directly into clang's main branch, or
>>> > should I simply give it a moment until that part is reviewed? If so,
>>> about how long should I wait.
>>> >
>>> > I find it'd be more beneficial, if I were to do it myself, if I made
>>> the changes as globally as possible rather than just within my concepts
>>>  implementation.
>>>
>>>
>>> I suggest implementing it for inclusion in Clang's main branch, and
>>> submitting a patch to cfe-commits. That way, everyone can benefit from this
>>> work immediately, and it'll just be That Much Cooler when concepts are
>>> involved.
>>>
>>>        - Doug
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110829/cf6c528c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: template_deduction_failure_handling.patch
Type: application/octet-stream
Size: 24379 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110829/cf6c528c/attachment.obj>