java/1438: Problem with jv-scan --print-main

[green@cygnus.com]

>Number:         1438
>Category:       java
>Synopsis:       Problem with jv-scan --print-main
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    tromey
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 20 12:19:51 PST 2000
>Closed-Date:    Mon Oct 04 13:36:54 PDT 1999
>Last-Modified:  Mon Oct  4 13:50:03 PDT 1999
>Originator:     Anthony Green
>Release:        GCC trunk
>Organization:
>Environment:
Debian x86 Linux 2.1
>Description:
jv-scan --print-main libjava/testsuite/libjava.lang/Primes.java
does not work.
This affect the `make check' test results because
the testsuite depends on this functionality.
>How-To-Repeat:
jv-scan --print-main libjava/testsuite/libjava.lang/Primes.java
>Fix:

>Release-Note:

>Audit-Trail:

Formerly PR gcj/59


From: Tom Tromey <tromey@cygnus.com>
To: Anthony Green <green@cygnus.com> 
Cc: Java Gnats Server <java-gnats@sourceware.cygnus.com> ,
    Alexandre Petit-Bianco <apbianco@cygnus.com> 
Subject: gcj/59
Date: 04 Oct 1999 14:19:26 -0600

 I've looked at this a bit.
 
 jv-scan won't report any syntax errors it thinks it finds in the
 source.  Is this a bug?  I don't know.  I modified my local jv-scan to
 print error messages, and I got this:
 
     creche. jv-scan --print-main Primes.java
     Primes.java: 133: parse error
 
 This reveals a bug in parse-scan.y, which I haven't yet tracked down.
 I believe it is related to the declaration of the loop variable in the
 first argument to the `for'.
 
 This method of maintaining parse-scan.y is very brittle.  Is there
 some other approach we could take?
 
 Tom

From: Tom Tromey <tromey@cygnus.com>
To: Anthony Green <green@cygnus.com> 
Cc: Java Gnats Server <java-gnats@sourceware.cygnus.com> ,
    Alexandre Petit-Bianco <apbianco@cygnus.com> 
Subject: gcj/59
Date: 04 Oct 1999 14:24:54 -0600

 My guess about the bug was wrong.
 Instead it has to do with the `+=' on the line in question.
 
 Tom
Responsible-Changed-From-To: apbianco->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Mon Oct  4 13:36:54 1999
Responsible-Changed-Why:
    I fixed it
State-Changed-From-To: open->closed
State-Changed-By: tromey
State-Changed-When: Mon Oct  4 13:36:54 1999
State-Changed-Why:
    I checked in a fix for this.  I tried it on your
    test case, so I'm closing this directly.
    Re-open it if you find a failure.

From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: java-gnats@sourceware.cygnus.com
Cc:  
Subject: Re: gcj/59
Date: Mon, 4 Oct 1999 13:43:57 -0700 (PDT)

 Tom Tromey writes:
 
 >  This method of maintaining parse-scan.y is very brittle.  Is there
 >  some other approach we could take?
 
 Well, the macro JC1_LITE allows us to use lex.{c,h} and parse.h. I
 guess we could easily tweak parse.y and get rid of parse-scan.y. I'm
 making a note to look at it.
 
 ./A
 
 
>Unformatted: