On Thu, Dec 13, 2012 at 10:40 AM, Igor Stasenko <siguc...@gmail.com> wrote:
> On 13 December 2012 10:30, Stéphane Ducasse <stephane.duca...@inria.fr> wrote:
>> Now adrian I imagine that you saw that people worked on this bug and this is
>> a rather complex one.
>> So I would suggest to you to avoid to draw conclusions too fast.
>>
> yes, if i remember, we tried to approach it at least once..
> but unfortunately it requires a lot deeper knowledge about bytecode
> and (de)optimizations to fix highlight.
>
I looked at it a bit on the train...
With the new infrastructure, we create an intermediate representation which is
(nearly) a 1:1 mapping to bytecode (some are mapped to multiple
bytecode, multiple
IR nodes can result in just one BC), but mostly: 1:1 mapping.
The nice thing is that the IRnode records the offset of the bytecode
when bytecode is
emitted. And the IR knows the AST Node it was created from. And the
AST node knows everything
(down to the Tokens and the offset in the source text).
after adding #instructionForPC: to IRMethod (which just searches for
the node), the following code just
works:
| method astNode|
method := Integer>>#+.
astNode := (method parseTree ir instructionForPC: 58) sourceNode.
method sourceCode copyFrom: astNode debugHighlightStart to: astNode
debugHighlightStop
returns
'ifTrue: [^ (self digitAdd: aNumber) normalize]
ifFalse: [^ self digitSubtract: aNumber]'
This needs to be tested and enhanced a bit (e.g. for the case that one
IR created multiple bytecodes, e.g. block
pre-amble and postscript...).
But it should not be that hard to do, I think. The good thing is that
it does not rely on some table that is created
somewhere, but instead you have the data (IR and AST) directly there
to look at. Tweaking special cases should
be quite easy with that.
Marcus
--
Marcus Denker -- den...@acm.org
http://www.marcusdenker.de
