[cfe-dev] Include Default C++ paths
Mohammad Adil
madil90 at gmail.com
Thu Oct 18 10:36:13 PDT 2012
I can't modify "createFromArgs" function of CompilerInvocation. I am not
sure why it's putting C++ paths at the end. Can you think of any reason?
Are there any other examples on Tooling which explore some other Actions
etc. I am especially looking for something that enables me to rewrite the
code. I am very grateful for your help.
Regards,
Mohammad Adil
On Thu, Oct 18, 2012 at 10:29 PM, Sean Silva <silvas at purdue.edu> wrote:
> > My use case currently requires me to be able to parse the AST. As I
> > mentioned, I almost have the problem solved. I modified the
> > "createInvocationFromCommandLine" function and added
> > "TheDriver.CCCIsCXX=true". The only problem is that the args in the
> > CompilerInvocation object created are not in the correct order. All the
> C++
> > include arguments are put AFTER the source file and so they are not
> working.
> > The "createInvocationFromArgs" is doing this. Is there any way this can
> be
> > remedied?
>
> If you have copied the function why not just write some code to
> rearrange things to be like you want?
>
> > On a completely different note, Can this be done using Libtooling? If
> > yes, Can you please provide a small example. There is rarely any
> > documentation on LibTooling and the Tooling API is much harder to
> understand
> > than normal Clang API which is much more intuitive.
>
> There is an example at <http://clang.llvm.org/docs/LibTooling.html>.
>
> -- Sean Silva
>
> On Thu, Oct 18, 2012 at 1:05 PM, Mohammad Adil <madil90 at gmail.com> wrote:
> > My use case currently requires me to be able to parse the AST. As I
> > mentioned, I almost have the problem solved. I modified the
> > "createInvocationFromCommandLine" function and added
> > "TheDriver.CCCIsCXX=true". The only problem is that the args in the
> > CompilerInvocation object created are not in the correct order. All the
> C++
> > include arguments are put AFTER the source file and so they are not
> working.
> > The "createInvocationFromArgs" is doing this. Is there any way this can
> be
> > remedied?
> >
> > On a completely different note, Can this be done using Libtooling? If
> > yes, Can you please provide a small example. There is rarely any
> > documentation on LibTooling and the Tooling API is much harder to
> understand
> > than normal Clang API which is much more intuitive.
> >
> > Regards,
> > Adil
> >
> >
> > On Thu, Oct 18, 2012 at 9:58 PM, Sean Silva <silvas at purdue.edu> wrote:
> >>
> >> Another problem that you are likely to run into is that there are some
> >> headers like stddef.h which are looked for in a hardcoded path
> >> relative to the binary itself, so you must either hardcode the path on
> >> your system in some way, or run your tool only in particular
> >> directories.
> >>
> >> The problem that you are having is probably the #1 most annoying thing
> >> for me about clang. When I was getting started with clang I spent more
> >> time than I wish to admit on exactly what you are trying to do now,
> >> and basically my conclusion was that Clang does not support this use
> >> case currently (i.e., using clang as a library to simply parse an
> >> arbitrary C++ file and then do stuff with the AST or whatever).
> >> libTooling was not around back then, so libTooling might be a way to
> >> accomplish what you want. You are going to waste a lot of time if you
> >> try to manually do this though---I certainly did.
> >>
> >> Someday, we may be able to say ParseFile("foo.cpp") which just gives
> >> you the ASTContext for the parsed file, but we currently do not, and
> >> it is a *really*, **really** hard problem to be able to make something
> >> like that "just work".
> >>
> >> A plugin is a way to get around this though, but your tool may or may
> >> not fit into the plugin model. If all you want though is to get the
> >> ASTContext and do something with it, then a plugin is the way to go
> >> currently.
> >>
> >> -- Sean Silva
> >>
> >> On Thu, Oct 18, 2012 at 3:22 AM, Mohammad Adil <madil90 at gmail.com>
> wrote:
> >> > I've been looking at the source code of the Driver. What I have
> >> > understood
> >> > till now is that the driver is created for the platform we are working
> >> > on.
> >> > The driver can then build a compilation object from a list of
> >> > arguments.
> >> > Inside this compilation object, there exists a toolchain specific to
> the
> >> > platform (e.g. Linux in my case) which has the job of inserting
> correct
> >> > system and C++ include paths. Is that correct? Let us say that I have
> >> > build
> >> > such a compilation object. How can I create a CompilerInvocation or
> >> > CompilerInstance out of this such that it includes the information
> about
> >> > all
> >> > default C and C++ paths? I see no way of using the driver to just
> create
> >> > an
> >> > AST and parse it so the only way is to create a Driver and somehow
> >> > create a
> >> > CompilerInstance out of it.
> >> >
> >> >
> >> > On Thu, Oct 18, 2012 at 1:09 AM, Manuel Klimek <klimek at google.com>
> >> > wrote:
> >> >>
> >> >> On Wed, Oct 17, 2012 at 6:50 PM, David Blaikie <dblaikie at gmail.com>
> >> >> wrote:
> >> >>>
> >> >>> (readding cfe-dev)
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Wed, Oct 17, 2012 at 9:42 AM, Mohammad Adil <madil90 at gmail.com>
> >> >>> wrote:
> >> >>> > What I am trying to do is to make a small program which parses the
> >> >>> > AST
> >> >>> > and
> >> >>> > does some rewriting to output modified code. How will I use the
> >> >>> > Driver
> >> >>> > in
> >> >>> > this case? All I want to do is to parse the AST.
> >> >>>
> >> >>> I don't know off-hand what the best way to integrate the Driver's
> >> >>> lib/header discovery is, just that that's where the logic is.
> >> >>>
> >> >>> The focus of Clang development with regard to "tools" like the one
> you
> >> >>> described is the Tooling infrastructure (overview of options & a
> link
> >> >>> to libTooling-specific information can be found here:
> >> >>> http://clang.llvm.org/docs/Tooling.html ). I'm not sure if that
> meets
> >> >>> the "standalone execution" scenario that you seem to be going for -
> >> >>> it's ideally meant to integrate with code already building using an
> >> >>> existing build system that has been modified to generate a database
> of
> >> >>> compilation commands. I /think/ it should also work standalone &
> still
> >> >>> do all the driver-based discovery, but I could be wrong.
> >> >>
> >> >>
> >> >> It does not fully do the driver-based discovery, but it'll usually
> work
> >> >> with the same flags that you provide to a normal clang call - and you
> >> >> can
> >> >> always specify options after "--" if you build the tool like in the
> >> >> tutorials.
> >> >>
> >> >> Cheers,
> >> >> /Manuel
> >> >>
> >> >>>
> >> >>>
> >> >>> > On Wed, Oct 17, 2012 at 9:39 PM, David Blaikie <
> dblaikie at gmail.com>
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> On Wed, Oct 17, 2012 at 9:29 AM, madil90 <madil90 at gmail.com>
> wrote:
> >> >>> >> > Hi,
> >> >>> >> > I am trying to parse a C++ code but clang doesn't recognize
> >> >>> >> > the
> >> >>> >> > C++
> >> >>> >> > types. Consider the following code
> >> >>> >> >
> >> >>> >> > #include <iostream>
> >> >>> >> > #include <string>
> >> >>> >> >
> >> >>> >> > int main()
> >> >>> >> > {
> >> >>> >> > string str;
> >> >>> >> > }
> >> >>> >> >
> >> >>> >> > clang gives an error at <iostream> and doesn't recognize the
> >> >>> >> > string
> >> >>> >> > type. To
> >> >>> >> > enable C++, I did "langOptions.CPlusPlus=1" and the code
> >> >>> >> > recognizes
> >> >>> >> > custom
> >> >>> >> > C++ classes. So how do I include default C++ paths?
> >> >>> >>
> >> >>> >> I assume you're using clang as a library, rather than actually
> >> >>> >> going
> >> >>> >> through the clang driver? The driver's where all (most) of the
> >> >>> >> header
> >> >>> >> search logic is. You can extract the paths by simply asking clang
> >> >>> >> what
> >> >>> >> command it used to invoke the frontend (I forget offhand, but
> there
> >> >>> >> is
> >> >>> >> a verbose/print-commands option to clang) & just pass those in.
> But
> >> >>> >> if
> >> >>> >> you want to make a tool using clang as a library & have the same
> >> >>> >> header/lib discovery that the clang command line program has,
> you'd
> >> >>> >> need to duplicate or reuse the logic in the driver.
> >> >>> >>
> >> >>> >> - David
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > --
> >> >>> > Mohammad Adil
> >> >>> > LUMS SSE
> >> >>> >
> >> >>>
> >> >>> _______________________________________________
> >> >>> cfe-dev mailing list
> >> >>> cfe-dev at cs.uiuc.edu
> >> >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Mohammad Adil
> >> > LUMS SSE
> >> >
> >> >
> >> > _______________________________________________
> >> > cfe-dev mailing list
> >> > cfe-dev at cs.uiuc.edu
> >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >> >
> >
> >
> >
> >
> > --
> > Mohammad Adil
> > LUMS SSE
> >
>
--
Mohammad Adil
LUMS SSE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121018/f72153df/attachment.html>
More information about the cfe-dev
mailing list