Compiler+Decompiler together have a serious 'bad case' bug

> Sorry, hyperlink is
>
> - http://bugs.impara.de/view.php?id=4313
>
> /Klaus
>
> On Sat, 22 Jul 2006 23:37:07 +0200, Klaus D. Witzel  
> <[hidden email]> wrote:
>
>> http://bugs.impara.de/view.php?id=2921
>>
>> You can provoke the emergency console by having Decompiler fail  
>> with self error:'bad case' in #send:super:numargs.
>>
>> The following trivial, innocent looking code snippet does it in  
>> 3.8 and 3.9:
>>
>> | x y |
>>   x := y := 0.
>> {'a'. 'b'. 'c'} do: [:c|
>>      (c string halt; endsWith: 'd')
>>          ifTrue: [x:= 1 + x]
>>          ifFalse: [y:= 1 + y]]
>>
>> Strange, why should Decompiler be involved in a halt situation,  
>> and then, why should it refuse to decompile code?
>>
>> /Klaus
>>
>>
>>
>
>
>

> On Sun, 23 Jul 2006 16:52:01 +0200, Marcus Denker  
> <[hidden email]> wrote:
>> On 23.07.2006, at 16:31, Bert Freudenberg wrote:
>>> Am 22.07.2006 um 23:42 schrieb Klaus D. Witzel:
>>>
>>>> Strange, why should Decompiler be involved in a halt situation
>>>
>>> I guess because there is no method source if you evaluate the code
>>> in a workspace.
>
> Good guess but I found the error in a regular .changes file source  
> coded method.
>
>> Printing of blocks for the stack-trace shown in the pre-debug window
>> nees the
>> decompiler...
>
> Strange, all source code is available.

> Decompiler recompileAllTest
>
> - Bert -
>
> Am 23.07.2006 um 23:16 schrieb Klaus D. Witzel:
>
>> It works, your and my example no longer fail.
>>
>> Is there a routine to check the modified Decompiler against all source  
>> coded methods?
>>
>> /Klaus
>>
>> On Sun, 23 Jul 2006 16:23:31 +0200, Bert Freudenberg wrote:
>>
>>> Simpler test case - in a Browser, add this method:
>>>
>>> test
>>> (self foo; bar)
>>> ifTrue: [1]
>>> ifFalse: [2]
>>>
>>> Then switch to "decompile" instead of "source".
>>>
>>> If the receiver of an ifTrue:ifFalse: is a cascade, the decompiler
>>> mistakes it for a case statement. I attached a fix for that, could
>>> someone please verify?
>>>
>>> - Bert -
>>>
>>>
>>> Am 22.07.2006 um 23:42 schrieb Klaus D. Witzel:
>>>
>>>> Sorry, hyperlink is
>>>>
>>>> - http://bugs.impara.de/view.php?id=4313
>>>>
>>>> /Klaus
>>>>
>>>> On Sat, 22 Jul 2006 23:37:07 +0200, Klaus D. Witzel
>>>> <[hidden email]> wrote:
>>>>
>>>>> http://bugs.impara.de/view.php?id=2921
>>>>>
>>>>> You can provoke the emergency console by having Decompiler fail
>>>>> with self error:'bad case' in #send:super:numargs.
>>>>>
>>>>> The following trivial, innocent looking code snippet does it in
>>>>> 3.8 and 3.9:
>>>>>
>>>>> | x y |
>>>>>   x := y := 0.
>>>>> {'a'. 'b'. 'c'} do: [:c|
>>>>>      (c string halt; endsWith: 'd')
>>>>>          ifTrue: [x:= 1 + x]
>>>>>          ifFalse: [y:= 1 + y]]
>>>>>
>>>>> Strange, why should Decompiler be involved in a halt situation,
>>>>> and then, why should it refuse to decompile code?
>>>>>
>>>>> /Klaus
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>
>

> Died (in 3.9b-7048) with the attached (ByteString(Object)
> >>doesNotUnderstand: #between:and:), with temps
>
> aStream: a LimitedWriteStream 'isRoot: t1 '
> kwd: 'isRoot:'
> arg: {t1}
> temp: nil
> each: <primitive: 'primitiveIsRoot'>
>
> Does it make sense to check other builds / releases, is  
> recompileAllTest up-to-date?
>