llvm dev - Jul 2019 - [clang][AST] : extern "C" symbols not present or not visited when traversing TU decl

Hi,

I'm using clang ast for a while now to do meta compilation, and I just fell
into a problem
when trying to parse vulkan library which has extern "C" in it.
Every symbol inside extern "C" seem to be striped from the TU and ast.
I tried to #undef __cplusplus and this time I got the symbols into the AST.
I first supposed it was a problem with missing includes or else, but clang
ouput no errors, and more, now when tracing the files of every symbol in
the AST i fall onto some windows headers I never had before #undef of
__cplusplus.

Does someone know what goes wrong?

Thanks for your help !

Vivien
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190712/e69de191/attachment.html>

I don’t work on clang but I have used the AST in a project of mine before
so please take this with a grain of salt. I believe that an extern “C”
block will require you to recurse down it to see the declarations within
that block. At least this is what was true of namespaces. In that code (C
not C++) my visitor function returned CXChildVisit_Recurse for namespaces.
A quick look at the docs would suggest that the cursor kind for extern “C”
is CXCursor_LinkageSpec.

Hope that helps!

-Alex

On Fri, Jul 12, 2019 at 2:48 PM Vivien Millet via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I'm using clang ast for a while now to do meta compilation, and I just
> fell into a problem
> when trying to parse vulkan library which has extern "C" in it.
> Every symbol inside extern "C" seem to be striped from the TU and
ast.
> I tried to #undef __cplusplus and this time I got the symbols into the
> AST.
> I first supposed it was a problem with missing includes or else, but clang
> ouput no errors, and more, now when tracing the files of every symbol in
> the AST i fall onto some windows headers I never had before #undef of
> __cplusplus.
>
> Does someone know what goes wrong?
>
> Thanks for your help !
>
> Vivien
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190712/670f840e/attachment.html>

Hi Alex,
I don't have this issue with namespace on my side, and I'm using the
clang
lib in C++ (clang::ParseAST function), not the cursor based.
Thus, I don't really know if your solution applies to mine.. but thanks, I
will dig this as a start !
Vivien

Le ven. 12 juil. 2019 à 15:05, Alex Brachet-Mialot <
alexbrachetmialot at gmail.com> a écrit :
> I don’t work on clang but I have used the AST in a project of mine before
> so please take this with a grain of salt. I believe that an extern “C”
> block will require you to recurse down it to see the declarations within
> that block. At least this is what was true of namespaces. In that code (C
> not C++) my visitor function returned CXChildVisit_Recurse for namespaces.
> A quick look at the docs would suggest that the cursor kind for extern “C”
> is CXCursor_LinkageSpec.
>
> Hope that helps!
>
> -Alex
>
> On Fri, Jul 12, 2019 at 2:48 PM Vivien Millet via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> I'm using clang ast for a while now to do meta compilation, and I
just
>> fell into a problem
>> when trying to parse vulkan library which has extern "C" in
it.
>> Every symbol inside extern "C" seem to be striped from the TU
and ast.
>> I tried to #undef __cplusplus and this time I got the symbols into the
>> AST.
>> I first supposed it was a problem with missing includes or else, but
>> clang ouput no errors, and more, now when tracing the files of every
symbol
>> in the AST i fall onto some windows headers I never had before #undef
of
>> __cplusplus.
>>
>> Does someone know what goes wrong?
>>
>> Thanks for your help !
>>
>> Vivien
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190712/cb4b2ec6/attachment.html>