Some problems with analyzed trees and locating selected terms:

1.) On this moment the selected term is not always located in the analyzed ast when constructing the builder or refactoring input term.
This can probably be improved.

2.) When the selected node can not be located, the non-desugared node + ast is used instead.
Probably better to report the problem instead.

3.) in some cases it seems that either the analyzed AST is null (?) or outdated. Maybe this is fixed now.

Submitted by Maartje on 17 October 2012 at 11:33

I am not sure if this is related, but students discovered weird behaviour when selecting leaves and showing their ASTs. For example, consider System.out.println(1) with 1being selected. There are two correct behaviours:

1. Show only the leave, i.e. "1".
2. Show the AST for the expression, i.e. IntValue("1").

However, in the MiniJava project (CC repository, tag minimal 2), the shown AST is Print(IntValue("1")). In other places, for example in subexpressions, IntValue("1") is shown correctly.
Similar things happen for identifiers. In some places, only the string is shown, for example fac. In other places, the surrounding compound node is shown, for example Call(_, "fac", _).

Probably not related. The determination of the ‘selected’ term in builder rules is a bit fuzzy. As I remember correctly, the rule is first applied with the top node i.e. Print(IntValue(“1”)), and if it fails than the child nodes i.e. Intvalue(“1”) and “1” are tried.

Best solution seems to be to let the developer specify the expected (SDF)sort (or the constructor or both) in the .esv file. The same is done for refactorings. See also: https://yellowgrass.org/issue/Spoofax/551