c++11 fixed types not recognised as builtin types

[Firefly35]

• Platform : Mac OS Mojave
• cppast version: latest
• parser: libclang_parser
• clang version: Apple clang version 11.0.0 (clang-1100.0.33.12)
  (but using llvm from brew version 7.0.1 to configure LLVM_CONFIG_BINARY for cppast build)

While parsing the following code, when iterating over member function parameters, parameter is considered as a "User defined type".

Input: class header file

#include <cstdint>

class X {
virtual void f(uint32_t parameter) = 0;
};

I then tried to retrieve the cpp_entity from the cpp_type using lookup in the cpp_entity_index

void parse_parameter(const cppast::cpp_entity_index& index, const cppast::cpp_type & p) {
auto & userType = static_cast<const cppast::cpp_user_defined_type&>(p);
        std::string derefTypeKind = "User defined type";
        if (userType.entity().no_overloaded().get() > 0) {
            auto ids = userType.entity().id();
            for (auto & id : ids) {
                if (index.lookup(id).has_value()) {
                    auto & entity = index.lookup(id).value();
                    if (entity.kind() == cppast::cpp_entity_kind::type_alias_t) {
                        std::cout<<"Entity "<<entity.name()<<" is a type alias"<<std::endl;
                    }
                }
            }
}

But there is no typedef matching uint32_t in the index, hence I can't consider uint32_t as a builtin type (except through basic string matching, but not the best way IMHO).

[foonathan]

The behavior is correct, uint32_t is not a builtin type, but a typedef in stddef.h. The typedef declaration is not in the index, because you didn't parse stddef.h.

[Firefly35]

I believe stdint.h has been parsed : I use the compilation database generated from Qt creator to parse the file, hence the stdint.h file must be in the include paths. I'll check if it's parsed. However, as I want to map the fixed width types towards protobuf fixed width types, the typedef doesn't resolve the problem. Even if width types are typedefs, they functionally represent a concrete platform independent type (which is not represented with unsigned int for instance). I find unfortunate there is no information about fixed width types while parsing the AST, even if I'm aware that it depends on clang exposed types (and I did'nt found any fixed width types declarations in CXTypes). Le mer. 11 déc. 2019 à 14:33, Jonathan Müller <notifications@github.com> a écrit :

…

Closed #98 <#98>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#98>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC5Z2FE66YLGZGKVESFHYHLQYDT2DANCNFSM4JZNYOIA> .

[foonathan]

I believe stdint.h has been parsed : I use the compilation database
generated from Qt creator to parse the file, hence the stdint.h file must
be in the include paths.
I'll check if it's parsed.

It's in the include paths, yes, but the header file itself is not necessarily parsed by cppast (unless you've explicitly parsed it).

However, as I want to map the fixed width types towards protobuf fixed
width types, the typedef doesn't resolve the problem.

Hm, let me investigate a way to detect those types in an easier way.

[Firefly35]

Thanks Jonathan, I found a workaround for now extending the builtin_type_kind enum in my own code and parsing the type name. But maybe there is a sense for cppast to provide the information in the parsed AST out of the box. Le mer. 11 déc. 2019 à 15:12, Jonathan Müller <notifications@github.com> a écrit :

…

Reopened #98 <#98>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#98>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC5Z2FFKFQ3L7FEE4IY5GPDQYDYOVANCNFSM4JZNYOIA> .

[Firefly35]

Hello Jonathan, I meet an issue parsing a template instantiation parameter and have some difficulty to figure out what happens. The function parameter is declared as std::vector<int>. While trying to retrieve the arguments array, the execution logs "[debug assert] ../../../../github/github-cppast/external/type_safe/include/type_safe/tagged_union.hpp:251: Assertion 'cur_type_ == type' failed - different type stored in union." I expected to retrieve and parse the various arguments provided to the template (in this case, only int as a builtin type). Am I doing anything wrong ? Le mer. 11 déc. 2019 à 15:21, Touraine Loic <loic.touraine@gmail.com> a écrit :

…

Thanks Jonathan, I found a workaround for now extending the builtin_type_kind enum in my own code and parsing the type name. But maybe there is a sense for cppast to provide the information in the parsed AST out of the box. Le mer. 11 déc. 2019 à 15:12, Jonathan Müller ***@***.***> a écrit : > Reopened #98 <#98>. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#98>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AC5Z2FFKFQ3L7FEE4IY5GPDQYDYOVANCNFSM4JZNYOIA> > . >

[Firefly35]

I forgot to put the code retrieving the arguments array : if (p.kind() == cppast::cpp_type_kind::template_instantiation_t) { auto& templateInstType = static_cast<const cppast::cpp_template_instantiation_type&>(p); auto tmplArgs = templateInstType.arguments(); } Le lun. 16 déc. 2019 à 16:46, Touraine Loic <loic.touraine@gmail.com> a écrit :

…

Hello Jonathan, I meet an issue parsing a template instantiation parameter and have some difficulty to figure out what happens. The function parameter is declared as std::vector<int>. While trying to retrieve the arguments array, the execution logs "[debug assert] ../../../../github/github-cppast/external/type_safe/include/type_safe/tagged_union.hpp:251: Assertion 'cur_type_ == type' failed - different type stored in union." I expected to retrieve and parse the various arguments provided to the template (in this case, only int as a builtin type). Am I doing anything wrong ? Le mer. 11 déc. 2019 à 15:21, Touraine Loic ***@***.***> a écrit : > Thanks Jonathan, I found a workaround for now extending the > builtin_type_kind enum in my own code and parsing the type name. > But maybe there is a sense for cppast to provide the information in the > parsed AST out of the box. > > > Le mer. 11 déc. 2019 à 15:12, Jonathan Müller ***@***.***> > a écrit : > >> Reopened #98 <#98>. >> >> — >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub >> <#98>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AC5Z2FFKFQ3L7FEE4IY5GPDQYDYOVANCNFSM4JZNYOIA> >> . >> >