On Mon, 5 Apr 2010, Eliot Miranda wrote:

> 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.

What about the "real" bugs when the decompiler cannot reproduce the 
declaration of temporiaries (for example EventSensor >> #eventTickler)?


Levente

>
> HTH
> Eliot
>
>
>
>
>
>>
>> Cheers,
>>  - Andreas
>>
>>
>