public inbox for java-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Gcc Patch List <gcc-patches@gcc.gnu.org>
Cc: Java Patch List <java-patches@gcc.gnu.org>
Subject: Re: [ecj] Patch: remove old .java parser
Date: Sat, 23 Dec 2006 02:46:00 -0000	[thread overview]
Message-ID: <m3bqlvbg1q.fsf@localhost.localdomain> (raw)
In-Reply-To: <m3bqlypjry.fsf@localhost.localdomain>

Tom> I'm going to check this in on the gcj-eclipse-merge-branch.
Tom> Andrew, if you could give it a look over first, that would be helpful.

Tom> This is the first step at removing the old .java parser and other
Tom> now-unused code from gcj.  There is still some unused code remaining,
Tom> and a few bits which I simply commented out.  I'll have more cleanups
Tom> in future patches.

On irc Andrew asked about how I decided what to remove.  It is a fair
question and I do have an answer, albeit a somewhat ugly one.

I started at the obvious starting place: delete every file which ought
to be deletable.  So, I removed the parser, the lexer, and
check-init.c (definite assignment is only needed for source analysis).
Then I removed supporting files (keyword, character tables) and random
files which have long been obsolete (buffer.[ch] and convert.h).

Then I started building gcj and seeing what broke.  If the code was
related only to parsing source files, I generally removed it.  Since
over the years gcj has not been maintained with perfect cleanliness,
sometimes java-source-language-related functions ended up in the wrong
files; there were also a few already dead things lying about.

When I determined either via compilation or later testing that a given
function was wrongly deleted, I resurrected it (eg cxx_keyword_p stuff
in the name mangler).

The only really odd bit here was java_layout_seen_class_methods, which
was in parse.y but which is needed for proper operation of the .class
compiler.  You can see all the resurrected functions by searching for
"New function" in the ChangeLog.

At this point I had a working compiler which could build libgcj and
pass all tests.  Then I worked my way through parse.h, java-tree.h,
and java-tree.def, deleting every declaration, definition, or macro
which appeared not to be in use by the remaining parts of the
compiler.  There were a couple surprises here, since things like
URSHIFT_EXPR turn out to only be referenced via token pasting... yay.
If a deleted macro referred to a field in some structure, I removed
the field as well.

This is by no means a complete patch.  However, it is a good start.  I
think it removed around 50% of the source lines in gcj.

Tom

      reply	other threads:[~2006-12-23  2:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-20 19:18 Tom Tromey
2006-12-23  2:46 ` Tom Tromey [this message]

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=m3bqlvbg1q.fsf@localhost.localdomain \
    --to=tromey@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=java-patches@gcc.gnu.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).