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

mustache-2.4.0 failed to build in Stackage Nightly #58

Closed
juhp opened this issue Mar 8, 2022 · 6 comments
Closed

mustache-2.4.0 failed to build in Stackage Nightly #58

juhp opened this issue Mar 8, 2022 · 6 comments

Comments

@juhp
Copy link

juhp commented Mar 8, 2022

/var/stackage/work/unpack-dir/unpacked/mustache-2.4.0-44c4d43ecfe1fee11fb03ffd49b0580ed00eec5144067092801ef4256df77ef8/src/Text/Mustache/Internal/Types.hs:395:1: error:
    • Overlapping instances for Lift TemplateCache
        arising from a use of ‘lift’
      Matching instances:
        two instances involving out-of-scope types
        (use -fprint-potential-instances to see them all)
    • In the second argument of ‘Language.Haskell.TH.Lib.Internal.appE’, namely
        ‘(lift x2_aclX)’
      In the expression:
        (Language.Haskell.TH.Lib.Internal.appE
           ((Language.Haskell.TH.Lib.Internal.appE
               ((Language.Haskell.TH.Lib.Internal.appE
                   (Language.Haskell.TH.Lib.Internal.conE
                      ((Name (mkOccName "Template"))
                         (((NameG DataName)
                             (mkPkgName "mustache-2.4.0-7gu0iJzW3shKWbIZjtf98g"))
                            (mkModName "Text.Mustache.Internal.Types")))))
                  (lift x0_aclV)))
              (lift x1_aclW)))
          (lift x2_aclX)
      In a case alternative:
          Template x0_aclV x1_aclW x2_aclX
            -> (Language.Haskell.TH.Lib.Internal.appE
                  ((Language.Haskell.TH.Lib.Internal.appE
                      ((Language.Haskell.TH.Lib.Internal.appE
                          (Language.Haskell.TH.Lib.Internal.conE
                             ((Name (mkOccName "Template"))
                                (((NameG DataName)
                                    (mkPkgName "mustache-2.4.0-7gu0iJzW3shKWbIZjtf98g"))
                                   (mkModName "Text.Mustache.Internal.Types")))))
                         (lift x0_aclV)))
                     (lift x1_aclW)))
                 (lift x2_aclX)
    |
395 | deriveLift ''Template
    | ^^^^^^^^^^^^^^^^^^^^^

/var/stackage/work/unpack-dir/unpacked/mustache-2.4.0-44c4d43ecfe1fee11fb03ffd49b0580ed00eec5144067092801ef4256df77ef8/src/Text/Mustache/Internal/Types.hs:397:10: error:
    • Overlapping instances for Lift TemplateCache
        arising from a use of ‘Language.Haskell.TH.Syntax.$dmlift’
      Matching instances:
        two instances involving out-of-scope types
        (use -fprint-potential-instances to see them all)
    • In the expression:
        Language.Haskell.TH.Syntax.$dmlift
          @('ghc-prim-0.7.0:GHC.Types.LiftedRep) @(TemplateCache)
      In an equation for ‘lift’:
          lift
            = Language.Haskell.TH.Syntax.$dmlift
                @('ghc-prim-0.7.0:GHC.Types.LiftedRep) @(TemplateCache)
      In the instance declaration for ‘Lift TemplateCache’
    |
397 | instance Lift TemplateCache where
    |          ^^^^^^^^^^^^^^^^^^
@Bodigrim
Copy link

Bodigrim commented Mar 8, 2022

This is caused by new instances in unordered-containers-0.2.17.0, haskell-unordered-containers/unordered-containers#343

@Bodigrim
Copy link

Bodigrim commented Mar 8, 2022

@hasufell
Copy link

hasufell commented Mar 10, 2022

The resolver seems to prefer mustache-2.3.0 now, so it can pick unordered-containers-2.7. However, that leads to build failures and users need to specify bounds explicitly: commercialhaskell/stack#5298 (comment)

Note that cabal has two options here:

  1. pick mustache later than 2.3.0 and unordered-containers earlier than 2.7
  2. pick mustache lower than 2.3.1 and unordered-containers 2.7

Cabal seems to pick option 2, probably because the resolver works alphabetically and depth first.

@JustusAdam
Copy link
Owner

Presumably it should be possible to fix this by adding a VERSION guard to the deriveLift line. I will see if I can find the time to look into that but if anyone wants to take a stab it should be easy to add , just takes a bit to test it works.

@JustusAdam
Copy link
Owner

This was fixed in #59.

I will prepare a release to publish the fix

juhp added a commit to commercialhaskell/stackage that referenced this issue Mar 24, 2022
@juhp
Copy link
Author

juhp commented Mar 24, 2022

Thanks!

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

No branches or pull requests

4 participants