I don't think this line was there by mistake. In some cases, the activePC with this code is lower than the startpc and then the debugger shows an error 'no ast node found at this pc' and cannot properly highlight the current executed code because the pc is outside the method bytecode. I remember adding this line as a hack to fix a bug report.... But I don't remember any more...

Here's an extract from my blog post, at that time the method had not this line, and we added it due to a bug report:

in a debugger, the context on the top of the stack does not highlight the same way other contexts does. In fact, the top context highlights the instruction in source code that *will* be executed in the next step. On the contrary, all the other contexts highlights the instruction in source code that *has been* executed previously. That means that you need to take care about that in the mapping to highlight the correct range.

Right now we had to keep the old mapping API so there is a method named�rangeForPC:contextIsActiveContext:�that has a boolean as second argument. With this boolean you know if you need to look for the range of the current pc (first argument) of the previous pc of the first argument. On the old mapping, they needed the exact pc for their pc to�abstract�pc mapping. So they needed a method�previousPCFor:�to handle the case of multiple byte code instructions. But we don�t care, as the pc will be used in the scan of�instructionForPC:, so we just need to do pc � 1.

The result is :

DebuggerMethodMapOpal>>#rangeForPC:�aPC�contextIsActiveContext:contextIsActive
"return the debug highlight for aPC"
| pc |
pc := contextIsActive ifTrue: [aPC] ifFalse: [aPC - 1].
^ (methodNode sourceNodeForPC: pc) debugHighlightRange
RBMethodNode>>#sourceNodeForPC:�anInteger
^ (self ir instructionForPC: anInteger) sourceNode

IRMethod>>#instructionForPC:�aPC
0 to: -3 by: -1 do: [ : off |
(self firstInstructionMatching: [:ir | ir bytecodeOffset = (aPC - off) ]) ifNotNil: [:it |^it]]