<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        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. :-(<div><br></div><div>This looks like a bug in how the stack is used in Decompiler. Having to check for "isKindOf: ParseNode" looks ugly in there.</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 16.11.2021 12:43:39 schrieb Marcel Taeumel <marcel.taeumel@hpi.de>:</p><div style="font-family:Arial,Helvetica,sans-serif"><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Note that there is #atLast: :-)<div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 16.11.2021 12:41:10 schrieb commits@source.squeak.org <commits@source.squeak.org>:</p><div style="font-family:Arial,Helvetica,sans-serif">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></div></blockquote>
                                        </div></div></blockquote></div>