Incoming flow errors about ablec HOT 7 CLOSED

BTW: a piece of good news: so far the performance impact of being more precise about patterns has been small. happy dance

from ablec.

Looks the same as the issue that I had to workaround for substitution on exprStmt and a few other places - for example, in order to explicitly check if the Expr is a declRefExpr, I need to supply dummy values for env and returnType. This is actually slightly wrong, since we could be wanting to substitute on something forwarding to one of these 'target' constructs... but I can't think of a way around this without making substituted depend on env and returnType.

from ablec.

More progress/fixes. Current status:

Errors for edu:umn:cs:melt:ableC:abstractsyntax
 [./edu.umn.cs.melt.ableC/abstractsyntax/AttributeAnimation.sv]
AttributeAnimation.sv:5:2: warning: Equation has transitive dependency on child attr's inherited attribute for env but this equation appears to be missing.
AttributeAnimation.sv:5:2: warning: Equation has transitive dependency on child attr's inherited attribute for returnType but this equation appears to be missing.
AttributeAnimation.sv:21:2: warning: Equation has transitive dependency on child attr's inherited attribute for env but this equation appears to be missing.
AttributeAnimation.sv:21:2: warning: Equation has transitive dependency on child attr's inherited attribute for returnType but this equation appears to be missing.

Errors for edu:umn:cs:melt:ableC:abstractsyntax:substitution
 [./edu.umn.cs.melt.ableC/abstractsyntax/substitution/Attribute.sv]
Attribute.sv:60:2: warning: Synthesized equation substituted exceeds flow type with dependencies on env, returnType

from ablec.

I think I'm now feature-complete, and those are it for base ablec.

from ablec.

Those aren't the most descriptive error messages when dealing with a large match statement, but I don't know how easy that would be to improve...
Also, fixing those is going to make the code a fair bit uglier, as it already has in a few other places. It is starting to seem like a fairly common problem to be pattern matching, but needing to provide inherited attributes at some intermediate level in the pattern, which requires the match to be split up into locals.
How hard would it be to implement some sort of special pattern syntax that would allow this to be done 'in place'? For example, as in ableC where we have this problem:

case attr of
| consAttribute(gccAttribute(l) with {env = emptyEnv(); returnType = nothing();}, t) -> ...
...
end;

This could work sort of like decorate in terms of the flow analysis, except it would expect the whole forward set to be present instead of the ref set. Thoughts?

from ablec.

The error messages are hard to improve because tracking down what caused the dependency is slightly difficult (and can have multiple causes).

Your suggestion isn't something that works well with the pattern matching feature, but fortunately, I think you are just missing a useful detail: those children are extracted already decorated from what you're matching on. If you need to supply inherited attributes like that, all you need to do is give the dummy values to the top-level match, and they should be passed down in that tree as that tree's equations specify.

from ablec.

Ah, thanks for clarifying! That behavior does make sense, I'm not sure why I assumed that they are undecorated.

from ablec.