[squeak-dev] Bug in Decompiler for decoding inlined messages (#ifNotNil:, #by:do:)

christoph.thiede at student.hpi.uni-potsdam.de christoph.thiede at student.hpi.uni-potsdam.de
Tue Nov 16 12:03:07 UTC 2021

Hi all!

This method is currently decompiled incorrectly. In particular, this makes it impossible to debug it without a changes file:

		| x |
		(x := self foo) ifNotNil: [self bar].
		^ x

The decompiler returns:

		self foo
			ifNotNil: [:x | self bar].
		^ x

Here is another example:

		| x |
		x := 1.
		[x <= 5] whileTrue: [
			Transcript showln: x.
			x := x + 1].
		^ x

The decompiler returns:

			to: 5
			do: [:x | Transcript showln: x].
		^ x

In both examples, the decoding of the inlined message is invalid because the temporary is also accessed outside of the block scope.
In DecompilerConstructor>>decodeIfNilWithReceiver:selector:arguments:tempReadCounts:, we already check "that there is no remote vector pointing to it", but the tempReadCounts arguments cannot see into the future, unfortunately.
What would be the right way to fix this? I saw that we already have #markTemp:asOutOfScope: but we do not send this from #jump:in: and it is also unclear to me where the scope is really checked during the decompilation. If we do not want to perform a second run over all byte codes, I could only imagine that if a variable out of scope is pushed onto the stack (#pushTemporaryVariable:), we could revert the previous decoding. But first of all, I do not see any possibility to get the current scope of a running decompiler and second, implementing this revert sounds like a not so small design change.

Do you see a simple way to fix this limitation, or do we indeed need to rework the decompiler design to handle this edge case properly? If yes, which one would you prefer - 1) run the decompiler twice so that tempReadCounts is already filled correctly, or 2) try to identify the scope of every "pushTemp" instruction and if the scope is invalid, revert the inline decoding from there?


Sent from Squeak Inbox Talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211116/8b03dbb5/attachment.html>

More information about the Squeak-dev mailing list