Attached is a patch I just made to address the issue below. <br>It basically adds local implementation in SemaTemplate.cpp and updates two regression tests.<br>I hope I applied the LLVM code standard well enough.<br><br>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. :) <br>
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". <br>
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? <br><br>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 <br>
should I express these replacements? <br><br>Please let me know what you think.<br><br>Thanks,<br>-- Larisse.<br><br><br><br><div class="gmail_quote">On Mon, May 9, 2011 at 12:00 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5"><br>
On May 9, 2011, at 6:13 AM, Larisse Voufo wrote:<br>
<br>
> The current code base, under Sema::ActOnExplicitInstantiation and Sema::CheckFunctionTemplateSpecialization (in SemaTemplate.cpp), looses information about why a given template argument deduction fails.<br>
> I need that to not be the case for better diagnoses in concepts-enabled programs.<br>
> 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.<br>
> Should I go ahead and modify my off-main-branch concepts implementation, or<br>
> should I make the change directly into clang's main branch, or<br>
> should I simply give it a moment until that part is reviewed? If so, about how long should I wait.<br>
><br>
> 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.<br>
<br>
<br>
</div></div>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.<br>

<br>
        - Doug<br>
</blockquote></div><br>