Adapt to MonadFail changes in GHC 8.8.#516
Conversation
|
Migration is probably widely known. Citing release docs: Link: https://gitlab.haskell.org/ghc/ghc/wikis/migration/8.8#base-41300 I'm writing error-handling PR, so, looked at code, and 👍 |
|
Travis timed-out due to your commit got into timing of compiling Cabal & such. If you want - you can re-push this change, so Travis compiles it. |
|
I restarted the builds. |
Note that this is an enforced public API change. I went with changing the `MonadFile` typeclass rather than threading through a `MonadFail` at every use-site, but that would be possible as well if it makes more semantic sense - however, since `MonadFile` already seems to require an IO-ish implementation, adding that superclass doesn't seem like an imposition.
f5b91aa to
37c2bb2
Compare
|
I've given it another kick; let's see if the cache is full enough for it to complete now... |
|
Doesn't seem like the cache is warming up at all. |
|
I think |
|
Trying to build and upload to cachix now. |
|
I'm having all kinds of problems building this branch... |
|
Note that this branch doesn't currently build with cabal because EDIT: It now seems that |
|
I think it might be a good idea to include these changes in the upcoming release, even if real GHC-8.8 support is still blocked by Users who don't mind depending on this fork could then still easily compile with GHC-8.8. Users of GHC-8.4 and 8.6 don't lose anything. |
|
I just need to find time then to reproduce this build and make sure it works for me before uploading. |
Note that this is an enforced public API change.
I went with changing the
MonadFiletypeclass rather than threadingthrough a
MonadFailat every use-site, but that would be possible aswell if it makes more semantic sense - however, since
MonadFilealready seems to require an IO-ish implementation, adding that
superclass doesn't seem like an imposition.