Marcel Taeumel uploaded a new version of Kernel to project The Treated Inbox: http://source.squeak.org/treated/Kernel-jar.1421.mcz
==================== Summary ====================
Name: Kernel-jar.1421 Author: jar Time: 15 November 2021, 2:01:40.493442 am UUID: a0158f6a-ffeb-4946-bd0a-25ac6b1947d5 Ancestors: Kernel-eem.1420
Fix a bug: when debugging things like this: [^2] ensure: [Transcript cr; show: 'done'] if we step into the protected block [^2] and then step over ^2, we incorrectly get a lockCannotReturn. The bug is described in detail in Kernel-nice.1407 and discussed in http://forum.world.st/stepping-over-non-local-return-in-a-protected-block-td...
Add a flag and an explanatory comment.
Supersedes Kernel-jar.1413; please kindly remove from the Inbox
=============== Diff against Kernel-eem.1420 ===============
Item was changed: ----- Method: Context>>resume:through: (in category 'controlling') ----- resume: value through: firstUnwindCtxt "Unwind thisContext to self and resume with value as result of last send. Execute any unwind blocks while unwinding. ASSUMES self is a sender of thisContext."
| ctxt unwindBlock | + self flag: #simulator. "jar: see Note below" self isDead ifTrue: [self cannotReturn: value to: self]. + ctxt := firstUnwindCtxt ifNil: [thisContext findNextUnwindContextUpTo: self]. - ctxt := firstUnwindCtxt. [ctxt isNil] whileFalse: [(ctxt tempAt: 2) ifNil: [ctxt tempAt: 2 put: true. unwindBlock := ctxt tempAt: 1. thisContext terminateTo: ctxt. unwindBlock value]. ctxt := ctxt findNextUnwindContextUpTo: self]. thisContext terminateTo: self. ^value + + "Note (11/2021): when debugging things like this: + [^2] ensure: [Transcript cr; show: 'done'] + if we step into the protected block [^2] and then step over ^2, we incorrectly get a BlockCannotReturn. + To avoid this bug, a close interplay between #return:from: and #resume:through: has been established: + During simulation, #return:from: passes firstUnwindCtxt = nil to #aboutToReturn:through: which then + propagates to resume:through: and causes a fresh search for the first unwind context. The matter has + been discussed in http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-August/216214.ht... - !
Item was changed: ----- Method: Context>>return:from: (in category 'instruction decoding') ----- return: value from: aSender "For simulation. Roll back self to aSender and return value from it. Execute any unwind blocks on the way. ASSUMES aSender is a sender of self"
| newTop | + self flag: #simulator. "jar: see Note below" aSender isDead ifTrue: [^self send: #cannotReturn: to: self with: {value}]. newTop := aSender sender. (self findNextUnwindContextUpTo: newTop) ifNotNil: + [^self send: #aboutToReturn:through: to: self with: {value. nil}]. - [:unwindProtectCtxt| - ^self send: #aboutToReturn:through: to: self with: {value. unwindProtectCtxt}]. self releaseTo: newTop. newTop ifNotNil: [newTop push: value]. + ^newTop + + "Note (11/2021): when debugging things like this: + [^2] ensure: [Transcript cr; show: 'done'] + if we step into the protected block [^2] and then step over ^2, we incorrectly get a BlockCannotReturn. + To avoid this bug, a close interplay between #return:from: and #resume:through: has been established: + During simulation, #return:from: passes firstUnwindCtxt = nil to #aboutToReturn:through: which then + propagates to resume:through: and causes a fresh search for the first unwind context. The matter has + been discussed in http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-August/216214.ht... - ^newTop!
packages@lists.squeakfoundation.org