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:

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180823/5627745b/attachment.html>