[cfe-dev] Help with integral template argument suffix and cast printing

David Rector via cfe-dev cfe-dev at lists.llvm.org
Wed Jul 22 07:53:42 PDT 2020


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.

The type of the NonTypeTemplateParmDecl N in 

template<auto N> struct S {}` is an AutoType — so far so good.

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.  

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.

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.  

That’s my last best guess anyway.  Good luck,

Dave

> On Jul 22, 2020, at 3:53 AM, Pratyush Das <reikdas at gmail.com> wrote:
> 
> That change does not work :( 
> 
> Thanks though! 
> 
> On Tue, 21 Jul 2020 at 23:30, David Rector <davrecthreads at gmail.com <mailto:davrecthreads at gmail.com>> wrote:
> 
> I would try replacing
> 
>  else if (auto *DT = T->getContainedDeducedType())
> 
> with
> 
>   else if (auto *DT = T->getAs<DeducedType>())
> 
> 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.
> 
> 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.
> 
> 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.
> 
> If that doesn’t work though, disregard.  Good luck,
> 
> Dave
> 
>> On Jul 21, 2020, at 9:06 AM, Pratyush Das via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>> 
>> Hi, 
>> 
>> I am a little stuck with https://reviews.llvm.org/D77598 <https://reviews.llvm.org/D77598> and would really appreciate any help.
>> 
>> I am trying to get the proper suffixes in the error messages for the following two examples - 
>> 
>> template<auto N> struct S {};
>> template<> struct S<1> { using type = int };
>> S<1L>::type t;
>> 
>> which should give the error message with a suffix - 
>> error: no type named 'type' in 'S<1L>'; did you mean 'S<1>::type'?
>> 
>> and
>> 
>> template <unsigned long long N> struct enable_if_unsigned_long_long {};
>> template <> struct enable_if_unsigned_long_long<1> { typedef int type; }; 
>> void test_unsigned_long_long() { enable_if_unsigned_long_long<2>::type i; } 
>> 
>> which should give no suffix in the error message - 
>> error: no type named 'type' in 'enable_if_unsigned_int<2>'; did you mean 'enable_if_unsigned_int<1>::type'?
>> 
>> 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. 
>> 
>> Can anyone please provide any insight on how to proceed?
>> 
>> Thanks!
>> 
>> -- 
>> Pratyush Das(Reik)
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> 
> 
> 
> -- 
> Pratyush Das(Reik)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200722/f124f2d5/attachment.html>


More information about the cfe-dev mailing list