[cfe-dev] Help Request: Libclang on Windows (C++11)

[Bobby Anguelov]

Hi,

 

I'm emailing this list in the hopes that someone might be able to help me. I
am currently using libclang to do some very basic reflection of C++. I am
creating a translation unit for a header and then visiting all the tree
elements using the cursors, in some cases I fall back onto the qualtypes to
get the necessary information out. The problem that I'm having right now is
that the cursor type libclang return for std::vector (and other std types
like std::map ) is incorrect. It looks like libclang can't identify the type
and falls back onto default int as I am getting a type spelling of "int" for
fields of type std::vector. 

 

Given the example header file below:

#include <vector>

#include <string>

 

namespace SomeNamespace

{

    struct B

    {

        std::string m_string;

        std::vector<float> m_vector;

    };

}

 

I parse it using clang_parseTranslationUnit2 with the following inputs: 

 

Args: "-x", "c++", "-std=c++11"

 

Options: CXTranslationUnit_DetailedPreprocessingRecord |
CXTranslationUnit_SkipFunctionBodies | CXTranslationUnit_Incomplete;

 

Now when visiting the fields for struct B I get:

 

CXType_Int for the cursor to m_vector instead of CXtype_Unexposed which is
what I would expect.

 

but for the std::string member m_string, I get CXType_Unexposed which allows
me to visit the field and extract the necessary info. When visiting the
field for the string I correctly get the "namespace" then "typeref" cursor
types.

 

I am completely out of ideas as to what is going on, why does lib clang fail
to understand the std::vector type? I'm pretty sure I must be doing
something horribly wrong.

 

I got latest on the libclang version from github on June 1st, 2015, built
for windows x64 using MSVC 2013 toolchain.

 

Any assistance would be greatly appreciated, thanks in advance, 

Bobby

 

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