darcs

Issue 2616 compilation errors with MonadFail

Title compilation errors with MonadFail
Priority Status unknown
Milestone Resolved in 2.14.2 STABLE
Superseder Nosy List jerith
Assigned To
Topics

Created on 2019-01-14.01:53:16 by jerith, last changed 2019-01-28.07:17:50 by ganesh.

Messages
msg20615 (view) Author: jerith Date: 2019-01-14.01:53:13
1. Summarise the issue (what were doing, what went wrong?)

as described at https://github.com/NixOS/nixpkgs/issues/53433, building
with LTS 13.0 fails with:

src/Darcs/Util/Tree.hs:420:11: error:
    • Could not deduce (Control.Monad.Fail.MonadFail m)
        arising from a do statement
        with the failable pattern ‘SubTree t''’
      from the context: Monad m
        bound by the type signature for:
                   partiallyUpdateTree :: forall (m :: * -> *).
                                          Monad m =>
                                          (TreeItem m -> m (TreeItem m))
                                          -> (AnchoredPath -> TreeItem m
-> Bool)
                                          -> Tree m
                                          -> m (Tree m)
        at src/Darcs/Util/Tree.hs:(415,1)-(416,86)
      Possible fix:
        add (Control.Monad.Fail.MonadFail m) to the context of
          the type signature for:
            partiallyUpdateTree :: forall (m :: * -> *).
                                   Monad m =>
                                   (TreeItem m -> m (TreeItem m))
                                   -> (AnchoredPath -> TreeItem m ->
Bool) -> Tree m -> m (Tree m)
    • In a stmt of a 'do' block:
        SubTree t'' <- fun . SubTree
                         $ t {items = items', treeHash = NoHash}
      In the expression:
        do items' <- M.fromList
                       <$> mapM (maybeupdate path) (listImmediate t)
           SubTree t'' <- fun . SubTree
                            $ t {items = items', treeHash = NoHash}
           return t''
      In an equation for ‘go’:
          go path t
            = do items' <- M.fromList
                             <$> mapM (maybeupdate path) (listImmediate t)
                 SubTree t'' <- fun . SubTree
                                  $ t {items = items', treeHash = NoHash}
                 return t''
    |
420 |           SubTree t'' <- fun . SubTree $ t { items = items'
    |           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...

Applying
https://github.com/jerith666/nixpkgs/commit/f97acd9da6e9dc1fbf83bd48a25371357a2b8af6
to fix that, the next error is:

[222 of 224] Compiling Darcs.UI.Defaults ( src/Darcs/UI/Defaults.hs,
dist/build/Darcs/UI/Defaults.o )
[223 of 224] Compiling Darcs.UI.RunCommand ( src/Darcs/UI/RunCommand.hs,
dist/build/Darcs/UI/RunCommand.o )
[224 of 224] Compiling Darcs.UI.Commands.Help (
src/Darcs/UI/Commands/Help.hs, dist/build/Darcs/UI/Commands/Help.o )
dist/build/darcs/darcs.1: openFile: does not exist (No such file or
directory)
builder for
'/nix/store/j3q93kwc6glvs8y2zkz9vmyxrh11mjmi-darcs-2.14.1.drv' failed
with exit code 1
error: build of
'/nix/store/j3q93kwc6glvs8y2zkz9vmyxrh11mjmi-darcs-2.14.1.drv' failed

2. What behaviour were you expecting instead?

successful compilation

3. What darcs version are you using? (Try: darcs --exact-version)

2.14.1

4. What operating system are you running?

NixOS
msg20616 (view) Author: ganesh Date: 2019-01-14.07:38:23
Thanks for the report! The MonadFail issue in the title is because we don't 
support base 4.12/ghc 8.6 yet, I'll try to get that fixed soon. The problem 
with darcs.1 I'm less sure about off the top of my head. I've commented on 
the nixpkgs issue, we can discuss it further there to at least isolate the 
trigger.
msg20648 (view) Author: ganesh Date: 2019-01-26.21:45:51
The MonadFail problem is fixed in 2.14.2. Nailing down the darcs.1 
issue is proving harder, I'll raise a separate ticket for it once I can 
reproduce it outside nixpkgs.
msg20649 (view) Author: bf Date: 2019-01-28.06:43:20
> The MonadFail problem is fixed in 2.14.2. Nailing down the darcs.1 
> issue is proving harder, I'll raise a separate ticket for it once I can 
> reproduce it outside nixpkgs.

FWIW I have stumbled over this one, too. What I did is to add darcs as a
subproject (in cabal.project file) of darcsden. I think it failed
because this will build only the library component.
msg20650 (view) Author: ganesh Date: 2019-01-28.07:17:48
Thanks for the hint - I now see the flag is being set to false.
By coincidence hvr pointed out to me last night that a lot of
our flags are "automatic" which can cause unexpected behaviour.
I'll dig more into why it's happening.
History
Date User Action Args
2019-01-14 01:53:16jerithcreate
2019-01-14 07:38:25ganeshsetmessages: + msg20616
2019-01-26 21:45:53ganeshsetstatus: unknown -> resolved
messages: + msg20648
resolvedin: 2.14.2 STABLE
2019-01-28 06:43:23bfsetstatus: resolved -> unknown
messages: + msg20649
2019-01-28 07:17:50ganeshsetmessages: + msg20650