Wrong source for CompiledBlocks due to incorrect bytecode to AST nodes mapping

[chisandrei]

In this method all blocks seem to be printed wrongly:

This code is wrong as the sourceNode for a CompiledBloc resolves to a wrong node. We got several methods like the one below in Pharo 11 where the source code of all the blocks is wrong. Recompiling the method fixes the issue, and all blocks have the right source code, but not sure how initially it got in that state.

This was encountered in the latest Pharo 11 + VW on Windows 11.

In the above case this is the bytecode for the method and block:

Also this is the bytecode to AST nodes mapping:

This is after recompiling the method:

Not sure if related, but we seem to be getting also wrong sources for blocks in Pharo-12.0.0+SNAPSHOT.build.1488.sha.c55c586763b889b5e3b0c2749a987fac5ae1f7a7 (64 Bit) in some cases.
For example executing the first time this code in Pharo 12 returns the wrong result

blocks := OrderedCollection  new.
(AbsolutePath>>#asZnUrl) innerCompiledBlocksDo: [ :aBlock | 
		blocks add: aBlock ].
	
blocks first sourceNode sourceCode.

Executing the code the second time returns the correct result:

[carolahp]

The problem is caused when the method containing the block references a variable that was undeclared at the time of its compilation. The image below shows that blocks first outerCode returns an outdated version of the method's code, where the bytecode 67 (send:runtimeUndeclaredReadInContext:) is stacked.

A solution would be to recompile all the methods referencing a given UndeclaredVariable when the variable is no longer Undeclared, and do the same when a Global is deleted and left as Undeclared.

Additionally, we should add some tests to ReleaseTest to ensure that a fresh Pharo image does not contain methods with this problem.

@MarcusDenker do you think this solution is heading in the right direction?