[cfe-dev] Find Type by name

Roman Popov via cfe-dev cfe-dev at lists.llvm.org
Wed Feb 28 20:02:14 PST 2018


Ok,  simply adding suffixes based on BuiltinType Kind solves the problem
for me. I will update to Clang trunk tomorrow and check if it will work
there.

2018-02-28 18:54 GMT-08:00 Roman Popov <ripopov at gmail.com>:

> Well, from what I'm seeing non-type argument printer is actually untyped.
> It uses APInt, which looks like "generic" arbitrary precision integer,
> that knows nothing about C++ type system.
>
> So solution is to print APInt value without type postfix, and then
> generate type postfix based on template parameter type.
>
> I'm not really familiar with Clang yet, so it will take a time to fix
> this. But I will try.
>
> Another option would be using mangled type names in AST Matcher.  This way
> it will be even better: you wan't need to demangle names from LLVM IR.
>
>
>
> 2018-02-28 18:07 GMT-08:00 Roman Popov <ripopov at gmail.com>:
>
>> Ok, let me run the code in debugger to understand how it makes decision
>> when to print U.
>>
>> 2018-02-28 18:05 GMT-08:00 Artem Dergachev <noqnoqneo at gmail.com>:
>>
>>> Huh, nice one. It means that the problem is somewhere in
>>> QualType::getQualifiedNameAsString(). No, it doesn't seem to be fixed
>>> in trunk. This might be an easy and welcomed patch.
>>>
>>> On 28/02/2018 5:56 PM, Roman Popov wrote:
>>>
>>>> Btw, I'm using Clang 5.0, probably it is already fixed in trunk?
>>>>
>>>> 2018-02-28 17:54 GMT-08:00 Roman Popov <ripopov at gmail.com <mailto:
>>>> ripopov at gmail.com>>:
>>>>
>>>>     Yes, it matches indeed vs my_nm::my_type<int, 10>.
>>>>
>>>>     I think this is a bug in*asString() *matcher: Here is reproducer:
>>>>
>>>>     *namespace my_nm {*
>>>>     *template<typename T, unsigned U>*
>>>>     *struct my_type {  };*
>>>>     *}*
>>>>     *
>>>>     *
>>>>     *my_nm::my_type<int, 10> m1;*
>>>>     *my_nm::my_type<int, 11u> m2;*
>>>>
>>>>     LLVM IR  generator correctly generates both types with unsigned
>>>>     second parameter. But AST Matcher thinks that m1 has signed
>>>>     parameter, and m2 has unsigned:
>>>>
>>>>     m1 matches vs *my_nm::my_type<int, 10>*
>>>>     m2 matches vs *my_nm::my_type<int, 11U> *(notice capital U)
>>>>
>>>>     In LLVM IR types are *my_nm::my_type<int, 10u> and
>>>>     *my_nm::my_type<int, 11u> **
>>>>
>>>>
>>>>     Thanks, Roman
>>>>
>>>>
>>>>
>>>>     2018-02-28 17:37 GMT-08:00 Artem Dergachev <noqnoqneo at gmail.com
>>>>     <mailto:noqnoqneo at gmail.com>>:
>>>>
>>>>
>>>>         Sorry i don't have a quick way of trying this at the moment;
>>>>         Does it work with "struct my_nm::my_type<int, 10>"? - because
>>>>         that's what i see in clang's -ast-dump. Does
>>>>         varDecl(hasType(asString(...))) work? If you match qualType()
>>>>         and dump .getAsString() on all results, what do you see?
>>>>
>>>>         Cause i think it should ultimately work.
>>>>
>>>>         On 28/02/2018 2:12 PM, Roman Popov wrote:
>>>>
>>>>             Thanks Artem. This is what I've tried before writing
>>>>             original mail. However it does not work, I got zero matches.
>>>>
>>>>             Here is reproducer:
>>>>
>>>>             *namespace my_nm {*
>>>>             *template<typename T, unsigned U>*
>>>>             *struct my_type {  };*
>>>>             *}*
>>>>             *
>>>>             *
>>>>             *my_nm::my_type<int, 10> m;
>>>>             *
>>>>
>>>>
>>>>             I got types from LLVM IR analysis, and then want to find
>>>>             them in Clang AST.
>>>>
>>>>             From LLVM I got mangled name:
>>>>             *N5my_nm7my_typeIiLj10EEE*
>>>>
>>>>             Demangled to:
>>>>             *my_nm::my_type<int, 10u>*
>>>>
>>>>             However I can't find it by any matcher:
>>>>
>>>>             auto matches =
>>>>             match(qualType(asString("*my_nm::my_type<int,
>>>>             10u>*")).bind("types"), astCtx);  // Zero matches
>>>>
>>>>             auto matches =
>>>>             match(qualType(asString("*N5my
>>>> _nm7my_typeIiLj10EEE*")).bind("types"),
>>>>             astCtx);  // Zero matches
>>>>
>>>>             Probably there is some other way to go back from LLVM IR
>>>>             to Clang AST?
>>>>
>>>>
>>>>             Thanks,
>>>>             Roman
>>>>
>>>>
>>>>             2018-02-28 12:36 GMT-08:00 Artem Dergachev
>>>>             <noqnoqneo at gmail.com <mailto:noqnoqneo at gmail.com>
>>>>             <mailto:noqnoqneo at gmail.com <mailto:noqnoqneo at gmail.com>>>:
>>>>
>>>>                 I don't think it's possible via straightforward lookup
>>>>             - you might
>>>>                 need to scan the AST to do this.
>>>>
>>>>                 Eg. using ASTMatchers:
>>>>
>>>>                     qualType(asString("my_nm::my_type<int, 10u>"))
>>>>
>>>>                 Or, if you're not using ASTMatchers (likely), you can
>>>>             do the same
>>>>                 with a RecursiveASTVisitor. Or manually.
>>>>
>>>>
>>>>                 On 27/02/2018 10:56 AM, Roman Popov via cfe-dev wrote:
>>>>
>>>>                     Hello,
>>>>
>>>>                     Is it possible to find type in AST by it's
>>>>             qualified type?
>>>>
>>>>                     For example I have string "my_nm::my_type<int,
>>>>             10u>", how can
>>>>                     I get clang::QualType if type is present in
>>>>             translation unit?
>>>>
>>>>                     Thanks,
>>>>                     Roman
>>>>
>>>>
>>>>                     _______________________________________________
>>>>                     cfe-dev mailing list
>>>>             cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>>>             <mailto:cfe-dev at lists.llvm.org
>>>>             <mailto:cfe-dev at lists.llvm.org>>
>>>>             http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>             <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>>>>
>>>>             <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>             <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180228/44f22bb7/attachment.html>


More information about the cfe-dev mailing list