cppast icon indicating copy to clipboard operation
cppast copied to clipboard

c++11 fixed types not recognised as builtin types

Open Firefly35 opened this issue 6 years ago • 6 comments

  • 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).

Firefly35 avatar Dec 11 '19 11:12 Firefly35

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.

foonathan avatar Dec 11 '19 13:12 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.

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 [email protected] a écrit :

Closed #98 https://github.com/foonathan/cppast/issues/98.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/foonathan/cppast/issues/98?email_source=notifications&email_token=AC5Z2FG4QHPGJEQXT2GBSTLQYDT2DA5CNFSM4JZNYOIKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOVNJCWCI#event-2874288905, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5Z2FE66YLGZGKVESFHYHLQYDT2DANCNFSM4JZNYOIA .

Firefly35 avatar Dec 11 '19 13:12 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.

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.

foonathan avatar Dec 11 '19 14:12 foonathan

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 [email protected] a écrit :

Reopened #98 https://github.com/foonathan/cppast/issues/98.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/foonathan/cppast/issues/98?email_source=notifications&email_token=AC5Z2FB42IFQTA6DSROYCOTQYDYOVA5CNFSM4JZNYOIKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOVNKEYLY#event-2874428463, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5Z2FFKFQ3L7FEE4IY5GPDQYDYOVANCNFSM4JZNYOIA .

Firefly35 avatar Dec 11 '19 14:12 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. 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 [email protected] 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 [email protected] a écrit :

Reopened #98 https://github.com/foonathan/cppast/issues/98.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/foonathan/cppast/issues/98?email_source=notifications&email_token=AC5Z2FB42IFQTA6DSROYCOTQYDYOVA5CNFSM4JZNYOIKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOVNKEYLY#event-2874428463, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5Z2FFKFQ3L7FEE4IY5GPDQYDYOVANCNFSM4JZNYOIA .

Firefly35 avatar Dec 16 '19 15:12 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 [email protected] 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. 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 [email protected] 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 [email protected] a écrit :

Reopened #98 https://github.com/foonathan/cppast/issues/98.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/foonathan/cppast/issues/98?email_source=notifications&email_token=AC5Z2FB42IFQTA6DSROYCOTQYDYOVA5CNFSM4JZNYOIKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOVNKEYLY#event-2874428463, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5Z2FFKFQ3L7FEE4IY5GPDQYDYOVANCNFSM4JZNYOIA .

Firefly35 avatar Dec 16 '19 15:12 Firefly35