From: Ian Lance Taylor <iant@google.com>
To: mefyl <mefyl@gruntech.org>
Cc: gcc-help@gcc.gnu.org
Subject: Re: GCC plugins: mapping AST back to source files, missing locations.
Date: Fri, 19 Oct 2012 00:19:00 -0000 [thread overview]
Message-ID: <CAKOQZ8xPR8mDTKJc2qyEDt67-QUS8pPPqAaDzmSsaZS0_xC5bw@mail.gmail.com> (raw)
In-Reply-To: <2075037.saGV1fzbJA@lust.mefyl.net>
On Thu, Oct 18, 2012 at 9:34 AM, mefyl <mefyl@gruntech.org> wrote:
>
> * I can retrieve source file location of declarations with
> DECL_SOURCE_LOCATION without any problem, but I can't get locations for
> expressions since their EXPR_LOCATION is always null. I used the
> PLUGIN_PRE_GENERICIZE hook, which AFAIK is the earliest, so I expected
> locations to still be there. Did I miss something, or is there no way to
> retrieve such locations from plugins, in which case my example seems
> impossible ?
Most expressions should have locations these days. It is certainly
true that there will be some that do not. Hard to say more without
more details.
> * Even if we suppose I fixed the previous issue, from what I inferred from the
> AST, a reference to a variable is directly represented by the corresponding
> VAR_DECL. That is, in "int x; int y; x + y;", "x + y" is a PLUS_EXPR whose
> operands are the VAR_DECL corresponding to "int x" and "int y". This would
> make it impossible for me to get the location of "x" and "y", since they are
> not represented as such by nodes in the AST.
That is correct.
> I fear that due to the compiler nature of GCC, the AST I'm working on is
> altered, with some processing and simplification already applied, preventing
> source-to-source code transformation since one cannot map ast chunks back to
> source files. Could anyone confirm or point me in some direction if I'm wrong
> ? In the case it's indeed impossible, is there any intent to improve this
> aspect, like giving access to earlier stages of the AST (freshly parsed, with
> only variable bindings for instance) ? This would enable to write extremely
> powerfull analysis & refactoring tools.
Unfortunately the GCC AST almost certainly does not retain enough
information for the kind of transformations you want to do. This is a
deficiency in the AST, but I can't even estimate how difficult it
would be to fix.
Ian
next prev parent reply other threads:[~2012-10-18 18:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-18 20:08 mefyl
2012-10-19 0:19 ` Ian Lance Taylor [this message]
2012-10-22 12:31 ` mefyl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKOQZ8xPR8mDTKJc2qyEDt67-QUS8pPPqAaDzmSsaZS0_xC5bw@mail.gmail.com \
--to=iant@google.com \
--cc=gcc-help@gcc.gnu.org \
--cc=mefyl@gruntech.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).