-
Notifications
You must be signed in to change notification settings - Fork 50
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
Avoid runTcInteractive
in BuildDictionary
#82
base: master
Are you sure you want to change the base?
Conversation
Sounds great! Thanks for the contribution, @zliu41! @mikesperber Since you folks are the primary users of concat other than KittyHawk I'm aware of (and since I'm currently not using it), would you please check out this PR to see how affects your use? |
Unfortunately, it fails to solve some constraints it was able to solve pre-patch. We're investigatung. (Relevant, as we were also having problems pre-patch where the plugin was not seeing certain class instances.) |
Thanks @mikesperber. I'd be curious what the error message is, and if it points to a missing instance, whether the module that defines it is included in |
@zliu41 It looks like it can't infer |
Here's trace output that shows the problem:
|
Nope, doesn't ring any bells. I'm happy to do some more investigation but it's not clear to me how to reproduce this. It sounds like you are using both the concat plugin, and the knownnat plugin, and with this change, somehow the knownnat plugin stopped working, and then concat tried to solve that constraint, but couldn't, either? |
@zliu41 No: ConCat is trying to solve a |
@mikesperber Ok thanks. I think we are basically saying the same thing. Seems like for some reason the knownnat plugin isn't properly triggered with this patch. I'll see if I can reproduce this. |
I think the problem is that runTcInteractive hsc_env thing_inside
= initTcInteractive hsc_env $ withTcPlugins hsc_env $
withDefaultingPlugins hsc_env $ withHoleFitPlugins hsc_env $ It would be a one-line fix if |
@mikesperber Would you give 68c4901 a try, and see if it solves the problem? I think it should. |
Unfortunately, now I'm getting problems resolving
(What a rabbit hole ...) |
Thanks @mikesperber . We also use |
@mikesperber Here's our reason for the |
So I haven't been able to reproduce this exact error:
So I'm not sure what can lead to the "unsolved constraints" |
Funny that I've just encountered This commit turns a few ... but now the plugin takes a different path when applying the plugin again to the output of AD. I'm sure I have only a very superficial understanding of the issues, but I did this:
... turning core It's simplistic - I got a headache actually trying to examine the coercion expression. But I also can't immediately see why it's wrong. |
So with that in place, our code runs. |
If the problem is data constructor not being in scope for |
Huh. Strange that the trace doesn't mention |
Instead of
runTcInteractive
, it now runs theTcM
viainitTcDsForSolver
, followed byinitDsWithModGuts
.This makes
BuildDictionary
work better with orphan instances. When usingrunTcInteractive
we need to obtain theModuleName
s of the orphanModule
s, add them toic_imports
, and they are then loaded back intoModule
s. This not only wastes work, but we must filter out the hidden modules since hidden modules can't be loaded. This meansBuildDictionary
can't find orphans in hidden modules.In the new approach we can simply add the orphan
Module
s to theTcGblEnv
. No need to re-load them.I tested it in my work repository and it works as expected.
The use of
initTcDsForSolver
was suggested by Matthew Pickering in https://gitlab.haskell.org/ghc/ghc/-/issues/20499.Fixes #81.