can't find modules after switch from v0.9.0.4 to v0.9.0.5

[polymorphicengine]

Hey,
I made some changes to my gui project for tidal recently and decided to publish a new release. I didn't change anything relating to hint, so I thought that the workflow I had should be still fine. I also decicded to use the newest version of hint (previously I used 0.9.0.4).

But I noticed that in the new release hint wasn't able to find any of the haskell modules. This makes me think something changed in the way the interpreter is called with arguments? The arguments I use with my interpreter are:

args:: String -> [String]
args lib = ["-clear-package-db", "-package-db", lib ++ "haskell-libs/package.conf.d", "-package-db", lib ++ "haskell-libs/package.db", "-v"]

where lib is dependent on the location of the binary file. This works fine with hint 0.9.0.4, but is apprently broken with the latest version.

[gelisam]

I confirm that I can reproduce this locally.

The only two changes which happened in 0.9.0.5 are to add support for ghc-9.2.1 and to refactor the code to make this support easier to add. Perhaps that refactoring accidentally broke something?

In any case, the first step is to write a test case so that this regression doesn't occur again!

[gelisam]

git bisect blames a73aceb, which is indeed a refactoring which shouldn't have changed anything; especially since it only affects logging!

Pinging @brandon-leapyear, who authored the refactoring. Any idea how that refactoring could possibly affect which package databases the ghc library can see?

[brandon-leapyear]

✨ _**This is an old work account. Please reference @brandonchinn178 for all future communication**_ ✨ <!-- updated by mention_personal_account_in_comments.py -->

…

--- The immediate thing that sticks out to me is I'm not sure why I put the modifyLogger call at the top instead of right before the `setDynFlags df2` line. If you move the modifyLogger line down, does that change anything?

On Sat, Mar 5, 2022, 7:30 PM Samuel Gélineau ***@***.***> wrote: git bisect blames a73aceb <a73aceb>, which is indeed a refactoring which shouldn't have changed anything; especially since it only affects logging! Pinging @brandon-leapyear <https://github.com/brandon-leapyear>, who authored the refactoring. Any idea how that refactoring could possibly affect which package databases the ghc library can see? — Reply to this email directly, view it on GitHub <#142 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGUC75LM24UZAJQCL2W76ULU6QRGVANCNFSM5O7O3R2Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[gelisam]

That fixes it, thanks!

[gelisam]

I have a hypothesis as to how configuring a logger can possibly have an effect on package databases. Here's the relevant code:

GHC.modifyLogger (const logger)
...
(df2, ...) <- parseDynamicFlags ... ["-package-db=..."]
GHC.setSessionDynFlags df2

I'm using ghc-8.4.4, and so modifyLogger is implemented in terms of setSessionDynFlags:

df <- getSessionDynFlags
setSessionDynFlags df{log_action = const logger $ DynFlags.log_action df}
...
(df2, ...) <- runGhc $ parseDynamicFlags ... ["-package-db=..."]
GHC.setSessionDynFlags df2

Observe that setSessionDynFlags is called twice: once without the -package-db arguments, and once with them. According to its documentation, setSessionDynFlags does many things, including reading the package database unless it has already been read. So I think the first call reads the default package database and sets some packageDbHasBeenRead flag indicating that the package databases have been read, then the second call, which should normally be reading the package databases specified by the -package-db arguments, skips reading the package databases because of the packageDbHasBeenRead flag.

[gelisam]

Now fixed in HEAD; the next step is to release a new version on hackage. And maybe to deprecate the version which has the bug?

[gelisam]

0.9.0.6 is now published, and 0.9.0.5 is now deprecated. Thank you both!