Skip to content
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

hint-0.9.0.7 improvements #160

Merged
merged 14 commits into from
Jun 15, 2023
Merged

hint-0.9.0.7 improvements #160

merged 14 commits into from
Jun 15, 2023

Conversation

gelisam
Copy link
Contributor

@gelisam gelisam commented Jun 15, 2023

I want to make a release with #152 and #158, but I would like to address a few low-hanging fruits first:

And if I have time (probably not):

  • test the ghc-environment-files workflow
  • test the catch around setImports workflow
  • simplify reinstallSupportModule to only load the targets once

Warn right away about the common mistake of importing a module from the
current package.

Warn about the bug with implicit kinds.

Document where hint looks for packages.

Clarify the behaviour of 'loadModules'.

Advertize that it is possible, but difficult, to run hint without ghc
being installed.
@gelisam gelisam changed the title improve documentation hint-0.9.0.7 improvements Jun 15, 2023
as it was written, the test could have passed because 1 divided by 0
returned NaN or something, not because it threw an exception which was
caught.
A very common use case for hint is to interpret code which has access to
the same packages as the compiled program which calls hint. the easiest
way to accomplish that is to compile that program using
"cabal build --write-ghc-environment-files=always", as that will write
down all the necessary information to a file which hint can read at
runtime. This test makes sure that this common workflow continues to
work in the future.
such as the fact that hint is implemented via the ghc library
first show the user whether the library looks like it might possibly fit
their use case, and only then write the small print explaining the
circumstances in which it might not.
Previously, we were adding the phantom module to the list of targets,
and then loading all the targets, and then if there are more targets to
load, we were setting the targets to those plus the phantom module, and
then loading all the targets again.

Now, we simply set the targets to those plus the phantom module, and
then we load all the targets, once.
previously we were avoiding an extra LoadAllTargets when we knew that
there were no modules to load, but now that there is only one call to
LoadAllTargets, there is no reason to distinguish that case.
In the previous two commits, I said that installSupportModule was
calling LoadAllTargets twice in a row. That was only true on ghc-9.4+;
on older versions of ghc, the first call was actually a call to
"LoadUpTo phantomModule".

Now that there is only one call, "LoadUpTo phantomModule" is
insufficient, because we want to load all the targets, not just the
phantom module.
now that it always returns GHC.Succeeded, it might as well just return
unit.
@gelisam gelisam merged commit 97b5f99 into main Jun 15, 2023
8 checks passed
@gelisam gelisam deleted the hint-0.9.0.7-improvements branch June 15, 2023 18:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant