-
Notifications
You must be signed in to change notification settings - Fork 437
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
Unknown AnalysisClassHierarchy.Untracked(_) exception occurs at analysis #378
Comments
@AngelinaG we're going to do some work to make that error message a lot more helpful. Thanks for pointing this out. In the mean time, your attempt at excluding your venv in via
If you're still getting errors after trying both of those, perhaps the problematic code really is present in your project. If that's the case, can you try doing a sort of binary search for the bug by deleting one half the code and then the other, and seeing if it makes the error go away? If you find the problematic file/lines, we can use that as a test case to get a fix out for you. |
Summary: The basic premise here is that our ClassHierarchy.Untracked issue gets surfaced to users a decent amount, and has come up on GitHub during the type checking multiple times: #378 as the most recent example. OCaml isn't able to serialize Type.t's to user, but can do a better job with strings, especially when we're in the case of a `Scheduler.map_reduce`, where the backrtrace can be very hard to read. For reference, here's what the exceptions have historically looked like: ``` AnalysisClassHierarchy.Untracked(_) ``` This diff changes the type of `ClassHierarchy.Untracked` to take a string, so that users at least know which type caused the issues. This isn't perfect, but can give us enough information to help do some basic debugging. Consequences: The good: 1. We get more readable error messages for some of the harder-to-debug errors we tend to find. 2. We've eliminated a lot of the Type.show's, since all we did with this exception type was display it. The bad: 1. Analysis failure errors of different types will not be joined any more. I don't think this is a real concern. 2. The types of analysis failures are no longer dequalified. I think this is the real concern, but in this case, feel that the benefit of users being able to debug this outweighs the longer error message. Reviewed By: grievejia Differential Revision: D26323785 fbshipit-source-id: b63b626005c2b14246534373825b68f9a2e96784
@gbleaney I'm a part of this project also. I've got an update on this - turns out the problem was within our own library, specifically a misplaced import statement. |
@SaurusXI is there any way you could put that into a small file I could use to repro? From what you were describing, I assumed adding an |
We have improved that specific exception, it should now give the problematic class. I will close this for now, feel free to reopen if you still have issues. |
Hello, urgently trying to find a fix for an unidentified and undocumented error.
Running pysa analysis and getting this error:
pyre config file:
Our model:
The class its modelling:
We tried tweaking a lot of things and we keep getting the same error.
Only found 3 mentions of this problem so far here, here at the end of the page and also here. None have been useful so far.
The text was updated successfully, but these errors were encountered: