Defer type errors #47

jacg · 2019-09-12T14:05:32Z

At present, all sorts of useful IDE featrues, such as diagnostics reporting and go-to-definition, stop working at the first sign of a type error. This PR attempts to fix this. The plan is:

defer type errors
report them as warnings during typechecking
re-upgrade them to errors after type checking

TODO:

(EDIT: fixed by Make sure warnings use unqualified names where appropriate #59) ~~The current implementation breaks old behaviour by changing the text of type error messages to contain fully qualified type names, e.g: GHC.Types.Int appears instead of Int.~~
There are other things besides type errors that could be deferred?
- Type Errors
- Typed Holes
- Out of scope variables

digitalasset-cla · 2019-09-12T14:05:40Z

All committers have signed the CLA.

hsenag · 2019-09-12T23:34:18Z

I spent a while experimenting to try to understand where the GHC.Types.Int is coming from and still have no clue :-(

It doesn't happen with ghc or ghci itself if you use -fdefer-type-errors on the command-line. It also happens from setting Opt_DeferTypeErrors alone, no matter whether that's just in typecheckModule or in runGhcEnv.

I also tried setting an unrelated flag (Opt_PrintExplicitKinds) in case just the very act of calling gopt_set was triggering the change, but the error messages were still as expected then.

hsenag · 2019-09-13T10:12:42Z

It looks like the qualified names are something general to do with how ghcide gets warnings and nothing to do with setting Opt_DeferTypeErrors.

In the following code, there's a warning about the unnecessary constraint Ord a, and the whole warning has fully qualified names. If you add -Werror to OPTIONS_GHC to turn it into an error, it has unqualified names.

{-# OPTIONS_GHC -Wredundant-constraints #-}
module Foo where
foo :: Ord a => Int -> a -> Int
foo a b = a + 1

hsenag · 2019-09-13T11:04:49Z

I tracked down why it's happening (I think) - the warnings collection code uses mkPlainWarnMsg which always qualifies symbols. We can extract the right setting with queryQual from the PprStyle and use mkWarnMsg instead, I'll send a patch later.

hsenag · 2019-09-13T13:42:43Z

I think the three things we can/want to defer are

type-errors
typed-holes
out-of-scope-variables

I think at least typed-holes is implied by type-errors.

A few comments on the code:

I'm not sure about the merits of the current gyrations compared to just setting the option once-and-for-all in runGhcEnv (which is a lot simpler code-wise). @ndmitchell may have a view.
Perhaps ghcide should detect if the user has explicitly set the relevant -fdefer option, and in that case not promote the warnings back to errors. I think this a nice-to-have though, you could just open up a follow-up issue rather than doing it.
I'm a bit confused about how the various flags get set, but when I was experimenting to understand the qualified names issue, I found I didn't need to set the Opt_Warn flag to get the warnings. So perhaps that can be removed.

jacg · 2019-09-13T14:24:55Z

I found I didn't need to set the Opt_Warn flag to get the warnings. So perhaps that can be removed.

I've removed it, and the tests still pass, as demonstrated on the branch rebased on #59 [Edit: this is now available on this branch too.]

ndmitchell · 2019-09-13T14:55:25Z

I'm not sure about the merits of the current gyrations compared to just setting the option once-and-for-all in runGhcEnv (which is a lot simpler code-wise). @ndmitchell may have a view.

The gyrations are only ugly because Haskell records suck, but we should just fix that problem at source 😝.

I prefer having the dynflag stuff localised where possible since it's just unclear what the impact is, and this way we can actually get at the original to see if the user had already set deferred type errors and thus avoid promoting them, whereas setting them in runGhcEnv makes that harder. However, I'm not against the other if people think it has benefits.

jacg · 2019-09-13T15:22:09Z

I think the three things we can/want to defer are

type-errors

typed-holes

out-of-scope-variables

I think at least typed-holes is implied by type-errors.

That hypothesis seems to be disproved by the commit entitled TEST: Downgrade severity of typed holes Error -> Warning which I have just pushed.

BTW, this branch is now rebased on top of #59, as the latter seems to be cruicial to its correctness.

jacg · 2019-09-13T15:25:45Z

I prefer having the dynflag stuff localised where possible since it's just unclear what the impact is

Agreed.

jacg · 2019-09-13T23:37:06Z

This seems to be working now, including the extra deferals proposed by @hsenag, so I think it's ready for review.

It does crucially depend on #59, therefore it is rebased on top of it.

I have gradually modified the tests and implementation in separate commits, in order to document which approaches work / don't work and which flags are needed / not need.

jacg · 2019-09-13T23:40:25Z

I have gradually modified the tests and implementation in separate commits, in order to document which approaches work / don't work and which flags are needed / not need.

Unfortunately Github presents the commits in timestamp order, rather than DAG order, thoroughly confusing the story I'm trying to tell!

hsenag · 2019-09-13T23:48:56Z

This seems to be working now

Excellent!

Unfortunately Github presents the commits in timestamp order, rather than DAG order, thoroughly confusing the story I'm trying to tell!

Wouldn't you have needed to use merge commits to get an actual DAG? I just see a linear history in gitk as well.

I'd be inclined to squish it down to a single commit now (maybe that'll happen anyway when it's merged, I'm not too familiar with what github does). Having lots of logical commits is great during development to keep track of uncertain options, but is not necessarily so helpful when the feature is done. If there's something future readers of the code should understand, a comment is likely to be more discoverable than git history.

jacg · 2019-09-14T00:06:49Z

Wouldn't you have needed to use merge commits to get an actual DAG?

It's Directed, it's Acyclic, and it's a Graph, so it's a DAG! (A single vertex is a DAG ... even an empty graph is a DAG ... not very interesting ones, admittedly :-)

I'd be inclined to squish it down to a single commit now

I'll leave that to the owners of this repo to decide. I've crafted the commits like this, so that the necessity, or otherwise, of various bits is easily verifiable.

ndmitchell · 2019-09-14T08:29:34Z

At DA we always used squash merges so that you have a guarantee your history all passed all CI tests, which is useful for bisecting.

ndmitchell

This looks awesome! Looking forward to using this.

jacg · 2019-09-14T08:32:13Z

It certainly was nice having it available in my editor while hacking on it!

jacg · 2019-09-14T08:35:22Z

At DA we always used squash merges so that you have a guarantee your history all passed all CI tests, which is useful for bisecting.

Haven't done it recently, but I recall having a workflow where --first-parent let you have the best of both worlds: easily bisectable master and detailed, documenting feature branches.

cocreature · 2019-09-14T11:03:49Z

Thanks a lot for the contribution and sorry for my lack of response. I hope to get around to taking a closer look at this next week.

hsenag · 2019-09-14T19:41:31Z

One thing I noticed after using this for a bit is that the text of the "error" still says warning:

C:\msys64\home\ganesh\darcs\wip\src\Darcs\Patch\Bundle.hs:181:5: warning:

Regardless of minor glitches like that, now I've been using it for a little while, I can also confirm that it is indeed awesome for improving the development experience :-)

jacg · 2019-09-14T21:20:48Z

the text of the "error" still says warning

Yes, I had also noticed this glitch while using it, but it seemed very much a second-order problem, and it slipped my mind. Maybe I'll manage to have a look at it and fix it before @cocreature gets around to reviewing it.

cocreature

Looks great, thank you very much!

It would be great if you could address two things before merging:

I would like this behavior to be configurable in IdeOptions so add a field there that allows you to turn this on/off.
A test that depends on the new behavior would be great.

cocreature · 2019-09-16T11:51:19Z

test/exe/Main.hs

+            , "foo a = _ a"
+            ]
+      _ <- openDoc' "Testing.hs" "haskell" content
+      expectDiagnostics


I’m not sure what you are trying to test here. Afaik, this test passes without any of your changes as well? It would be good to get a test that actually relies on this behavior.

I guess you want to test that the undemoting works? Looks reasonable in that case but a comment would be good and it would still be nice to have a test that checks that actually relies on deferring the errors.

Yes, the point is that the definition of this test (and a couple of others like it) evolves through this sequence of commits, and the implementation has to follow the tests through the Error -> Warning -> Error route. When all is said and done, we end up where we started (error) but these test document, in the sequence of commits, that each individual step did what it was supposed to; or, quite importantly in the case of the first attempt to defer type errors, that the obvious approach does NOT work, justifying the more complex implementation that ended up being used.

Anyway, I have added tests which detect if any of the deferrals are removed. These, of course, will have to be duplicated once I've added the deferral on/off switch.

jacg · 2019-09-16T14:01:29Z

I would like this behavior to be configurable in IdeOptions so add a field there that allows you to turn this on/off.

Presumably you would want a single option that switches all three deferrals together ... or three different options, one for each deferral?

For completeness, the three things being deferred are:

type errors
typed holes
out of scope variables

If there are to be 3 separate ones, the names are fairly obvious:

optDeferTypeErrors
optDeferTypedHoles
optDeferOutOfScopeVariables

which closely follow similar names in DynFlags.

It's less obvious what the name would be if there is to be a single option controlling all three. optDefer? Otherwise the name starts getting veeeeery long indeed.

This test fails, thereby falsifying the hypothesis that `Opt_DeferTypeErrors` implies `Opt_DeferTypedHoles`.

... and pass the failing test.

... failing the test until the implementation catches up in the next commit.

... and pass the test once again.

... test fails until next commit.

... passing the test which was changed in the last commit.

... failing the test, and forcing the implementation to catch up.

... passing the test once again.

cocreature · 2019-09-17T11:17:32Z

The easiest option to get access to the options is probably to call getIdeOptions in typeCheckRule and then pass that as an argument to typecheckModule.

As for the tests, I don’t mind if we don’t test the non-defer codepath right now.

jacg · 2019-09-17T11:33:27Z

If you don't need tests for it, then I have pushed something that seems to do the job. I have tested it informally by setting the default to False and observing the deferral tests fail, while they pass with the default set to True.

jacg · 2019-09-17T11:34:42Z

Any preference as to the position in which the new parameter of typecheckModule should occupy?

cocreature · 2019-09-17T11:38:40Z

src/Development/IDE/Core/Compile.hs

@@ -82,19 +82,22 @@ computePackageDeps env pkg = do

 -- | Typecheck a single module using the supplied dependencies and packages.
 typecheckModule
-    :: HscEnv
+    :: Bool


Putting it as the first parameter is very reasonable but it would be great if we could get a newtype for this to get something a bit more informative than Bool.

cocreature · 2019-09-17T12:03:09Z

src/Development/IDE/Types/Options.hs

@@ -44,9 +45,16 @@ data IdeOptions = IdeOptions
    -- ^ the ```language to use
  , optNewColonConvention :: Bool
    -- ^ whether to use new colon convention
+  , optDefer :: Bool


Suggested change

, optDefer :: Bool

, optDefer :: IdeDefer

cocreature · 2019-09-17T12:03:31Z

src/Development/IDE/Types/Options.hs

@@ -63,6 +71,7 @@ defaultIdeOptions session = IdeOptions
    ,optReportProgress = IdeReportProgress False
    ,optLanguageSyntax = "haskell"
    ,optNewColonConvention = False
+    ,optDefer = True


Suggested change

,optDefer = True

,optDefer = IdeDefer True

cocreature · 2019-09-17T12:03:59Z

src/Development/IDE/Core/Rules.hs

@@ -312,7 +312,8 @@ typeCheckRule =
        tms <- uses_ TypeCheck (transitiveModuleDeps deps)
        setPriority priorityTypeCheck
        packageState <- hscEnv <$> use_ GhcSession file
-        liftIO $ typecheckModule packageState tms pm
+        IdeOptions{ optDefer = defer} <- getIdeOptions
+        liftIO $ typecheckModule (IdeDefer defer) packageState tms pm


Suggested change

liftIO $ typecheckModule (IdeDefer defer) packageState tms pm

liftIO $ typecheckModule defer packageState tms pm

jacg · 2019-09-17T12:18:44Z

Hmm, that was confusing: I think that your suggestions, which were almost identical to the changes I had just pushed, appeared here just after the push, so I was left wondering why on earth my changes were appearing as your suggestions.

cocreature

Looks great, thank you so much!

jacg · 2019-09-17T12:25:06Z

You're welcome. It's a pleasure. Thank you for ghcide; it's going to lead to a huge improvement in the Haskell development experience.

@hsenag

* 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

@hsenag

* 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

@hsenag

* 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

@hsenag

* 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

@hsenag

* 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

jacg force-pushed the defer-type-err branch from 2ba97f2 to e4bec00 Compare September 13, 2019 06:31

hsenag mentioned this pull request Sep 13, 2019

Make sure warnings use unqualified names where appropriate #59

Merged

jacg force-pushed the defer-type-err branch from e4bec00 to 06cbc63 Compare September 13, 2019 15:16

jacg force-pushed the defer-type-err branch from e540ea6 to 0ed59c8 Compare September 13, 2019 23:29

jacg marked this pull request as ready for review September 13, 2019 23:32

jacg force-pushed the defer-type-err branch from 0ed59c8 to 7d22abd Compare September 14, 2019 08:26

ndmitchell approved these changes Sep 14, 2019

View reviewed changes

jacg force-pushed the defer-type-err branch from 7d22abd to e805d8b Compare September 14, 2019 12:21

jacg force-pushed the defer-type-err branch from e805d8b to 4655e51 Compare September 15, 2019 20:12

cocreature reviewed Sep 16, 2019

View reviewed changes

jacg added 8 commits September 17, 2019 11:29

TEST: Downgrade severity of typed holes Error -> Warning

cbf20d9

This test fails, thereby falsifying the hypothesis that `Opt_DeferTypeErrors` implies `Opt_DeferTypedHoles`.

Defer typed holes

9fae96c

... and pass the failing test.

TEST: Reinstate severity of typed holes

f21d59f

... failing the test until the implementation catches up in the next commit.

Upgrade severity of deferred Typed Holes after typecheck

246d99c

... and pass the test once again.

TEST: Degrade variable out of scope from Error to Warning

f4ee843

... test fails until next commit.

Defer out of scope variables

efb92c1

... passing the test which was changed in the last commit.

TEST: Reinstate severity of out of scope variables

f086d69

... failing the test, and forcing the implementation to catch up.

Upgrade severity of deferred out of scope vars after typecheck

bf7c4af

... passing the test once again.

jacg force-pushed the defer-type-err branch from 4655e51 to 28fe605 Compare September 17, 2019 09:30

Add explicit tests for deferrals

b5961e7

Add IdeOption for deferral switching

1e08d50

jacg force-pushed the defer-type-err branch from 28fe605 to 1e08d50 Compare September 17, 2019 11:32

Improve documentation of optDefer

e162696

cocreature reviewed Sep 17, 2019

View reviewed changes

jacg force-pushed the defer-type-err branch from 7f85128 to 14f2b3e Compare September 17, 2019 12:01

cocreature reviewed Sep 17, 2019

View reviewed changes

Add IdeDefer newtype

6a33708

jacg force-pushed the defer-type-err branch from 14f2b3e to 6a33708 Compare September 17, 2019 12:17

cocreature approved these changes Sep 17, 2019

View reviewed changes

cocreature merged commit a162e81 into haskell:master Sep 17, 2019

	liftIO $ typecheckModule (IdeDefer defer) packageState tms pm
	liftIO $ typecheckModule defer packageState tms pm

Defer type errors #47

Defer type errors #47

Conversation

jacg commented Sep 12, 2019 • edited Loading

digitalasset-cla commented Sep 12, 2019 • edited Loading

hsenag commented Sep 12, 2019

hsenag commented Sep 13, 2019

hsenag commented Sep 13, 2019

hsenag commented Sep 13, 2019

jacg commented Sep 13, 2019 • edited Loading

ndmitchell commented Sep 13, 2019

jacg commented Sep 13, 2019

jacg commented Sep 13, 2019

jacg commented Sep 13, 2019

jacg commented Sep 13, 2019

hsenag commented Sep 13, 2019

jacg commented Sep 14, 2019

ndmitchell commented Sep 14, 2019

ndmitchell left a comment

Choose a reason for hiding this comment

jacg commented Sep 14, 2019

jacg commented Sep 14, 2019

cocreature commented Sep 14, 2019 • edited Loading

hsenag commented Sep 14, 2019

jacg commented Sep 14, 2019

cocreature left a comment

Choose a reason for hiding this comment

cocreature Sep 16, 2019

Choose a reason for hiding this comment

cocreature Sep 16, 2019

Choose a reason for hiding this comment

jacg Sep 17, 2019

Choose a reason for hiding this comment

jacg commented Sep 16, 2019

cocreature commented Sep 17, 2019

jacg commented Sep 17, 2019

jacg commented Sep 17, 2019

cocreature Sep 17, 2019

Choose a reason for hiding this comment

cocreature Sep 17, 2019

Choose a reason for hiding this comment

cocreature Sep 17, 2019

Choose a reason for hiding this comment

cocreature Sep 17, 2019

Choose a reason for hiding this comment

jacg commented Sep 17, 2019

cocreature left a comment

Choose a reason for hiding this comment

jacg commented Sep 17, 2019

jacg commented Sep 12, 2019 •

edited

Loading

digitalasset-cla commented Sep 12, 2019 •

edited

Loading

jacg commented Sep 13, 2019 •

edited

Loading

cocreature commented Sep 14, 2019 •

edited

Loading