Hi Marcel,<br>
<br>
> This looks like a bug in how the stack is used in Decompiler. Having to check for "isKindOf: ParseNode" looks ugly in there.<br>
<br>
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. :-)<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font color="#808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></font><br>
<br>
On 2021-11-16T12:49:36+01:00, marcel.taeumel@hpi.de wrote:<br>
<br>
> 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. :-(<br>
> <br>
> This looks like a bug in how the stack is used in Decompiler. Having to check for "isKindOf: ParseNode" looks ugly in there.<br>
> <br>
> Best,<br>
> Marcel<br>
> Am 16.11.2021 12:43:39 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:<br>
> Note that there is #atLast: :-)<br>
> <br>
> Best,<br>
> Marcel<br>
> Am 16.11.2021 12:41:10 schrieb commits at source.squeak.org <commits at source.squeak.org>:<br>
> A new version of Compiler was added to project The Inbox:<br>
> http://source.squeak.org/inbox/Compiler-ct.463.mcz<br>
> <br>
> ==================== Summary ====================<br>
> <br>
> Name: Compiler-ct.463<br>
> Author: ct<br>
> Time: 16 November 2021, 12:40:59.711376 pm<br>
> UUID: 8f758ee8-125c-d54d-b581-72ab467f92ae<br>
> Ancestors: Compiler-eem.460<br>
> <br>
> 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).<br>
> <br>
> =============== Diff against Compiler-eem.460 ===============<br>
> <br>
> Item was changed:<br>
> ----- Method: Decompiler>>startAndLimitFor:from:into: (in category 'private') -----<br>
> startAndLimitFor: incrVar from: aStack into: binaryBlock<br>
> "If incrVar matches the increment of a whileLoop at the end of statements<br>
> evaluate binaryBlock with the init statement for incrVar and the init statement<br>
> for the block's limit, if any, and answer true. Otherwise answer false. Used to<br>
> help convert whileTrue: loops into to:[by:]do: loops."<br>
> | guard initExpr limitInit size |<br>
> ((size := aStack size) >= 1<br>
> + and: [(initExpr := aStack at: size) isKindOf: ParseNode]<br>
> + and: [initExpr isAssignmentNode]) ifFalse:<br>
> - and: [(initExpr := aStack at: size) isAssignmentNode]) ifFalse:<br>
> [^false].<br>
> initExpr variable == incrVar ifTrue:<br>
> [binaryBlock value: initExpr value: nil.<br>
> ^true].<br>
> limitInit := initExpr.<br>
> (size >= 2<br>
> + and: [((initExpr := aStack at: size - 1) isKindOf: ParseNode)<br>
> + and: [initExpr isAssignmentNode<br>
> + and: [initExpr variable == incrVar]<br>
> - and: [(initExpr := aStack at: size - 1) isAssignmentNode<br>
> - and: [initExpr variable == incrVar<br>
> and: [(guard := statements last receiver) isBlockNode<br>
> and: [guard statements size = 1<br>
> and: [(guard := guard statements first) isMessageNode<br>
> and: [guard receiver == incrVar<br>
> and: [guard arguments first == limitInit variable]]]]]]]) ifTrue:<br>
> [binaryBlock value: initExpr value: limitInit.<br>
> ^true].<br>
> ^false!<br>
> <br>
> <br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211116/aaa02397/attachment.html><br>
> <br>
>