A new version of Kernel was added to project The Inbox:
http://source.squeak.org/inbox/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-td5128777.html

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.html"!
- !

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.html"!
- 	^newTop!