On Tue, May 18, 2010 at 12:15 PM, Hans-Martin Mosner <hmm@heeg.de> wrote:

Hello,
while looking at the decompiled code of some OMeta methods I noticed
that the temp name handling in the decompiler seems to be broken.
When you compile a method with temps that are referenced from blocks,
the decompiler tends to rearrange the temp names, so this method

test
| one two |
two := 2.
^{[one := 1].
[ [one + two] value]}

gets decompiled to this:

test
| one two |
one := 2.
^ {[two := 1]. [[two + one] value]}

OK, the issue in Squeak 4.1 is that the CodeHolder>>decompiledSourceIntoContents method is out of date. Find attached.

But that's only a nuisance. The bug really shows up when you decompile a
method compiled using OMeta.
To see what I mean, load the OMeta2 package and have a look at method
OMeta2AndOrOpt>>and.

Any way of reproducing this without OMeta, e.g. in a workspace?

e.g. to test the above I used things like

| mn m |

mn := Compiler new compile: 'test

| one two |

two := 2.

^{[one := 1].

[ [one + two] value]}' in: nil class classified: nil notifying: nil ifFail: nil.

m := (mn generate: #(0 0 0 0)) copyWithTempsFromMethodNode: mn.

{m decompile. m tempNamesString}

where in 4.1 "generate: #(0 0 0 0)" needs to be replaced with "generate: CompiledMethodTrailer defaultMethodTrailer" (although asMethodTrailer on ArrayedCollection would be nice for backward-compatibility).

Cheers,
Hans-Martin