-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error disappears when a module is added #31
Comments
I've pushed the two necessary callmap files to https://github.com/bgamari/ward-T31-repro |
While debugging this I have noticed if I export the callgraph of the failing case I find that |
Indeed it looks like declarations aren't handled properly. Specifically,
that is, just a declaration for However,
It looks like depending upon the order the files are given in the declaration may override the definition. |
I don't have a working Ward at the moment, but the first thing to check is whether this works out with simple examples smaller than the GHC rts. The second thing to check is whether this is related to GHCs reliance on |
Previously the calls (or, rather, lack thereof) of a function's declaration would override those of its definition. This resulted in evincarofautumn#31.
To be clear, I described the underlying issue in my previous comment. It seems that the treatment of declarations and definitions is simply wrong. I just pushed #35 which fixes the issue. |
Using 05b02cf I am seeing some rather concerning behavior when processing callmaps. I am using this configuration file:
I have two callmap files:
rts/sm/BlockAlloc.c.ward.graph
andrts/Capability.c.ward.graph
.Checking the
Capability
callmap alone correctly reports no errors:Checking the
BlockAlloc
callmap alone correctly reports several errors:However, when I check the
Capability
andBlockAlloc
callmaps together the error vanishes:Even stranger, when I flip the order of the two the errors are again correctly reported,
The text was updated successfully, but these errors were encountered: