Re: [abc-dev] Fwd:

From: Chris Allan <mrchrisallan_at_googlemail.com>
Date: Thu, 11 Sep 2008 17:32:04 +0100

Great!

So, I hate to say it, but I've got another issue. If these emails are
becoming more annoying than useful, let me know and I'll just add an entry
to bugzilla and leave you guys in peace!

Anyway, the following file gives an error when running abc over the
generated classes:

import java.lang.annotation.*;
@Retention(RetentionPolicy.RUNTIME)
public @interface A{}

@A
public enum B
{
    C
}

Errors:

Jimplify2
Transforming A...
Transforming B...
Writing to c:\temp\test-target1\A.class
Jasmin:19: Warning - Syntax error.

^
Jasmin:19: Error - Couldn't repair and continue parse.

^
Jasmin: Found 2 errors
Writing to c:\temp\test-target1\B.class
Jasmin:16: Warning - Syntax error.

^
Jasmin:16: Error - Couldn't repair and continue parse.

^
Jasmin: Found 2 errors
abc finished on Thu Sep 11 17:29:56 BST 2008. ( 0 min. 3 sec. )

Chris

On Thu, Sep 11, 2008 at 4:35 PM, Pavel Avgustinov <pavel_at_comlab.ox.ac.uk>wrote:

> Ah, of course. Sorry, I should have thought to check the same problem for
> methods. Fixed in latest svn head.
>
> - P
>
> On Thursday 11 September 2008 16:20:50 Chris Allan wrote:
> > Wow, that was quick!
> >
> > Unfortunately, I've now hit a very similar involving methods with
> > annotations (replace the variable 'i' in my example with a method
> > definition to reproduce). I know you guys are busy, so please don't rush
> > to fix it for my benefit if you have other things to do - just let me
> know
> > if/when you have time to fix it, and I'll see how much further I can get.
> >
> > Exception in thread "main" polyglot.util.InternalCompilerError: unhandled
> > exception during
> > compilation
> > at abc.main.CompileSequence.runSequence(CompileSequence.java:110)
> > at abc.main.Main.run(Main.java:406)
> > at abc.main.Main.main(Main.java:144)
> > Caused by: java.lang.NullPointerException
> > at abc.ja.jrag.MethodDecl.addAttributes(MethodDecl.java:397)
> > at abc.ja.jrag.MethodDecl.jimplify1phase2(MethodDecl.java:353)
> > at abc.ja.jrag.TypeDecl.jimplify1phase2(TypeDecl.java:1061)
> > at abc.ja.jrag.ClassDecl.jimplify1phase2(ClassDecl.java:430)
> > at abc.ja.jrag.ASTNode.jimplify1phase2(ASTNode.java:601)
> > at abc.ja.jrag.ASTNode.jimplify1phase2(ASTNode.java:601)
> > at abc.ja.jrag.Program.jimplify1(Program.java:898)
> > at abc.ja.CompileSequence.compile(CompileSequence.java:118)
> > at abc.main.CompileSequence.runSequence(CompileSequence.java:100)
> > ... 2 more
> >
> >
> > Chris
> >
> > On Thu, Sep 11, 2008 at 3:18 PM, Pavel Avgustinov
> <pavel_at_comlab.ox.ac.uk>wrote:
> > > Hi all,
> > >
> > > On Thursday 11 September 2008 14:52:01 Eric Bodden wrote:
> > > > Hi all.
> > > >
> > > > 2008/9/11 Chris Allan <mrchrisallan_at_googlemail.com>:
> > > > > I had a very quick look at what was going on, and it seems that
> when
> > > > > processing the .class files, the field
> > > > > abc.ja.jrag.FieldDeclaration.sootField never gets set, because the
> > > > > conditional at FieldDeclaration line 329 [
> > > > > if(!hostType().getSootClassDecl().declaresFieldByName(name)) ]
> > > > > returns false when looking for the field 'i' - when compiling from
> > > > > source, this expression evaluates to true. I don't know what the
> > > > > significance of
> > >
> > > this
> > >
> > > > > is though, so I gave up investigating! Please let me know if I can
> > > > > provide any more information.
> > >
> > > Thanks for this, Chris. It was very helpful in helping us track down
> the
> > > bug!
> > > I and Torbjorn have fixed it in current svn head. Please let us know if
> > > you run into any more trouble!
> > >
> > > > To my understanding the error occurs somewhat earlier in the
> > > > compilation process. If I am not mistaken then JastAdd should not
> even
> > > > touch these files at all because they are read in from bytecode and
> > > > JastAdd is only meant to handle .java files.
> > >
> > > Unfortunately, that is a little inaccurate, since ITD weaving happens
> in
> > > the
> > > JastAdd part of the compiler. As such, JastAdd potentially needs to
> > > modify any weavable class file, and so all weavable bytecode is loaded
> > > and jimplified by JastAdd. I'm sorry I didn't correct this
> misconception
> > > when you
> > > mentioned it in response to one of Chris's earlier emails -- it
> probably
> > > would have saved you some confusion!
> > >
> > > Best wishes,
> > > - Pavel
>
>
>
>
Received on Thu Sep 11 2008 - 17:32:08 BST

This archive was generated by hypermail 2.2.0 : Tue Sep 30 2008 - 23:50:14 BST