A) Improve error message: Illegal refactoring result"
B) Requirement is not needed if a list with textchanges is returned (instead of single root change)
C) How to detect/report text-reconstruction failures caused by this problem?

Good point. As long as the changed terms have a parent term (not necessarily the root) with origin information the reconstruction can be applied in principle. In the implementation I think I combine all changes to a single change on the root and therefore apply the check. May reconsider this to be more robust in case the origin root ast get lost by accident in the desugaring.

On 12/21/2011 03:56 PM, Lennart Kats wrote:

Hi Maartje,

Don’t the (n, s, h, o) children already have a usable origin though?

Lennart

On 12/21/11 15:41 , maartje wrote:

Hi Guido,
Can you check for both cases if the (old) asts in the refactoring result has an origin term?
This is required for layout preservation and checked in Spoofax (the error message could be more informative).

example:
… -> ([(ast, ast-trans)], [], [], [])
with
ast

Just a check to see if the result is actually valid.

On 12/21/2011 03:18 PM, Guido Wachsmuth - EWI wrote:

Hi Maartje, hi Lennart,

I ran into a strange Spoofax bug. In the MiniJava project (https://svn.strategoxt.org/repos/cc/trunk/MiniJava), there is an example file examples/factorial.mjr. If I try to apply the “Evaluate next” refactoring on the runtime, I get an “Illegal refactoring result”. However, if I change sstore4 in trans/assignment2/analysis.str from

sstore4: Runtime(n, s, h, o) ->Runtime(n, s, h, o)

into

sstore4: Runtime(n, s, h, o) ->

the refactoring works fine. This is strange because both rules should do the same. Furthermore, sstore4 is not involved in the refactoring, but in the static analysis.

I ran into this with an earlier Spoofax version, but the update to release did not help. Any idea how to fix this?

Cheers, Guido

Submitted by Maartje on 21 December 2011 at 16:15