-
Notifications
You must be signed in to change notification settings - Fork 97
Use a global namecache to read .hie
files
#677
Conversation
8b2570e
to
b260708
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, thank you!
@@ -0,0 +1,394 @@ | |||
{- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m increasingly starting to wonder if GHC is the right location for the .hie
files code. We seem to copy paste basically everything since we need to patch it. Hopefully, things will stabilize at some point 😞
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's used by haddock, so there isn't much of an alternative at this point.
Unfortunately this will soon become worse, as I have a patch to backport .hie
files to ghc-8.6
Needs rebasing. |
Co-authored-by: Matthew Pickering <[email protected]>
Since we started reusing `.hi` files, this exposes a bug where definitions aren't available since a bad source span from the `.hi` file gets put into the NameCache. We rectify by ensuring the span in the NameCache always matches the one from the `.hie` file. This has surfaced because an interaction between the commit which uses `.hi` instead of retypechecking and the change to use the shared global NameCache to read `.hie` files.
I found a bug introduced by this, fixed it and modified the tests to exercise this code path. See the commit message of 96d1f30 for an explanation. |
Thanks for the bugfix! |
* Use global NameCache for reading HIE files Co-authored-by: Matthew Pickering <[email protected]> * ignore hlint * redundant imports * Use hie files as source of truth for name source spans. Since we started reusing `.hi` files, this exposes a bug where definitions aren't available since a bad source span from the `.hi` file gets put into the NameCache. We rectify by ensuring the span in the NameCache always matches the one from the `.hie` file. This has surfaced because an interaction between the commit which uses `.hi` instead of retypechecking and the change to use the shared global NameCache to read `.hie` files. * Add test for missing definitions Co-authored-by: Matthew Pickering <[email protected]>
* Use global NameCache for reading HIE files Co-authored-by: Matthew Pickering <[email protected]> * ignore hlint * redundant imports * Use hie files as source of truth for name source spans. Since we started reusing `.hi` files, this exposes a bug where definitions aren't available since a bad source span from the `.hi` file gets put into the NameCache. We rectify by ensuring the span in the NameCache always matches the one from the `.hie` file. This has surfaced because an interaction between the commit which uses `.hi` instead of retypechecking and the change to use the shared global NameCache to read `.hie` files. * Add test for missing definitions Co-authored-by: Matthew Pickering <[email protected]>
* Use global NameCache for reading HIE files Co-authored-by: Matthew Pickering <[email protected]> * ignore hlint * redundant imports * Use hie files as source of truth for name source spans. Since we started reusing `.hi` files, this exposes a bug where definitions aren't available since a bad source span from the `.hi` file gets put into the NameCache. We rectify by ensuring the span in the NameCache always matches the one from the `.hie` file. This has surfaced because an interaction between the commit which uses `.hi` instead of retypechecking and the change to use the shared global NameCache to read `.hie` files. * Add test for missing definitions Co-authored-by: Matthew Pickering <[email protected]>
This backports this GHC MR in preparation for a larger role for
.hie
files in ghcide.We now have a global shared
NameCache
referenced byShakeExtras
, which we use to read.hie
files.