* TEST: Degrade type error to warning
It will be upgraded again later, but for the time being we want to see
whether the proposed mechanism for deferring type errors works at
all. As it turns out the first, most obvious approach, does not
work: this is documented in the next commit.
A second approach was found that does work, and appears in the commit
after the next.
This test is failing until the second approach is implemented.
* Defer type errors (first approach: FAILED)
The idea is to set the `-fdefer-type-errors` and
`-fwarn-deferred-type-errors` flags, by setting options
programatically inside the `Ghc` monad.
Deferral of type errors was not observed with this approach. The
(less obvious) approach used in the next commit seems to be more
successful.
* Defer type errors (second approach: SUCCESS)
This approach modifies the `ParsedModule` which is passed to
`GHC.typecheckedModule` by hie-core's `typecheckModule`.
Type warning deferral is now observed at run time, and the tests pass.
* TEST: Reinstate severity of type errors
So far, type errors have been deferred and reported as warnings.
The next step is to ensure that the deferred type errors are reported
as errors rather than warnings, once again. This test fails until the
implementation arrives in the next commit.
* Upgrade severity of deferred Type Errors after typecheck
... and make the test pass again.
* Hide helper functions in local scopes
* Stop setting Opt_WarnDeferredTypeErrors
... and the tests still pass, thereby confirming @hsenag's hypothesis
that this flag is not needed.
* TEST: Check that typed holes are reported as errors
* TEST: Downgrade severity of typed holes Error -> Warning
This test fails, thereby falsifying the hypothesis that
`Opt_DeferTypeErrors` implies `Opt_DeferTypedHoles`.
* Defer typed holes
... and pass the failing test.
* TEST: Reinstate severity of typed holes
... failing the test until the implementation catches up in the next
commit.
* Upgrade severity of deferred Typed Holes after typecheck
... and pass the test once again.
* TEST: Degrade variable out of scope from Error to Warning
... test fails until next commit.
* Defer out of scope variables
... passing the test which was changed in the last commit.
* TEST: Reinstate severity of out of scope variables
... failing the test, and forcing the implementation to catch up.
* Upgrade severity of deferred out of scope vars after typecheck
... passing the test once again.
* Add explicit tests for deferrals
* Add IdeOption for deferral switching
* Improve documentation of optDefer
* Add IdeDefer newtype
* Add code action for filling type holes
* Incorporate hole name into action title
Useful if more than one hole appears on the same line. Not so useful
if both of these holes are just `_` rather than `_name` (or more than
one hole on the same line has the same `_name`): In which case perhaps
some numbers could be attached to the action titles, to distinguish
the holes. But I suspect that this would not be worth the effort.
* Add tests for fill-type-hole actions
* Disable two tests on GHC 8.4
These test hints about local bindings, whic GHC 8.4 does not provide.
* Replace compilerVersion with new MIN_GHC_API_VERSION macro
Previously we had a mix of GHC_STABLE and checks on
__GLASGOW_HASKELL__. This PR changes this to always check on
MIN_GHC_API_VERSION. Depending on whether you use ghc-lib or not (now
controlled by a cabal flag), this macro expands to MIN_VERSION_ghc or
MIN_VERSION_ghc_lib.
These options don‘t work with ghcide as far as I can tell. I believe they stem from copying the config used for hie-wrapper. As ghcide does not support hlint yet I believe this infos to be misleading. That‘s why I suggest deleting it.
Because we are constructing the message objects ourselves, as
opposed to error messages which are constructed by GHC, we need
to take care to respect the passed-in 'PprStyle'.
The suggestions are extracted from GHC's error messages.
To make parsing these error messages easier, we set the flag
useUnicode=True, which makes GHC always use “smart quotes”.
