Been playing with the testing plugin and my Lua editor again. Testing really works quite well now, but when I arrived at testing reference resolving I found an issue anyway :-)

The issue is that SelectionFetcher includes every selection n times, with n the number of injections at that place.

For example, in Lua there is only a multi-declaration and multi-assignment, and I’m wrapping all single declarations in a Name cons, so a declaration may look like this:

Lua: local x

AST: LocalVariableDecl([Name(“x”)])

The SelectionFetcher then adds "x", Name("x"), and [Name("x")] to the results, which is treated as 3 selections by the Stratego code in the Testing plugin.

Due to this a working test may be

test resolve variable
local var
var = 12

resolve #6 to #2

instead of resolve #2 to #1.

Additionally, SelectionFetcher.isCloseQuote treats the close quote of the test as a whole as a right token of a selection too, so in the above test, it will also add the node Assignment(_, _) that represents the whole last line to the selections. (This node is the unclosedChild in the SelectionFetcher at some point.)

So for the above test, the SelectionFetcher returns as selections the list:

[[Name(“var”)], Name(“var”), “var”, [Var(“var”)], Var(“var”), “var”, Assignment([Var(“var”)],[Number(“12”)])]

I’m guessing it should combine terms with equal left and right tokens, and then use the same heuristics as it uses for actually invoking the reference resolver to pick one of the three options.
In any case it should not consider the close quote of the test as a whole as a close quote of a selection.

Submitted by Tobi Vollebregt on 12 September 2011 at 01:14

Weird. Must be some issue with the SelectionFetcher traversal; I guess it needs some kind of stop condition…

Its because it only looks at the tokens left and right of each AST node.

In my example, each of “var”, Name(“var”), and [Name(“var”)] have as left token “" and as right token "”, so each is treated as a selection…

(And the assignment also has as left token “" and as right token "” (which actually is the closing bracket of the test case) so this gets added too.)

Aha. That makes two issues then. Not adding those child notes inside the [[...]] text, and making sure that the outer ]] doesn’t have a TK_ESCAPE_OPERATOR token kind.

SelectionFetcher is still a bit hacky (trying to reconcile two tree structures tends to be, I guesss), but this should be fixed in r23501.