Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.0, 1.5, 1.5.1
-
Fix Version/s: 1.5.3
-
Component/s: None
-
Labels:None
-
Testcase included:yes
-
Number of attachments :
Description
Alex said:
getArray () [ getIndex() ] = 10
Both getArray () and getIndex() called twice.
Jochen said:
Barzilai Spinak schrieb:
[...]> Something broke in 1.5.2 and I'm still following the debug trace so hold on for a minute
> (In Eclipse I still have Groovy 1.5.1)I agree, but following the stack possibly won't help much. because before 1.5.2 a "return a[x]=b" was compiled as
a[x]=b
return a[x]then we changed this to:
a[x]=b
return band during this change something broke. So while in 1.5.1 you would at some point get into a method call a.getAt
, in 1.5.2 you won't. Instead Groovy should have left a copy of b on the stack and used this copy to do the return. And I think that did not happen, so it is a compiler problem, no API problem.
But it is also possible that this uncovered an very old error we have even before 1.0 and that was till now simply hidden by the fact that "return a[x]" was generated.
Alex has fixed this already, so this issue is to capture that fact and this test case for it.
I'll point out that the sort of test case I made is really not adequate for the issues that underlie what we're really trying to check here.
Not only are a just couple types and expressions checked (which could in principle be addressed partially by having more test cases), but there are things we want to say about the generated code that can't be tested by a unit test at all.
For example the single evaluation constraint applies even to variables which (when non-local) could change state due to a race with another thread.
A relatively easy way to write tests to check the generated bytecode for this kind of behavior would be with AspectJ. I'm also thinking that the specification could be written in such a way to automatically generate test cases incorporating constraints described using AspectJ.
I actually have many references to various automated and/or formal testing schemes (some which work with AspectJ), but I'll omit them here.