Hello,

we have a failing test (OCClosureCompilerTest>>#testDebuggerTempAccess)
(fails since spur, but not related - I think).

A simple example to reproduce the behavior:

| local1 remote1|
remote1:=4.
local1 :=3.[:i | |c|
    c := local1.
    remote1 := i.
    i halt.
    "local1:=25.  <-- evaluate during debugging"
     ] value:1.
Transcript show:local1;cr.
Transcript show:remote1;cr.

(Executing this code and evaluating "local:=25" after the debugger halts
for
"i halt" will modify the var "remote1" instead of "local1", as this is a
vector tempvar , proceeding
the execution will crash at accessing the remote1 value).


The purpose of the testDebuggerTempAccess test case is, evaluating code
that changes the value of a copied temp var *does not* change the value of
this var in the outer context. (see comment in the test case:
"this is not 25 as the var is a local, non escaping variable that was
copied into the block,
    If the compiler would have known about the write, it would have made
the var escaping".
)

But the implementation (OCCopyingTempVariable>>#writeFromContext: aContext
scope: contextScope value: aValue)
explicitly iterates through all outer context(s) and changes the vars as
well.

1. Question: Who is right?

But the reason why the test actually fails is different. It is because
evaluating
the code that modifies the var "local1:=25" ends up to a call
aContext tempAt: self indexFromIR put: aValue
but the index (indexFromIR) can be different for every context (method
context / inner block
context(s)).

2. Question: should the index be always the same?

thanks inadvance

Nicolai


ps: since spur (resp. compiler changes that were done for new spur images),
the index of tempvars can be different.
In pre-spur, this testcase modifies an outer context var, but one that
isn't checked (the argument "two"), therefore
the test succeed. In spur, this testcase modifes a different outer context
var "remote1", and the test
fails.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160324/443987bd/attachment.htm