DecompilationTests failures [was: About DecompilerTests >> decompilerDiscrepancies]

Actually I suspect decompilerDiscrepancies is equivalent to my 3.8-derived image's DecompilerTests>>decompilerFailures which exists to list methods that will cause decompilation tests to fail and predates my work with closures.  My version reads

decompilerFailures

"here is the list of failures: DNU resulting in trying to decompile the following methods"

^ #((BalloonEngineSimulation circleCosTable "-0.3826834323650903 => -0.38268343236509 or -0.3826834323650902")

(BalloonEngineSimulation circleSinTable "-0.3826834323650903 => -0.38268343236509 or -0.3826834323650902")

(GeniePlugin primSameClassAbsoluteStrokeDistanceMyPoints:otherPoints:myVectors:otherVectors:mySquaredLengths:otherSquaredLengths:myAngles:otherAngles:maxSizeAndReferenceFlag:rowBase:rowInsertRemove:rowInsertRemoveCount: "Cannot compile -- stack including temps is too deep")

(QPickable2D pick:) "foo ifTrue: [^bar] ifFalse: [^baz]. ^huh?"

(QUsersPane userEntryCompare:to:) "foo ifTrue: [^bar] ifFalse: [^baz]. ^huh?"

(TShaderProgram vertexStrings) "foo ifTrue: []. => foo. => ."

(TShaderProgram fragmentStrings) "foo ifTrue: []. => foo. => ."

(TWindow zoomWindow:) "foo ifTrue: [^bar] ifFalse: [^baz]. ^huh?"

"(PNMReadWriter nextImage) (Collection #ifEmpty:ifNotEmpty:) (Collection #ifEmpty:) (Collection #ifNotEmpty:ifEmpty:) (Text #alignmentAt:ifAbsent:) (ObjectWithDocumentation propertyAt:ifAbsent:)")

They all list methods whose compilation of their decompilation won't match what one started with either because of limitations in the decompiler or optimizations in the compiler.  For example if one writes 

    foo ifTrue: [].

the compiler will emit that as foo, eliminating the branch around the empty block.  So when that is decompiled it'll decompile as

    foo.

and the compiler will then compile that as empty.  So ...

When you decompile the source code of the method containing foo ifTrue: [] it contains a parse node that prints as

    foo ifTrue: [].

But the bytecode contains only the code for

    foo.

so when you decompile that you get

    foo.

and when you compile that you get no bytecode generated for foo.

Other examples include cases where to:by:do: is decompiled as whileTrue:, where the precision of a written float exceeds the representation of underlying float objects, and so on.

I don't see the point of fixing these things in either the compiler or the decompiler.  They're legal Smalltalk, the optimizations the compiler performs is perfectly reasonable, and there seems no point in e.g. annotating the bytecode with information on the optimization so that the decompilation would be correct.  Hence I think we have to live with the work-around which is filtering-out expected failures.  Implementing the filter as a list is poor; better would be to have rules that match expected failures, but that's potentially a lot of tricky work for not much benefit. What would help is a) a simple tool to look at the discrepancies side-by-side (I have a workspace I can send you), and b) people who run the tests updating the filer-list with exceptions and documenting what causes each exception.

HTH

Eliot