<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">The issue may be that the proper sugar isn’t being stored in the integral type when the TemplateArgument is created, so that there is no way to distinguish a non-deduced BuiltInType from a deduced one.<div class=""><div class=""><br class=""></div><div class="">The type of the NonTypeTemplateParmDecl N in </div><div class=""><span style="font-family: Menlo; font-size: x-small;" class=""><br class=""></span></div><div class=""><span style="font-family: Menlo; font-size: x-small;" class="">template<</span><span style="font-family: Menlo; font-size: x-small;" class="">auto </span><span style="font-family: Menlo; font-size: x-small;" class="">N> </span><span style="font-family: Menlo; font-size: x-small;" class="">struct </span><span style="font-family: Menlo; font-size: x-small;" class="">S {}` </span>is an AutoType — so far so good.</div><div class=""><div><br class=""></div><div>But the type of the integral TemplateArgument '1' in S<1>, though, seems to be a BuiltInType — no sugar atop it, nothing to distinguish it from the situation where N had a BuiltInType instead of an AutoType.  </div><div><br class=""></div><div>If I understand DeducedTypes correctly, when they are substituted, they should remain as sugar atop the substitution (someone correct me if I’m wrong), and that does not seem to happen here.</div><div><br class=""></div><div>If others agree this is the issue, I would imagine you will have to dig around to figure out where the template argument is being created, and wrap the integral’s type in an AutoType.  Then testing if getAs<DeducedType>() before testing getAs<BuiltInType>() should tell you when your BuiltInType was deduced.  </div><div><br class=""></div><div>That’s my last best guess anyway.  Good luck,</div><div><br class=""></div><div>Dave</div><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 22, 2020, at 3:53 AM, Pratyush Das <<a href="mailto:reikdas@gmail.com" class="">reikdas@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">That change does not work :( <div class=""><br class=""></div><div class="">Thanks though! </div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 21 Jul 2020 at 23:30, David Rector <<a href="mailto:davrecthreads@gmail.com" class="">davrecthreads@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><div class=""><font face="Menlo, Consolas, Monaco, monospace" class=""><span style="background-color:rgba(151,234,151,0.6)" class=""><br class=""></span></font><div class="">I would try replacing</div><br class=""><font face="Menlo" size="1" class=""> else if (auto *DT = T->getContainedDeducedType())</font><br class=""><br class="">with<br class=""><br class=""><font face="Menlo" size="1" class="">  else if (auto *DT = T->getAs<DeducedType>())</font></div><div class=""><br class=""></div><div class="">I think that is what you want anyway, since getContainedDeducedType seems to look not only through type sugar but through pointee types, array element types, etc.</div><div class=""><br class=""></div><div class="">To be sure, your example still should have worked using getContainedDeducedType but I think GetContainedDeducedTypeVisitor may have a problem in its implementation: it doesn’t handle all the possible sugar types.   In this case, you probably have a SubstTemplateTypeParmType, and I don’t see a VisitSubstTemplateTypeParmType implementation in there anywhere, so it is probably returning nullptr instead of desugaring and continuing to search.  That’s my best guess anyway from my perusal.</div><div class=""><br class=""></div><div class="">If this change works, it is probably another reason to replace stuff like GetContainedDeducedTypeVisitor with a more advanced getAs<T>(), with an extra template param that would allow you to look through e.g. pointee types, element types, function return types etc. when desired.</div><div class=""><div class=""><br class=""></div><div class="">If that doesn’t work though, disregard.  Good luck,</div><div class=""><br class=""></div><div class="">Dave</div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 21, 2020, at 9:06 AM, Pratyush Das via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Hi, <div class=""><br class=""></div><div class="">I am a little stuck with <a href="https://reviews.llvm.org/D77598" target="_blank" class="">https://reviews.llvm.org/D77598</a> and would really appreciate any help.</div><div class=""><br class=""></div><div class="">I am trying to get the proper suffixes in the error messages for the following two examples - <br class=""></div><div class=""><br class=""></div><div class=""><font face="monospace" class="">template<auto N> struct S {};</font></div><div class=""><font face="monospace" class="">template<> struct S<1> { using type = int };</font></div><div class=""><font face="monospace" class="">S<1L>::type t;</font></div><div class=""><br class=""></div><div class="">which should give the error message with a suffix - </div><div class=""><font face="monospace" class="">error: no type named 'type' in 'S<1L>'; did you mean 'S<1>::type'?</font></div><div class=""><br class=""></div><div class="">and</div><div class=""><br class=""></div><div class=""><font face="monospace" class="">template <unsigned long long N> struct enable_if_unsigned_long_long {};<br class="">template <> struct enable_if_unsigned_long_long<1> { typedef int type; }; <br class="">void test_unsigned_long_long() { enable_if_unsigned_long_long<2>::type i; } </font><br class=""></div><div class=""><br class=""></div><div class="">which should give no suffix in the error message - </div><div class=""><font face="monospace" class="">error: no type named 'type' in 'enable_if_unsigned_int<2>'; did you mean 'enable_if_unsigned_int<1>::type'?</font><br class=""></div><div class=""><br class=""></div><div class="">I am trying to find the correct combination that would enable suffix in the first case, but not in the second case. I have been tinkering with checks for DeducedType and DependentType, but always either the suffixes are disabled for both the cases, or enabled for both the cases. </div><div class=""><br class=""></div><div class="">Can anyone please provide any insight on how to proceed?</div><div class=""><br clear="all" class=""><div class="">Thanks!</div><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">Pratyush Das(Reik)<br class=""></div></div></div></div></div></div></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">Pratyush Das(Reik)<br class=""></div></div></div></div></div>
</div></blockquote></div><br class=""></div></div></body></html>