cpp_template_specialization unexposed_arguments() broken syntax

[deadlocklogic]

• cppast version: latest
• parser: libclang_parser
• clang version: 15.0.2

Explanation of the error.

Input:

cppast::cpp_entity_index _idx;
cppast::libclang_parser _parser;
cppast::libclang_compile_config _config;
auto _file = parse(_idx, "test", R"(
#include <vector>

template <typename T>
struct StructTemplateSpecialized {};
template <typename T>
struct StructTemplateSpecialized<std::vector<T>> {};
)",
                    true);
cppast::visit(*_file, [&](const cppast::cpp_entity& e, cppast::visitor_info info) {
    if (info.event != cppast::visitor_info::container_entity_exit) {
        if (e.kind() == cppast::cpp_entity_kind::class_template_specialization_t) {
            auto& target = dynamic_cast<const cppast::cpp_template_specialization&>(e);
            if (!target.arguments_exposed()) {
                std::cout << target.unexposed_arguments().as_string() << std::endl;
            }
        }
    }
    return true;
});

Output: This prints std::vector<T notice the missing >

Side questions:

• Why you haven't considered adding line info to cpp_entity
• Why not adding a cpp_comment entity for non-docs comment.

Thanks

[foonathan]

Fixed the issue, thanks for reporting.

Why you haven't considered adding line info to cpp_entity

I didn't need it when I wrote cppast initially. Feel free to do a PR, I'm giving some pointers in #105.

Why not adding a cpp_comment entity for non-docs comment.

Ideologically: comments shouldn't contain semantic information, use doc comments or custom attributes instead.

If you need it, it should be enough to just adjust the logic here https://github.com/foonathan/cppast/blob/34e7bb4bf4a6e0d5ce80001dd12ee6b0c4b0b384/src/libclang/preprocessor.cpp#L806 and here https://github.com/foonathan/cppast/blob/34e7bb4bf4a6e0d5ce80001dd12ee6b0c4b0b384/src/libclang/preprocessor.cpp#L739. If you want to do a PR, please add a flag to control the comment behavior.

[deadlocklogic]

Basically, in my case I my using this library for reflection/binding generation and it works perfectly. But I was considering using it as a code generator in which case I need line infos in order to be able to modify original source. By the way I already created binding to this library for lua and python and I am working for one for javascript/nodejs which I will release soon.

[deadlocklogic]

I saw someone in late issue tracker, doing a PR addressing line infos and dunno what happened back then but I think this should be straight forward.