Hi Marcel,

> This looks like a bug in how the stack is used in Decompiler. Having to check for "isKindOf: ParseNode" looks ugly in there.

You can browse the references to any of the class variable flags in Decompiler, it seems to be a common thing to put them onto the stack for whatever reasons. The decompiler truly will not win the price for our most beautiful implementation, but in this case, I would opt for "don't let perfect be the enemy of good" - I would rather like to prioritize its test coverage. Also, iirc inline sends will be deprecated with the next VM generation so I would not want to spend too much time on refactoring this stuff. :-)

Best,
Christoph

---
Sent from Squeak Inbox Talk

On 2021-11-16T12:49:36+01:00, marcel.taeumel at hpi.de wrote:

> Hmm... I wonder since when the Decompiler's stack has so many objects other than ParseNode instances? I mean, there is LiteralNode and SpecialLiteralNode. Yet, I find actual SmallInteger or ByteString in there. :-(
> 
> This looks like a bug in how the stack is used in Decompiler. Having to check for "isKindOf: ParseNode" looks ugly in there.
> 
> Best,
> Marcel
> Am 16.11.2021 12:43:39 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
> Note that there is #atLast: :-)
> 
> Best,
> Marcel
> Am 16.11.2021 12:41:10 schrieb commits at source.squeak.org <commits at source.squeak.org>:
> A new version of Compiler was added to project The Inbox:
> http://source.squeak.org/inbox/Compiler-ct.463.mcz
> 
> ==================== Summary ====================
> 
> Name: Compiler-ct.463
> Author: ct
> Time: 16 November 2021, 12:40:59.711376 pm
> UUID: 8f758ee8-125c-d54d-b581-72ab467f92ae
> Ancestors: Compiler-eem.460
> 
> Fixes a DNU in the decompiler when the stack contains flags (such as CaseFlag) while trying to match a #to:[by:]do: loop. Can be reproduced with String >> #format: ct 12/7/2019 15:05 (Collections-ct.867).
> 
> =============== Diff against Compiler-eem.460 ===============
> 
> Item was changed:
> ----- Method: Decompiler>>startAndLimitFor:from:into: (in category 'private') -----
> startAndLimitFor: incrVar from: aStack into: binaryBlock
> "If incrVar matches the increment of a whileLoop at the end of statements
> evaluate binaryBlock with the init statement for incrVar and the init statement
> for the block's limit, if any, and answer true. Otherwise answer false. Used to
> help convert whileTrue: loops into to:[by:]do: loops."
> | guard initExpr limitInit size |
> ((size := aStack size) >= 1
> + and: [(initExpr := aStack at: size) isKindOf: ParseNode]
> + and: [initExpr isAssignmentNode]) ifFalse:
> - and: [(initExpr := aStack at: size) isAssignmentNode]) ifFalse:
> [^false].
> initExpr variable == incrVar ifTrue:
> [binaryBlock value: initExpr value: nil.
> ^true].
> limitInit := initExpr.
> (size >= 2
> + and: [((initExpr := aStack at: size - 1) isKindOf: ParseNode)
> + and: [initExpr isAssignmentNode
> + and: [initExpr variable == incrVar]
> - and: [(initExpr := aStack at: size - 1) isAssignmentNode
> - and: [initExpr variable == incrVar
> and: [(guard := statements last receiver) isBlockNode
> and: [guard statements size = 1
> and: [(guard := guard statements first) isMessageNode
> and: [guard receiver == incrVar
> and: [guard arguments first == limitInit variable]]]]]]]) ifTrue:
> [binaryBlock value: initExpr value: limitInit.
> ^true].
> ^false!
> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211116/aaa02397/attachment.html>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211116/4a21b8d6/attachment.html>