-
-
Notifications
You must be signed in to change notification settings - Fork 142
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
Can Dialyxir help to clarify the success typing rationale? #327
Comments
I'm skeptical we can do anything helpful in Maybe a good heuristic to follow when debugging this manually is something like, look at the return paths and the function(s) which determines their type. Is that function specced? If not, add a spec to it for what you think it is and run dialyzer again. Does it say your spec is wrong? |
"... we'd have to give you every function tree recursively, not just the ones determining the return type." Is there some reason for this? Please clarify why the program couldn't print only the relevant functions. |
I was referring to using xref - I'm not sure we can even tell you who all the callees are from a given function. It looks like XRef only resolves that at the module level. Perhaps there is another way to get all the callees from a function (rather than to a function, which is what xref focuses on) but in order to get "the relevant" function we'd have to know which ones influence the return value. |
I recently spent quite a bit of time trying to kill off a Dialyzer nastygram. (See this thread for details.) Eventually, I determined that a couple of other functions, not mentioned in the diagnostics, were feeding bad information into the success typing. Although I was able to find these functions manually, some mechanized assistance would have been quite helpful.
So, I’m wondering if it might be possible to produce a traceback of sorts, detailing how Dialyzer came up with its success typing determination, with emphasis on the arguments and return values that don’t match. I realize that this would bulk up the report, so it should be optional, tunable, etc. And a pony...
In the long term, this sort of thing should be handled largely by Dialyzer itself. However, some short term hacks in Dialyxir might help to point the way. For instance, it might be possible to start with a given function and (extracting data from
mix xref
or somesuch) present a sub-tree of relevant functions.The text was updated successfully, but these errors were encountered: