(in 0.6.next)

When I write rules like

constraint-error :
c@Call(qid, e*) -> (c, $[Not a function variable.])
where …

This error is connected to an earlier (first?) use of qid.

Submitted by Zef Hemel on 11 February 2011 at 15:15

Some details. Having a small example or some insight into the renaming transformation and the transformation of Call() would be useful.

16:44:15 but this is a more serious issue: https://yellowgrass.org/issue/Spoofax/342
[…]
16:45:53 <Chip_Zero> zefhemel: can you provide some more context for that bug? is it detecting that “fn” is the origin for qid?
16:46:00 <Chip_Zero> were you marking an error for a call to test()? etc
16:46:41 yes
16:46:53 no
16:46:54 to fn
16:47:04 fn() <— that’s where the error should be
16:48:17 <Chip_Zero> so the fn parameter is the origin for the fn reference in fn()..?
16:48:26 <Chip_Zero> what kind of transformation do you do that would cause this?
16:48:27 yes
16:48:36 well, renaming
16:48:55 the odd thing is that I put the marker on the Call(), not on the qid, though
16:51:23 <Chip_Zero> zefhemel: define renaming
16:51:40 <Chip_Zero> do you replace “fn” by a node based on the definition of “fn”?
16:51:51 <Chip_Zero> or do you take the “fn” reference and add an annotation to it?
16:52:16 <Chip_Zero> zefhemel: it sounds like Call() has no origin so it has to use the origin of the “fn” child
16:52:47 <Chip_Zero> so another queston is how do you transform Call()? maybe something changed in origin tracking there?
16:53:42 Maybe we should look into this next week, I still want to put out a minor mobl update today.
16:54:56 <Chip_Zero> it sounds like something changed in the origin tracking implementation, but I need to understand your transformation more to figure out what it is
16:55:02 <Chip_Zero> a minimal example would be very helpful :)
16:56:44 yeah
17:08:48 * zefhemel has quit (Quit: Leaving.)

This issue was mostly resolved, but a problem seems to remain with a rule of the form:

desugar-top = alltd(desugar)

desugar:
Function(x, body) -> Function(QID(m,x), body)

where the QID term doesn’t track back to x.

I looked into this again. What we knew about this so far is that QID(m,x) didn’t get an origin, but m does have an origin and/or position information. Then if you have something like error marking on the QID node, it’ll use the first child instead: m. From what I can tell, the old implementation also wouldn’t assign an origin to QID: it only does that at the first level of terms inside the all (so Function gets an origin).

Is it possible something changed in your code so that m now has position information where it didn’t before? Or perhaps the origin implementation handles that case slightly better?

In any case, perhaps origin tracking should be changed so it also considers the second level (at least when applied to lists?), i.e. also track origins for child nodes like QID(m,x). There may be a small performance penalty, but it seems like the right thing to do. Otherwise you’ll basically only get origin/position information for top-level nodes and descendants that already had position information in a setup like this one.

Anyway – I’m not entirely sure if we should do the two-level origin tracking like this, but I committed this change (r22360). Let me know if it works now.

It seems to work now. I’ll keep testing.

Great :) Closing issue then, for now anyway.