Thank you camille,
I still don't fully understand, why it is so hard to make it work for all use cases.
It looks like a simple thing, make a sourceNode for the current context!
So for me it looks like the main problem is to distinguish these cases:
Create a SourceNode for
a) Method or
b) Block or
c) MethodContext or
d) BlockContext
and at the moment we are mixing case c/d/b
It's easy for method and block.
For MethodContext, it's harder.
I would love if I could write:
MethodContext>>sourceNode
^ self isBlockContext ifTrue: [ closureOrNil sourceNode ] ifFalse: [ method sourceNode ].
but it doesn't work because inlined blocks don't create a new context:
1 to: 1 do: [ :i | ^ thisContext isBlockContext ] returns false.
So instead we have to rely on pc->IR nodes and IR nodes->AST nodes mappings.
But everything is not mapped as you would expect yet in these two mappings. I found that:
- the (pushLiteral: nil) bytecodes used to mark the number of block temporaries have corresponding IR nodes but these node are mapped with the AST block node instead of the AST sequence node.
- the (pushTemp: n) bytecodes used to push the copied values of blocks don't have corresponding IR nodes so no AST node is associated with them.
- the block return bytecodes are mapped to the block node instead of the sequence.
Fixing these mapping is not easy, and it's too big a change for Pharo 3.
So we have to deal with the current mapping for now.
Thank you ben, for finding/looking at the failing tests.
(I wished we would have an improved debugger, showing
sourcecode, AST, IR and bytecode linked together :-)