Kohsuke Kawaguchi wrote:
Another possible approach could be to use results of
DataflowInterpeter to find an instructions that are consuming given
stack value and then cast to the type required by this instruction,
but I am not sure if there are some gaps in this approach, e.g. if
locals
Kohsuke Kawaguchi wrote:
Actually your above example should be quite simple, especially if
we can assume that we know local variable types (e.g. debug
information is available):
Well, sure, if you can use debug information, but I don't think we can
assume that in javaflow, can we.
It
Kohsuke,
I've tried to run unit tests for asm transformer on code from SVN
and noticed that they all failing. I believe the reason is that you've
changed SimpleVerifier to BasicVerifier in the method analyzer and not
all of the checkcasts created with Object type. So, I am afraid that
Kohsuke,
I've noticed your comment in svn for ContinuationMethodAnalyzer class:
--
SimpleVerifier assumes that the types involved in the computation is
loadable through Class.forName(), which isn't true when we are running
inside Ant.
The correct computation would require us to parse
Kohsuke Kawaguchi wrote:
So if you don't mind, I'm happy to make the necessary changes.
Please go ahead. And if you don't mind please send me the test
results you'll get.
Will do.
I added a new property to select the transformer, and tried to use ASM.
I found a few issues.
-
Kohsuke Kawaguchi wrote:
- When moving 'new' instructions, local variables are allocated
excessively. I think it would be better for it to be used little more
conservatively. Namely, the number of additional local variables for
save/restore should be max of all constructor parameter counts,
