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

[Larisse Voufo]

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/eafb07e1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: template_deduction_failure_handling.patch
Type: application/octet-stream
Size: 13999 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110827/eafb07e1/attachment.obj>