On Mon, Apr 5, 2010 at 10:37 AM, Andreas Raab <andreas.raab at gmx.de> wrote:

> On 4/5/2010 4:04 AM, Levente Uzonyi wrote:
>
>> It's a decompiler bug. Eliot has fixes for these issues but I don't know
>> if he has time to add them to the Trunk.
>>
>
> I just spoke with Eliot and it seems unlikely that he'll have much time to
> work on this. Also, there are cases that the decompiler handles correctly,
> but differently from the compiler.
>
> Eliot's recommendation to extent DecompilerTests>>decompilerFailures with
> the failing sites.
>

Some saintly person should go through the failures and add to
decompilerFailures all those that fail because of known limitations in the
decompiler.  These limitations are things like

Floating point reader precision, e.g. the source specifies more precision
than is supported and so the compilation of the decompilation is slightly
different.

Unreachable statements. e.g. foo ifTrue: [^bar] ifFalse: [^baz]. ^huh?
decompiles as foo ifTrue: [^bar] ifFalse: [^baz]. and so ^'huh?' is missing.

Null statements.  e.g. foo ifTrue: []. decompiles as foo.  which, if foo is
an inst var, compiles as empty.

These are limitations in the decompiler we simply have to tolerate.
 decompilerFailures is a list that documents the reasons for failure.

Of course another, also valid, approach is to fix the code in the failures
so that they don't contain unreachable or null statements.

HTH
Eliot





>
> Cheers,
>  - Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100405/7799ce9a/attachment.htm