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

[Larisse Voufo]

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/20110827/cfb60f02/attachment.html>