pharo icon indicating copy to clipboard operation
pharo copied to clipboard

Possible issue when getting the #sourceNode for ConstantBlockClosure

Open chisandrei opened this issue 10 months ago • 5 comments

Is it expected that this fails in Pharo 11/12 and works in Pharo 10?

blocks := OrderedCollection  new.
(FBDExamples>>#exampleSimpleBlock) innerCompiledBlocksDo: [ :aBlock | 
    blocks add: aBlock  ].
    
self assert: blocks first sourceNode sourceCode = '[1]'.

In Pharo 10 the returned source code is [1], while in Pharo 11/12 it is ^[1]. The node of the block is RBBlockNode in Pharo 10 and RBReturnNode in Pharo 11/12

To work in Pharo 11/12 we can send value to the sourceNode.

self assert: blocks first sourceNode value sourceCode = '[1]'.

chisandrei avatar Apr 19 '24 18:04 chisandrei

I tracked this down to the bc-> AST mapping being wrong when the block is a constant block.

Next step is to fix that

MarcusDenker avatar Apr 23 '24 12:04 MarcusDenker

The problem is that OCBytecodeToASTCache>>#generateForNode: does not add any entry for compiledBlocks

I think we have to analyse all pushes, find when a constant block ist pushend and add the mapping pc -> AST from that

MarcusDenker avatar May 03 '24 14:05 MarcusDenker

Just as a side-note, CleanBlockClosure>>#doPrintOn: gets the source node of a compiled block using self sourceNode value instead of self sourceNode. For constant blocks sourceNodereturns aRBReturnNodeand sendingvalue` to that returns the correct node. This results in the source code actually being ok when printing it

chisandrei avatar Jun 13 '24 11:06 chisandrei

We currently have a workaround implemented by Andrei. @chisandrei it can be interesting to share it here.

fedemennite avatar Aug 26 '24 13:08 fedemennite

The workaround is just calling self compiledBlock ast value instead of self compiledBlock ast when handling a RBReturnNode.

chisandrei avatar Aug 26 '24 15:08 chisandrei

Thanks!

Ducasse avatar Aug 31 '24 17:08 Ducasse