Re: [abc] Jastadd compile bugs

From: Neil Ongkingco <neil.ongkingco@keb.ox.ac.uk>
Date: Thu Jan 12 2006 - 15:00:44 GMT

I've attached one more jastadd bug. Note that the comments are just my
best guesses on what the problem is, as I haven't really tried to debug
the jastadd compiler code yet. As with the other examples, this compiles
fine in both javac and abc.

I'm getting the impression that there seems to be a good number of bugs
that need fixing, and that it may not as yet be worth moving to jastadd.
There are still some bugs that I haven't isolated yet (including a
rather strange one that says "primitive.Illegal is not assignable to a
variable of type primitive.Unknown"), so there may be more to come.

Neil

Pavel Avgustinov wrote:

>Neil Ongkingco wrote:
>
>
>
>>Attached are some jastadd bugs found when compiling using Jigsaw.
>>Perhaps they will help in deciding whether we should switch. All
>>examples compile fine in both javac and abc. I'm still just halfway
>>through jastadd's error dump, so I might add some more bugs later today.
>>
>>
>>
>Some remarks on the test cases below.
>
>
>
>>class CharByteTest {
>> public static void main(String args[]) {
>> byte a = 100;
>> System.out.println("Hello world");
>> //Jastadd does not properly recognize the cast, and insists
>> //that the type of the expression is still a char
>> a = (byte) (a - 'a');
>> }
>>}
>>
>>
>>
>>
>The comment about the problem in JastAdd is misleading. It's not the
>cast that confuses it; rather, it tries to add the byte a to the char
>'a' without performing binary numeric promotion
>(http://java.sun.com/docs/books/jls/second_edition/html/conversions.doc.html#170983),
>i.e. without converting both to int first. Thus it ends up with
>mismatched types on the '-' operation, not on the assignment back to a.
>Casting the first operand to char or the second to byte ensures
>compilability with jastadd. It is interesting that if one changes the
>expression to "a = (char) a - 'a';", then jastadd complains that it
>can't assign int to byte, i.e. it does do some promotion of its
>arguments, but seemingly too late.
>
>
>
>>import java.io.*;
>>
>>class FinallyTest {
>> //Jastadd gives a false error report if more than one exception
>> //is specifified in the signature. Removing InterruptedException
>> //allows Jastadd to compile properly
>> public static void a() throws IOException, InterruptedException {
>> throw new IOException("FinallyTest.a");
>> }
>>
>> public static void main(String args[]) throws Exception{
>> try {
>> a();
>> } finally {
>> try {
>> a();
>> } catch (IOException e) {}
>> }
>> }
>>}
>>
>>
>>
>>
>This is indeed rather strange -- the error JastAdd reports is that the
>body of the catch block is unreachable, and indeed this is reported
>whenever a() is declared to throw more than one exception, whether or
>not it is declared to throw IOException. No idea about this one.
>
>
>
>>class ClassTest {
>> static {
>> //Jastadd doesn't lookup names properly in static blocks
>> Class c = ClassTest.class;
>> }
>> public static void main(String args[]) {
>> }
>>}
>>
>>
>>
>>
>Again, the comment about the problem is misleading. The problem here is
>in JastAdd-generated code. The exact error message is "*** Semantic
>Error: variable class$ClassTest is used in static { Class c =
>class$ClassTest != null ? class$ClassTest : class$ClassTest =
>class$("ClassTest"); } before it is declared". Interestingly if one
>drops the static block, this works correctly -- perhaps the (generated)
>class$ClassTest variable isn't static itself?
>
>
>

>>class ClassTest2 {
>> //Jastadd also has lookup problems for static variables
>> static Class cn = ClassTest2.class;
>> public static void main(String args[]) {
>> }
>>}
>>
>>
>>
>>
>This is identical to above (in fact, though I may be wrong, I think the
>bottom form is syntactic sugar for the top). It certainly produces the
>same error message.
>
>
>The problem me and Julian have been talking about is demonstrated by
>this simple test case:
>
>public class Test {
> public static void main(String[] args) {
> StringBuffer b = new StringBuffer();
> b.append('-');
> }
>}
>
>When compiled with a Java 1.4 JVM, this works fine. Under a Java5 JVM,
>JastAdd can't compile it -- it complains about an uncaught IOException
>on the call to append(). The reason is that the Java 5 API introduces an
>Appendable interface with a method 'Appendable append(char c) throws
>IOException', and StringBuffer implements Appendable. The method lookup
>ends up returning the method from the interface rather than the
>StringBuffer class, and so exception behaviour is considered incorrect.
>This is actually quite nasty, because a lot of String manipulations get
>compiled down to StringBuffer actions, so this prevents the compilation
>of many many programs in a Java5 environment.
>
>I'll summarise any other problems in this thread; we should send it to
>Torbjorn for comments/fixes when we've finalised it.
>
>- P
>
>
>
>

import java.util.*;

class ArrayTest {
        public static void main(String args[]) {
                byte[] row = new byte[10];
                Vector v = new Vector(10);
                byte[][] varr = new byte[10][];
                //jastadd seems to have a problem with n-dim arrays, n>1.
                v.copyInto(varr);

                //jastadd compiles 1D arrays fine
                Vector v2 = new Vector(10);
                Integer[] v2arr = new Integer[10];
                v2.copyInto(v2arr);
        }
}
Received on Thu Jan 12 15:00:46 2006

This archive was generated by hypermail 2.1.8 : Thu Jan 12 2006 - 15:20:09 GMT