-
Notifications
You must be signed in to change notification settings - Fork 3
Solve the Index Symbols Reliability Problem #4
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
Comments
I would like to work on this. From my cursory look at the linked discussion at GHC it seems that alanz's inquiry came to a standstill. So I guess the best approach would be to duplicate the functionality of HaRe. Anything else I should know? P.S. @NinjaTrappeur : P.P.S: I saw that ex-hack will be a project at ZuriHac, what do you think about creating a channel in their slack workspace? |
FYI there is a GSOC currently running to make use of the .hie files carrying the symbol/type information, which will probably be useful for this too. Ping @wz1000 |
Yes, .hie files contain all the resolved names in a file, and can be generated by ghc 8.8+. See https://gitlab.haskell.org/ghc/ghc/wikis/hie-files and https://github.com/wz1000/HieDb for an example of how to consume the files. |
I will need a little time to look at it and get ghc8.8-alpha1 installed, but those hie files look very promising. Thank you for the heads-up. |
Looks indeed very promising.
My git server was down; my bad. @chkl As I was stating in another issue; I don't have a lot of time ahead ATM to play with those indices. I'll probably do that tomorrow and post the conclusion of the experiment.
I'm not really using slack regularly, that said, I created a #ex-hack channel on freenode if you need to chat. If you also come to Zurihac, we definitely could work on this symbol resolution/ghc-interface refactoring. |
We are currently using a wrong approach to index a file's used symbols (see indexModule in the ProcessingSteps.hs file). Basically, we are looking at the modules provided by the package dependencies and filtering them accordingly to the imported modules. This is obviously a rough approximation. This results in lots of false positive/missed match and makes this software hardly usable. TL;DR our approximation does not perform really well.
So far, we did not find a way to get the GHC's Name for every symbol coming out of the parser. Basically, we are getting the parser output token stream and we did not find a way to get the resolved Name of the parsed symbols without traversing the whole GHC AST contained in the ModSummary.
I guess the problem here is mostly me being unfamiliar with GHC's API, the solution will hopefully be obvious to somebody with more experience.
I see two potential starting points to address this issue:
The text was updated successfully, but these errors were encountered: