Build fails with GHC 8.8

[ekmett]

[1 of 1] Compiling Data.Vector.Unboxed.Deriving 

Data/Vector/Unboxed/Deriving.hs:129:42: error:
    • Couldn't match expected type ‘Maybe [TyVarBndr]’
                  with actual type ‘Name’
    • In the second argument of ‘NewtypeInstD’, namely ‘''MVector’
      In the expression:
        NewtypeInstD
          []
          ''MVector
          [s, typ]
          Nothing
          (NormalC mvName [(lazy, ConT ''MVector `AppT` s `AppT` rep)])
          []
      In an equation for ‘newtypeMVector’:
          newtypeMVector
            = NewtypeInstD
                []
                ''MVector
                [s, typ]
                Nothing
                (NormalC mvName [(lazy, ConT ''MVector `AppT` s `AppT` rep)])
                []
    |
129 |     let newtypeMVector = NewtypeInstD [] ''MVector [s, typ] MAYBE_KIND
    |                                          ^^^^^^^^^

Data/Vector/Unboxed/Deriving.hs:129:52: error:
    • Couldn't match expected type ‘Type’ with actual type ‘[Type]’
    • In the third argument of ‘NewtypeInstD’, namely ‘[s, typ]’
      In the expression:
        NewtypeInstD
          []
          ''MVector
          [s, typ]
          Nothing
          (NormalC mvName [(lazy, ConT ''MVector `AppT` s `AppT` rep)])
          []
      In an equation for ‘newtypeMVector’:
          newtypeMVector
            = NewtypeInstD
                []
                ''MVector
                [s, typ]
                Nothing
                (NormalC mvName [(lazy, ConT ''MVector `AppT` s `AppT` rep)])
                []
    |
129 |     let newtypeMVector = NewtypeInstD [] ''MVector [s, typ] MAYBE_KIND
    |                                                    ^^^^^^^^

Data/Vector/Unboxed/Deriving.hs:150:41: error:
    • Couldn't match expected type ‘Maybe [TyVarBndr]’
                  with actual type ‘Name’
    • In the second argument of ‘NewtypeInstD’, namely ‘''Vector’
      In the expression:
        NewtypeInstD
          []
          ''Vector
          [typ]
          Nothing
          (NormalC vName [(lazy, ConT ''Vector `AppT` rep)])
          []
      In an equation for ‘newtypeVector’:
          newtypeVector
            = NewtypeInstD
                []
                ''Vector
                [typ]
                Nothing
                (NormalC vName [(lazy, ConT ''Vector `AppT` rep)])
                []
    |
150 |     let newtypeVector = NewtypeInstD [] ''Vector [typ] MAYBE_KIND
    |                                         ^^^^^^^^

Data/Vector/Unboxed/Deriving.hs:150:50: error:
    • Couldn't match expected type ‘Type’ with actual type ‘[Type]’
    • In the third argument of ‘NewtypeInstD’, namely ‘[typ]’
      In the expression:
        NewtypeInstD
          []
          ''Vector
          [typ]
          Nothing
          (NormalC vName [(lazy, ConT ''Vector `AppT` rep)])
          []
      In an equation for ‘newtypeVector’:
          newtypeVector
            = NewtypeInstD
                []
                ''Vector
                [typ]
                Nothing
                (NormalC vName [(lazy, ConT ''Vector `AppT` rep)])
                []
    |
150 |     let newtypeVector = NewtypeInstD [] ''Vector [typ] MAYBE_KIND
    |                                                  ^^^^^
cabal: Failed to build vector-th-unbox-0.2.1.6 (which is required by
tabulation-hash-0). See the build log above for details.

Looks like template-haskell changed under you again.

[hvr]

Revised via https://hackage.haskell.org/package/vector-th-unbox-0.2.1.6/revisions/

fwiw, packages omitting bounds on a fast moving pkg such as template-haskell are almost always going to break sooner or later (sometimes in subtle not-so-noticeable ways); template-haskell related bounds are definitely in the top-10 of fixups that keep Trustees busy; so please use upper bounds to reduce our workload :-)

[mrkkrp]

I do not understand what is going on. criterion seem to build with GHC 8.8.1 now, at least according to its Travis CI runs. However, I'm trying to compile Megaparsec with GHC 8.8.1 and here is what I get:

https://travis-ci.org/mrkkrp/megaparsec/jobs/579429690#L278

It looks like the root of the problem is that criterion (which is a dependency of the benchmarks) depends on statistics which in turn depends on vector-th-unbox, which has uncompatible constraint for base and template-haskell. Can we resolve this somehow?

@hvr's update doesn't seem to resolve this, I just tried to re-run the tests today.

[leonschoorl]

@mrkkrp criterion is running their 8.8.1 test in "HEAD mode":
https://github.com/bos/criterion/blob/f6927ff71566abc796c257fc8017accc5a11fe19/.travis.yml#L31

This enables: https://github.com/bos/criterion/blob/f6927ff71566abc796c257fc8017accc5a11fe19/.travis.yml#L108-L117

Which adds some allow-newer options to the config to allow cabal to ignore the upper bound on base in vector-th-unbox.
It also add the head.hackage overlay which contains a patch to fix vector-th-unbox: https://gitlab.haskell.org/ghc/head.hackage/blob/master/patches/vector-th-unbox-0.2.1.6.patch