public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).