From cfe-users at lists.llvm.org  Mon Jul  1 09:17:14 2019
From: cfe-users at lists.llvm.org (Trevor Harrison via cfe-users)
Date: Mon, 1 Jul 2019 12:17:14 -0400
Subject: [cfe-users] DWARF bit field offset wrong values in LLVM
Message-ID: <CAEaoM9fTji6WJVjC99tX6fUvCs122Guh6Gxd3pKwfodSi0h6tQ@mail.gmail.com>

I'm trying to extract information about bitfields in a structure using
DWARF info.

The info generated by LLVM seems to be incorrect and not following the
DWARF standard.

If this isn't the right mailing list, please let me know.

If you look at DwarfUnit.cpp in the current LLVM src, it is using
DIDerivedType.getOffsetInBits() for the value of DW_AT_data_bit_offset.

The DWARF standard states that the bit offset: "is the offset in bits from
the beginning of the containing storage to the beginning of the value",
meaning the field the bitfield is packed in, not the structure holding the
field.

As a result of this, the values that LLVM emit are completely out of line
with the values that I'm seeing come from gcc.

(Of course, you can't use a naive example where the bitfields are at the
beginning of the struct to test this, they need to occur later in the
struct).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20190701/f3feddb4/attachment.html>

From cfe-users at lists.llvm.org  Mon Jul  1 11:24:03 2019
From: cfe-users at lists.llvm.org (Trevor Harrison via cfe-users)
Date: Mon, 1 Jul 2019 14:24:03 -0400
Subject: [cfe-users] DWARF bit field offset wrong values in LLVM
In-Reply-To: <CAEaoM9fTji6WJVjC99tX6fUvCs122Guh6Gxd3pKwfodSi0h6tQ@mail.gmail.com>
References: <CAEaoM9fTji6WJVjC99tX6fUvCs122Guh6Gxd3pKwfodSi0h6tQ@mail.gmail.com>
Message-ID: <CAEaoM9f7iW9Fs4m0L+v3GMoRf6b9x2rufE+Cpf1a7P03Tea9nw@mail.gmail.com>

Yeah, ignore my ramblings.  LLVM is fine, I was visually confusing the
pre-dwarf4 bit_offset attribute value with new hotness of data_bit_offset.
Thanks Matthew for the cfe-dev suggestion.

On Mon, Jul 1, 2019 at 12:17 PM Trevor Harrison <tharrison at eci-usa.net>
wrote:

> I'm trying to extract information about bitfields in a structure using
> DWARF info.
>
> The info generated by LLVM seems to be incorrect and not following the
> DWARF standard.
>
> If this isn't the right mailing list, please let me know.
>
> If you look at DwarfUnit.cpp in the current LLVM src, it is using
> DIDerivedType.getOffsetInBits() for the value of DW_AT_data_bit_offset.
>
> The DWARF standard states that the bit offset: "is the offset in bits from
> the beginning of the containing storage to the beginning of the value",
> meaning the field the bitfield is packed in, not the structure holding the
> field.
>
> As a result of this, the values that LLVM emit are completely out of line
> with the values that I'm seeing come from gcc.
>
> (Of course, you can't use a naive example where the bitfields are at the
> beginning of the struct to test this, they need to occur later in the
> struct).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20190701/0b762e51/attachment.html>

From cfe-users at lists.llvm.org  Thu Jul 18 02:15:03 2019
From: cfe-users at lists.llvm.org (Jerry Scharf via cfe-users)
Date: Thu, 18 Jul 2019 02:15:03 -0700
Subject: [cfe-users] thinlto and c++ static initialization analysis
Message-ID: <9765b0ae-9ed0-0823-636f-a7c022b219ae@lagunawayconsulting.com>

I am looking at trying out thinlto on our large c++ programs. We have 
had to do a bunch of careful things to make sure things get linked in 
the right order to get the static initialization to work right.

Two questions:

Will thinlto honor the command line ordering of files that we set?

In theory, with lto one could build the dependency graph of 
initializations and guarantee the correct ordering. Has anyone worked on 
this and are there any plans for this in the future?

thanks in advance,

jerry




From cfe-users at lists.llvm.org  Thu Jul 18 16:59:44 2019
From: cfe-users at lists.llvm.org (Christian Gagneraud via cfe-users)
Date: Fri, 19 Jul 2019 11:59:44 +1200
Subject: [cfe-users] thinlto and c++ static initialization analysis
In-Reply-To: <9765b0ae-9ed0-0823-636f-a7c022b219ae@lagunawayconsulting.com>
References: <9765b0ae-9ed0-0823-636f-a7c022b219ae@lagunawayconsulting.com>
Message-ID: <CABxGUTjyFwYNHS0tXL4ZOzZv235uNOmLCJnGcHbH3vWVhzjMVA@mail.gmail.com>

On Thu, 18 Jul 2019 at 21:15, Jerry Scharf via cfe-users
<cfe-users at lists.llvm.org> wrote:
>
> I am looking at trying out thinlto on our large c++ programs. We have
> had to do a bunch of careful things to make sure things get linked in
> the right order to get the static initialization to work right.
>
> Two questions:
>
> Will thinlto honor the command line ordering of files that we set?

You're relying on undefined behaviour. If thinlto honor the command
line ordering *today*, there's no guarantee that it will in the
future.
Best to fix the code instead of relying on compiler implementation.

You could use the "undefined" sanitizer to detect so called "static
initialisation 'fiasco' (problem)"
(https://isocpp.org/wiki/faq/ctors#static-init-order)

My 2 cents.


From cfe-users at lists.llvm.org  Wed Jul 17 23:20:49 2019
From: cfe-users at lists.llvm.org (=?utf-8?Q?Victor_=E2=80=9CLOST=E2=80=9D_Milovanov?= via cfe-users)
Date: Wed, 17 Jul 2019 23:20:49 -0700
Subject: [cfe-users] Getting underlying type for `using typename` declaration
Message-ID: <5d300fc1.1c69fb81.830f3.d179@mx.google.com>

Hi CFE users!

I am trying to get a `QualType` instance from `UnresolvedUsingTypenameDecl`. Unlike `TypeAliasDecl` `UnresolvedUsingTypenameDecl` does not have a `getUnderlyingType` method.

I could not find a way to construct one from the `DeclarationNameInfo` (`getNameInfo`) and `NestedNameSpecifier` (`getQualifier`).

The library I am working on already supports type aliases, and I was hoping I could treat `using typename` declarations in a similar way. Not sure if it is the right way though.

Regards,
Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20190717/d5444276/attachment.html>

From cfe-users at lists.llvm.org  Mon Jul 22 12:38:00 2019
From: cfe-users at lists.llvm.org (Richard Smith via cfe-users)
Date: Mon, 22 Jul 2019 12:38:00 -0700
Subject: [cfe-users] Getting underlying type for `using typename`
	declaration
In-Reply-To: <5d300fc1.1c69fb81.830f3.d179@mx.google.com>
References: <5d300fc1.1c69fb81.830f3.d179@mx.google.com>
Message-ID: <CAOfiQqn+aiJCXt6Nro97CHiPUij4=YinBi=jm_hx+HMLXtP1wQ@mail.gmail.com>

On Wed, 17 Jul 2019 at 23:20, Victor “LOST” Milovanov via cfe-users <
cfe-users at lists.llvm.org> wrote:

> Hi CFE users!
>
>
>
> I am trying to get a `QualType` instance from
> `UnresolvedUsingTypenameDecl`. Unlike `TypeAliasDecl`
> `UnresolvedUsingTypenameDecl` does not have a `getUnderlyingType` method.
>
>
>
> I could not find a way to construct one from the `DeclarationNameInfo`
> (`getNameInfo`) and `NestedNameSpecifier` (`getQualifier`).
>

You could build a suitable QualType by calling
Sema::CheckTypenameType(ETK_Typename, U->getTypenameLoc(),
U->getQualifierLoc(), U->getIdentifier(), U->getLocation()).


> The library I am working on already supports type aliases, and I was
> hoping I could treat `using typename` declarations in a similar way. Not
> sure if it is the right way though.
>
>
>
> Regards,
>
> Victor
> _______________________________________________
> cfe-users mailing list
> cfe-users at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20190722/4f3cdfe9/attachment.html>

From cfe-users at lists.llvm.org  Mon Jul 22 15:28:53 2019
From: cfe-users at lists.llvm.org (Edward Diener via cfe-users)
Date: Mon, 22 Jul 2019 18:28:53 -0400
Subject: [cfe-users] clang-cl choosing VC++ backend on Windows
Message-ID: <qh5db6$5g3v$1@blaine.gmane.org>

Given multiple installations installed of Visual Studio/VC++ on Windows, 
with none of them normally in the PATH, how does clang-cl choose which 
one to use at compile/link time as the clang backend ?



From cfe-users at lists.llvm.org  Mon Jul 22 21:15:55 2019
From: cfe-users at lists.llvm.org (Edward Diener via cfe-users)
Date: Tue, 23 Jul 2019 00:15:55 -0400
Subject: [cfe-users] clang-cl choosing VC++ backend on Windows
Message-ID: <4b06e75f-d2e4-b0dc-397e-a702ea18a4da@tropicsoft.com>

Given multiple installations installed of Visual Studio on Windows, with 
none of them normally in the PATH, how does clang-cl choose which one to 
use at compile/link time as the VC++ backend ?



From cfe-users at lists.llvm.org  Tue Jul 23 07:35:58 2019
From: cfe-users at lists.llvm.org (Harry Wagstaff via cfe-users)
Date: Tue, 23 Jul 2019 15:35:58 +0100
Subject: [cfe-users] clang+MinGW issue with float.h
Message-ID: <CABvbMNsY-C2=5hRBZCfFQN+_8XcFugVo-4K_wX5UUUsHJVTJKw@mail.gmail.com>

Hi all,

I have a simple program which I can successfully compile with clang, using
MinGW's C/C++ Library:

#include <stdio.h>int main(int argc, char **argv) { printf("Hello
world!\n"); return 0; }

I am able to compile this with mingw-gcc successfully:

 $ gcc test.c -o test
 $ ./test
 Hello world!

I am also able to compile it successfully using clang+mingw:

 $ clang test.c -o test -target
 $ ./test
 Hello world!

However, if I make a small change to my program (include float.h), it
continues to compile with gcc but no longer compiles with clang:

#include <stdio.h>#include <float.h>int main(int argc, char **argv) {
printf("Hello world!\n"); return 0; }

 $ gcc test.c -o test
 $ ./test
 Hello world!

 $ clang test.c -o test -target x86_64-pc-windows-gnu
 In file included from test.c:2:
 In file included from C:\llvm\built\lib\clang\8.0.0\include\float.h:45:
 C:\mingw64-8.1.0\x86_64-w64-mingw32\include\float.h:28:15: fatal
error: 'float.h' file not found
 #include_next <float.h>
               ^~~~~~~~~
 1 error generated.

Is there some configuration issue with clang or some missing command line
argument? Googling around a bit, it appears that the order of paths when
including float.h is important, but this is all supposed to be handled
internally by the clang driver.

Thanks,

Harry Wagstaff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20190723/0a1ad535/attachment.html>

From cfe-users at lists.llvm.org  Thu Jul 25 09:29:14 2019
From: cfe-users at lists.llvm.org (Hans Wennborg via cfe-users)
Date: Thu, 25 Jul 2019 09:29:14 -0700
Subject: [cfe-users] clang-cl choosing VC++ backend on Windows
In-Reply-To: <qh5db6$5g3v$1@blaine.gmane.org>
References: <qh5db6$5g3v$1@blaine.gmane.org>
Message-ID: <CAB8jPheDEwG72iQGqZw_sCdHAZ517un1H7XxeLwwNg+TPMz+mA@mail.gmail.com>

On Mon, Jul 22, 2019 at 3:29 PM Edward Diener via cfe-users
<cfe-users at lists.llvm.org> wrote:
>
> Given multiple installations installed of Visual Studio/VC++ on Windows,
> with none of them normally in the PATH, how does clang-cl choose which
> one to use at compile/link time as the clang backend ?

It's a bit involved. You can find the code here:
http://llvm-cs.pcc.me.uk/tools/clang/lib/Driver/ToolChains/MSVC.cpp#709

Clang first looks for environment variables VCToolsInstallDir or
VCINSTALLDIR which are usually set by vcvarsall.bat (or if you launch
a Visual Studio Native Tools Command Prompt). If those aren't set, it
looks on PATH.

After that, it queries the "Visual Studio Setup Configuration Server",
and after that it checks the registry.


If you want to point Clang to use a specific Visual Studio install,
the best way is to set the environment variables the way vcvarsall.bat
sets them.

Hope that helps,
Hans


From cfe-users at lists.llvm.org  Thu Jul 25 11:41:42 2019
From: cfe-users at lists.llvm.org (Bob Eastbrook via cfe-users)
Date: Thu, 25 Jul 2019 11:41:42 -0700
Subject: [cfe-users] Should clang++ -g produce debugging info for all types?
Message-ID: <CALaVOxnVJUQkq9MMyps52Cz4OH7u9GrPoA3Cxv62WzB1xkt8DA@mail.gmail.com>

On Fedora 30, "clang++ -g main.cc" does not emit debugging information
for types such as std::string.  I can only get complete debugging
information by including "-fno-limit-debug-info".

On Ubuntu 19.04, "clang++ -g" emits debugging info for std::string as expected.

Which behavior of "-g" is correct?  Can anyone explain why each
platform behaves differently?


From cfe-users at lists.llvm.org  Thu Jul 25 20:35:14 2019
From: cfe-users at lists.llvm.org (David Blaikie via cfe-users)
Date: Thu, 25 Jul 2019 20:35:14 -0700
Subject: [cfe-users] Should clang++ -g produce debugging info for all
	types?
In-Reply-To: <CALaVOxnVJUQkq9MMyps52Cz4OH7u9GrPoA3Cxv62WzB1xkt8DA@mail.gmail.com>
References: <CALaVOxnVJUQkq9MMyps52Cz4OH7u9GrPoA3Cxv62WzB1xkt8DA@mail.gmail.com>
Message-ID: <CAENS6Et4qQt7Cn0LMyK-wmp1iDn_ABRLay4XPoy25q6jRO_Kfw@mail.gmail.com>

No, it shouldn't - clang attempts to avoid emitting duplicate debug info
across the program (it assumes you built the whole program and all
libraries with debug info), gcc assumes the same thing though in slightly
different/fewer ways.

The solution is to install the -dbg build of your libstdc++ package
(assuming you're using libstdc++), it will include debug info for the
standard library, including std::string.

To see a case where GCC does the same thing - try a variable of type
std::fstream. GCC, similarly, will produce only a declaration for the
basic_fstream type, not the definition.

(& here's a lightning talk that discusses, briefly, some of this:
https://www.youtube.com/watch?v=XvkLHIASlp8 )

On Thu, Jul 25, 2019 at 11:41 AM Bob Eastbrook via cfe-users <
cfe-users at lists.llvm.org> wrote:

> On Fedora 30, "clang++ -g main.cc" does not emit debugging information
> for types such as std::string.  I can only get complete debugging
> information by including "-fno-limit-debug-info".
>
> On Ubuntu 19.04, "clang++ -g" emits debugging info for std::string as
> expected.
>
> Which behavior of "-g" is correct?  Can anyone explain why each
> platform behaves differently?
> _______________________________________________
> cfe-users mailing list
> cfe-users at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20190725/3885acce/attachment.html>

From cfe-users at lists.llvm.org  Tue Jul 30 09:50:14 2019
From: cfe-users at lists.llvm.org (Bob Eastbrook via cfe-users)
Date: Tue, 30 Jul 2019 09:50:14 -0700
Subject: [cfe-users] Should clang++ -g produce debugging info for all
	types?
In-Reply-To: <CAENS6Et4qQt7Cn0LMyK-wmp1iDn_ABRLay4XPoy25q6jRO_Kfw@mail.gmail.com>
References: <CALaVOxnVJUQkq9MMyps52Cz4OH7u9GrPoA3Cxv62WzB1xkt8DA@mail.gmail.com>
 <CAENS6Et4qQt7Cn0LMyK-wmp1iDn_ABRLay4XPoy25q6jRO_Kfw@mail.gmail.com>
Message-ID: <CALaVOx=YuN+XpYbayicjW-_26p7rWJ_3kE_=urgmH7NJEykw7Q@mail.gmail.com>

On Thu, Jul 25, 2019 at 8:35 PM David Blaikie <dblaikie at gmail.com> wrote:

> No, it shouldn't - clang attempts to avoid emitting duplicate debug info across the program (it assumes you built the whole program and all libraries with debug info), gcc assumes the same thing though in slightly different/fewer ways.
>
> The solution is to install the -dbg build of your libstdc++ package (assuming you're using libstdc++), it will include debug info for the standard library, including std::string.

Thanks for the pointer.  Based on what you told me, I was able to dig
deeper and found these relevant links:

https://bugs.llvm.org/show_bug.cgi?id=24202#c1
https://stackoverflow.com/questions/41745527/cannot-view-stdstring-when-compiled-with-clang

I installed the debug version of libstd++ on my Fedora system with
"dnf debuginfo-install libstdc++" and I now see a debug version of
libstdc++:

$ file /usr/lib/debug/lib64/libstdc++.so.6.0.26-9.1.1-1.fc30.x86_64.debug
/usr/lib/debug/lib64/libstdc++.so.6.0.26-9.1.1-1.fc30.x86_64.debug:
ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux),
dynamically linked,
BuildID[sha1]=3b2e1aaafd0cb7e1ebd75627d4cde2504c927159, with
debug_info, not stripped

I don't have things working though.  I still don't see std::string
info when debugging.  My executable is linked against the non-debug
version:

$ ldd a.out
    linux-vdso.so.1 (0x00007ffec03fe000)
    libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2fccd31000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f2fccbeb000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2fccbd1000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f2fcca0b000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2fccf45000)

Is that my problem?  Or does LLDB somehow know to use the version in
/usr/lib/debug/lib64?

I'm also puzzled about why the debug version was put in /usr/lib and
not /usr/lib64.


From cfe-users at lists.llvm.org  Tue Jul 30 15:14:01 2019
From: cfe-users at lists.llvm.org (Mateusz Loskot via cfe-users)
Date: Wed, 31 Jul 2019 00:14:01 +0200
Subject: [cfe-users] [clang-format] Trailing return type
In-Reply-To: <CABUeae-n581byawsCExtJ3RV_K_9s3bfgw1evTB1XXo=pdXGbA@mail.gmail.com>
References: <CABUeae-Abh7u3fSjRsm7Rn7OWfjLfeCyjODr5HFinJKe8RnEgw@mail.gmail.com>
 <CAAiaBiFPo_Q_iF7+cCkx7oBF+MM71-smb7uZR2_iZ0DxxqGtxg@mail.gmail.com>
 <CABUeae-n581byawsCExtJ3RV_K_9s3bfgw1evTB1XXo=pdXGbA@mail.gmail.com>
Message-ID: <CABUeae9EOvum70788L4X5f2J_b0k9zxsCGAPmeV_8K_kmZEZhQ@mail.gmail.com>

On Mon, 5 Nov 2018 at 19:27, Mateusz Loskot <mateusz at loskot.net> wrote:
> On Fri, 2 Nov 2018 at 06:11, Owen Pan <owenpiano at gmail.com> wrote:
>
> I noticed one issue which I wonder if it does qualify for a bug report:
>
> TL;TR: arrow followed by typename keyword is not handled
>
> Before:
>
> template <int K, typename E, typename L, int N>
> auto bbbbbbbbbbbbbbbbbbbbbbb(detail::base<E, L, N>& p) -> typename
> std::add_lvalue_reference<E>::type;
>
> After:
>
> template <int K, typename E, typename L, int N>
> auto bbbbbbbbbbbbbbbbbbbbbbb(detail::base<E, L, N> &p) ->
>     typename std::add_lvalue_reference<E>::type;

FYI, I've reported it as a bug (took me a while!)

https://bugs.llvm.org/show_bug.cgi?id=42835

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net


From cfe-users at lists.llvm.org  Tue Jul 30 15:17:12 2019
From: cfe-users at lists.llvm.org (Mateusz Loskot via cfe-users)
Date: Wed, 31 Jul 2019 00:17:12 +0200
Subject: [cfe-users] [clang-format] Trailing return type
In-Reply-To: <CABUeae9EOvum70788L4X5f2J_b0k9zxsCGAPmeV_8K_kmZEZhQ@mail.gmail.com>
References: <CABUeae-Abh7u3fSjRsm7Rn7OWfjLfeCyjODr5HFinJKe8RnEgw@mail.gmail.com>
 <CAAiaBiFPo_Q_iF7+cCkx7oBF+MM71-smb7uZR2_iZ0DxxqGtxg@mail.gmail.com>
 <CABUeae-n581byawsCExtJ3RV_K_9s3bfgw1evTB1XXo=pdXGbA@mail.gmail.com>
 <CABUeae9EOvum70788L4X5f2J_b0k9zxsCGAPmeV_8K_kmZEZhQ@mail.gmail.com>
Message-ID: <CABUeae_3Z=E8penTdG+6RWz+W_A2-D4bhfhqKeyxFeATeO31bg@mail.gmail.com>

On Wed, 31 Jul 2019 at 00:14, Mateusz Loskot <mateusz at loskot.net> wrote:
> On Mon, 5 Nov 2018 at 19:27, Mateusz Loskot <mateusz at loskot.net> wrote:
> > On Fri, 2 Nov 2018 at 06:11, Owen Pan <owenpiano at gmail.com> wrote:
> >
> > I noticed one issue which I wonder if it does qualify for a bug report:
> >
> > TL;TR: arrow followed by typename keyword is not handled
> >
> > Before:
> >
> > template <int K, typename E, typename L, int N>
> > auto bbbbbbbbbbbbbbbbbbbbbbb(detail::base<E, L, N>& p) -> typename
> > std::add_lvalue_reference<E>::type;
> >
> > After:
> >
> > template <int K, typename E, typename L, int N>
> > auto bbbbbbbbbbbbbbbbbbbbbbb(detail::base<E, L, N> &p) ->
> >     typename std::add_lvalue_reference<E>::type;
>
> FYI, I've reported it as a bug (took me a while!)
>
> https://bugs.llvm.org/show_bug.cgi?id=42835

Looks like thread inter-linking as not quite worked,
so here is old thread

http://lists.llvm.org/pipermail/cfe-users/2018-November/001421.html

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net


From cfe-users at lists.llvm.org  Tue Jul 30 16:25:04 2019
From: cfe-users at lists.llvm.org (Ayush Mittal via cfe-users)
Date: Tue, 30 Jul 2019 16:25:04 -0700
Subject: [cfe-users] AST Recursive Visitor- Statements (Stmt *)
Message-ID: <CA+OXOesMncmjiBnVJLogE=chXxuy80o4X+23xDfduTzsuTC44w@mail.gmail.com>

Hello Clangers,

I'm new to clang. I'm writing an AST Consumer plug-in to visit the
statements node and record the data in one of my table with line numbers.
I've this function callback ready: *VisitStmt(Stmt *S)*. My question is how
could I traverse If, while, for loop, boolean and Unary Operators- inside
this function.

Thanks and Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20190730/bd48676b/attachment.html>

From cfe-users at lists.llvm.org  Tue Jul 30 21:11:13 2019
From: cfe-users at lists.llvm.org (Richard Trieu via cfe-users)
Date: Tue, 30 Jul 2019 21:11:13 -0700
Subject: [cfe-users] AST Recursive Visitor- Statements (Stmt *)
In-Reply-To: <CA+OXOesMncmjiBnVJLogE=chXxuy80o4X+23xDfduTzsuTC44w@mail.gmail.com>
References: <CA+OXOesMncmjiBnVJLogE=chXxuy80o4X+23xDfduTzsuTC44w@mail.gmail.com>
Message-ID: <CAPUYKWnEx4ZF1i+tVoaZjg+hu=j8eb7F9X3kS5DQD_7gDL56Dw@mail.gmail.com>

Hi Ayush,

First, you need to know the classes associated with each of your target AST
nodes.  These are IfStmt, WhileStmt, ForStmt, BinaryOperator, and
UnaryOperator.  Each of these are sub-classes of Stmt.  IfStmt, WhileStmt,
ForStmt and direct sub-classes while BinaryOperator and UnaryOperator are
sub-classes of Expr, which is a sub-class of ValueStmt, which is a
sub-class of Stmt.  There's also two other related classes, CXXForRangeStmt
and DoStmt, which represent ranged-based for-loops and do/while loops.

Second, pointers can be changed between classes with the cast and dyn_cast
functions and Stmt::getStmtClass() will tell the type of the Stmt.  They
are used as follows:

void VisitStmt(Stmt *S) {
  if (BinaryOperator *BO = dyn_cast<BinaryOperator>(S)) {
    // Process BinaryOperator here
  } else if (UnaryOperator *UO = dyn_cast<UnaryOperator>(S)) {
    ...
  } // other checks here
}

void VisitStmt(Stmt *S) {
  switch (S->getStmtClass()) {
  case Stmt::BinaryOperatorClass: {
    BinaryOperator *BO = cast<BinaryOperator>(S);
    // Process BinaryOperator here
  }
  case Stmt::UnaryOperatorClass: {
    UnaryOperator *UO = cast<UnaryOperator>(S);
  }
  // Other cases here
  }
}

The difference between cast and dyn_cast is that cast expects the pointer
is the correct type without checking while dyn_cast does check the target
type and returns a null pointer on a type mismatch.  Chains of dyn_cast's
are used if the list of nodes is short while using a switch on
Stmt::getStmtClass() is used when checking a lot of node types.

There's also a third way.  Since you are already using a visitor, the
visitor will have a visit function for each AST node.  Instead of writing
just VisitStmt, you will write a VisitBinaryOperator(BinaryOperator *),
VisitUnaryOperator(UnaryOperator *), and so on for each one you're
interested in.  Hope this is enough to get you started.

On Tue, Jul 30, 2019 at 4:25 PM Ayush Mittal via cfe-users <
cfe-users at lists.llvm.org> wrote:

> Hello Clangers,
>
> I'm new to clang. I'm writing an AST Consumer plug-in to visit the
> statements node and record the data in one of my table with line numbers.
> I've this function callback ready: *VisitStmt(Stmt *S)*. My question is
> how could I traverse If, while, for loop, boolean and Unary Operators-
> inside this function.
>
> Thanks and Regards.
> _______________________________________________
> cfe-users mailing list
> cfe-users at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20190730/ff691ca6/attachment.html>

From cfe-users at lists.llvm.org  Wed Jul 31 06:12:43 2019
From: cfe-users at lists.llvm.org (Achilles Theodorakopoulos via cfe-users)
Date: Wed, 31 Jul 2019 16:12:43 +0300
Subject: [cfe-users] [clang-include-fixer]
Message-ID: <CALiZ9ydK4jOO4MGnGV4_rfhuXnwpr6dimNR5bmECu72AO3Gt5Q@mail.gmail.com>

Hi all,

I'd like to share something I believe is incorrect behavior (bug?) of
find-all-symbols from the clang-include-fixer

Consider the following header (filename is Type.h)

/* ----------------------------- */
#ifndef _TYPE_H
#define _TYPE_H

typedef struct SomeType {
   int a;
   int b;
} SomeType;

#endif
/* ----------------------------- */


Consider, also, main.c as follows:

/* ----------------------------- */
#include "Type.h"

static void func( void )
{
    SomeType obj2;

    struct SomeType obj1;
}
/* ----------------------------- */

And finally for ease of reproduction the compile_commands.json:

[
{
   "directory": "/home/me",
   "command": "/usr/bin/gcc -std=gnu90 -c /home/me/main.c",
   "file": "/home/me/main.c"
}
]

The result of running `find-all-symbols main.c` is the following

---
Name:        SomeType
Contexts:    []
FilePath:    '/home/me/Type.h'
Type:        TypedefName
Seen:        1
Used:        1
...

which appears to be missing the definition of struct SomeType

Notably, if the file is parsed as c++ (eg change "gcc" to "g++" and "gnu90"
to "gnu++98" above) then the result is

---
Name:        SomeType
Contexts:    []
FilePath:    '/home/me/Type.h'
Type:        Class
Seen:        1
Used:        2
...
---
Name:        SomeType
Contexts:    []
FilePath:    '/home/me/Type.h'
Type:        TypedefName
Seen:        1
Used:        1
...

which looks ok.

Is this a bug or is there something I'm missing?

Kind Regards,
Achilles T.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20190731/ca7983d9/attachment.html>