On Thu, 23 Aug 2018 at 07:38, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> Hi Bert,
> On Wed, Aug 22, 2018 at 3:57 PM Bert Freudenberg <bert at freudenbergs.de>
> wrote:
>
>> On Mon, 20 Aug 2018 at 16:06, Chris Muller <asqueaker at gmail.com> wrote:
>>
>>> I would never have guessed that fix.  It seems better, thanks.  I
>>> think the ifNil: check is not quite working, it seems to "stay" on the
>>> assignment for two steps, then skips over the #ifNil: check.
>>>
>>> It does now highlight the cases its checking, which is very nice.
>>>
>>
>> The debugger's highlighting is actually very simple: It looks up which
>> parse node has the current context's pc, and uses the source map to find
>> the interval (a.k.a. source range) in the source code to highlight.
>>
>> This information comes from the compiler. It's parsing the source code
>> into a tree of parse nodes, while its encoder records their source range.
>> Then the compiler traverses that tree to emit byte code, recording the pc
>> in each node.
>>
>> To fix the highlighting we just need to ensure that when the debugger
>> stops on a pc, that pc is actually found in the right parse node, and the
>> node has the right source range associated.
>>
>> I was about to do a fix for ifNil etc. but I see Eliot beat me to it
>> in Compiler-eem.391. That's a one-line fix too, the recorded pc was just
>> too far ahead.
>>
>
> But the fix is incomplete.  Replace ifNil: by an ifNil:ifNotNil: in Chris'
> example and one sees the same failure to emphasize anything for the == nil
> send hidden in the inlined ifNil:ifNotNil:
>

That's because it fails to assign a source range to the hidden "== nil"
message node.

Fixed in
Compiler-bf.393
.


There's still a minor glitch when the ifNotNil: block has an argument. In
that case the compiler creates a hidden assignment node for the argument
,
but
 the debugger stop
s
once
on that assignment, and stops again on the
"== nil"
comparison.
It
really should jump over the assignment, but I'm not sure how to arrange
that.

- Bert -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180823/6be5c268/attachment.html>