From: Arnaud Charlet <charlet@adacore.com>
To: Aldy Hernandez <aldyh@redhat.com>
Cc: joseph@codesourcery.com, lopezibanez@gmail.com,
gcc-patches@gcc.gnu.org, jason@redhat.com,
Arnaud Charlet <charlet@adacore.com>
Subject: Re: [patch] initial location support for C parser
Date: Sat, 23 Aug 2008 11:34:00 -0000 [thread overview]
Message-ID: <20080823072216.GA86953@adacore.com> (raw)
In-Reply-To: <20080822215202.GA13803@redhat.com>
> Here is a patch/RFC before I go any further.
Thanks for putting me in the loop BTW.
> My plan here is to make all the build* routines in the parser take a
> location, and fix everything else accordingly, eventually getting rid of
> input_location. Arnaud and Manuel are tackling similar tasks, I hope we
> can work in tandem.
Indeed, this seems to go as a complementary (or possibly partly overlapping).
This means that I should probably start sending my patches soon as well.
Note that if people feel this is not a good time to commit such patches, maybe
we should consider starting a branch (just a thought).
> With this initial patch I noticed that to come up with suitable tests
> for all this, I would have to basically write an entire ISO C
> comformance test, something which is perhaps beyond the scope of my
> work. I would like to fix existing tests as I go, and perhaps add new
> ones when it is obvious how to add new tests. Sometimes I noticed it
> was incredibly hard to contrive a test for a particular location we were
> setting. I hope we can come to a middle ground here-- I doubt I have
> the time, desire, or inclination to write an entire comformance suite.
Right.
Note that a better way to check line and column information may be to use some
kind of tree dump pass and check the result against e.g. a baseline.
For instance, I am working on generating relatively complete xref source
information, so using this xref dump could be a good basis for checking
line and column numbers generated by the front-ends in a pretty exhaustive
way.
Arno
next prev parent reply other threads:[~2008-08-23 7:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-22 23:10 Aldy Hernandez
2008-08-23 11:34 ` Arnaud Charlet [this message]
2008-08-25 11:35 ` Aldy Hernandez
2008-08-25 15:03 ` Arnaud Charlet
2008-08-28 23:58 ` Joseph S. Myers
2008-09-01 15:08 ` Aldy Hernandez
2008-09-01 19:33 ` Andreas Tobler
2008-09-01 19:48 ` Jakub Jelinek
2008-09-02 11:40 ` Aldy Hernandez
2008-09-02 22:10 ` Aldy Hernandez
2008-09-02 22:24 ` Jakub Jelinek
2008-09-02 22:35 ` Manuel López-Ibáñez
2008-09-02 22:48 ` Jakub Jelinek
2008-09-02 22:48 ` Richard Henderson
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=20080823072216.GA86953@adacore.com \
--to=charlet@adacore.com \
--cc=aldyh@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=joseph@codesourcery.com \
--cc=lopezibanez@gmail.com \
/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).