Failures on head.hackage
Recent failures
Several packages have been failing on nightly head.hackage runs.
Nightly pipeline | GHC commit | th-abstraction | base-compat | aeson | hashable | transformers-compat | yaml |
---|---|---|---|---|---|---|---|
https://gitlab.haskell.org/ghc/ghc/-/pipelines/63546 | a203ad85 | ok | ok | ok | ok | ok | ok |
https://gitlab.haskell.org/ghc/ghc/-/pipelines/63574 | 0196cc2b | FAIL | FAIL | ok | ok | ok | ok |
https://gitlab.haskell.org/ghc/ghc/-/pipelines/63632 | f70a0239 | FAIL | FAIL | FAIL | FAIL | FAIL | ok |
https://gitlab.haskell.org/ghc/ghc/-/pipelines/63684 | f11d9c27 | FAIL | FAIL | FAIL | FAIL | ok | ok |
https://gitlab.haskell.org/ghc/ghc/-/pipelines/63719 | e9e7a00d | FAIL | FAIL | FAIL | FAIL | FAIL | FAIL |
https://gitlab.haskell.org/ghc/ghc/-/pipelines/63756 | 2bfad50f | FAIL | FAIL | FAIL | FAIL | FAIL | ok |
https://gitlab.haskell.org/ghc/ghc/-/pipelines/63774 | 7825fef9 | FAIL | FAIL | FAIL | FAIL | FAIL | ok |
https://gitlab.haskell.org/ghc/ghc/-/pipelines/63785 | 7825fef9 | FAIL | FAIL | FAIL | FAIL | ok | ok |
Error messages
No pattern; in fact, they're all different.
th-abstraction:
src/Language/Haskell/TH/Datatype.hs:181:31: error: [GHC-83865]
• Expecting one more argument to ‘TyVarBndr’
Expected a type, but ‘TyVarBndr’ has kind ‘* -> *’
• In the type ‘[TyVarBndr]’
In the definition of data constructor ‘ConstructorInfo’
In the data declaration for ‘ConstructorInfo’
|
181 | , constructorVars :: [TyVarBndr] -- ^ Constructor type parameters
| ^^^^^^^^^
base-compat:
src/Data/Semigroup/Compat.hs:25:5: error: [GHC-76037]
Not in scope: type constructor or class ‘Option’
|
25 | , Option(..)
| ^^^^^^^^^^
src/Data/Semigroup/Compat.hs:26:5: error: [GHC-76037]
Not in scope: ‘option’
|
26 | , option
|
aeson:
Data/Aeson/Types/Internal.hs:130:5: error: [GHC-54721]
‘fail’ is not a (visible) method of class ‘Monad’
|
130 | fail msg = Parser $ \kf _ks -> kf msg
| ^^^^
hashable:
src/Data/Hashable/Class.hs:680:32: error: [GHC-76037]
Not in scope: ‘TA.aBA’
NB: the module ‘Data.Text.Array’ does not export ‘aBA’.
|
680 | hashByteArrayWithSalt (TA.aBA arr) (off `shiftL` 1) (len `shiftL` 1)
| ^^^^^^
src/Data/Hashable/Class.hs:688:37: error: [GHC-76037]
Not in scope: ‘TA.aBA’
NB: the module ‘Data.Text.Array’ does not export ‘aBA’.
|
688 | (hashByteArrayWithSalt (TA.aBA arr) (off `shiftL` 1) (len `shiftL` 1) s)
| ^^^^^^
transformers-compat:
generics/Data/Functor/Classes/Generic/Internal.hs:819:10: error: [GHC-39999]
• Could not deduce ‘Eq (FunctorClassesDefault f a)’
arising from the head of a quantified constraint
arising from the superclasses of an instance declaration
from the context: (GEq1 NonV4 (Rep1 f), Generic1 f)
bound by the instance declaration
at generics/Data/Functor/Classes/Generic/Internal.hs:819:10-75
or from: Eq a
bound by a quantified context
at generics/Data/Functor/Classes/Generic/Internal.hs:819:10-75
Possible fix:
If the constraint looks soluble from a superclass of the instance context,
read 'Undecidable instances and loopy superclasses' in the user manual
• In the instance declaration for ‘Eq1 (FunctorClassesDefault f)’
|
819 | instance (GEq1 NonV4 (Rep1 f), Generic1 f) => Eq1 (FunctorClassesDefault f) where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
generics/Data/Functor/Classes/Generic/Internal.hs:821:10: error: [GHC-39999]
• Could not deduce ‘Ord (FunctorClassesDefault f a)’
arising from the head of a quantified constraint
arising from the superclasses of an instance declaration
from the context: (GOrd1 NonV4 (Rep1 f), Generic1 f)
bound by the instance declaration
at generics/Data/Functor/Classes/Generic/Internal.hs:821:10-77
or from: Ord a
bound by a quantified context
at generics/Data/Functor/Classes/Generic/Internal.hs:821:10-77
Possible fix:
If the constraint looks soluble from a superclass of the instance context,
read 'Undecidable instances and loopy superclasses' in the user manual
• In the instance declaration for ‘Ord1 (FunctorClassesDefault f)’
|
821 | instance (GOrd1 NonV4 (Rep1 f), Generic1 f) => Ord1 (FunctorClassesDefault f) where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
generics/Data/Functor/Classes/Generic/Internal.hs:823:10: error: [GHC-39999]
• Could not deduce ‘Read (FunctorClassesDefault f a)’
arising from the head of a quantified constraint
arising from the superclasses of an instance declaration
from the context: (GRead1 NonV4 (Rep1 f), Generic1 f)
bound by the instance declaration
at generics/Data/Functor/Classes/Generic/Internal.hs:823:10-79
or from: Read a
bound by a quantified context
at generics/Data/Functor/Classes/Generic/Internal.hs:823:10-79
Possible fix:
If the constraint looks soluble from a superclass of the instance context,
read 'Undecidable instances and loopy superclasses' in the user manual
• In the instance declaration for ‘Read1 (FunctorClassesDefault f)’
|
823 | instance (GRead1 NonV4 (Rep1 f), Generic1 f) => Read1 (FunctorClassesDefault f) where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
generics/Data/Functor/Classes/Generic/Internal.hs:825:10: error: [GHC-39999]
• Could not deduce ‘Show (FunctorClassesDefault f a)’
arising from the head of a quantified constraint
arising from the superclasses of an instance declaration
from the context: (GShow1 NonV4 (Rep1 f), Generic1 f)
bound by the instance declaration
at generics/Data/Functor/Classes/Generic/Internal.hs:825:10-79
or from: Show a
bound by a quantified context
at generics/Data/Functor/Classes/Generic/Internal.hs:825:10-79
Possible fix:
If the constraint looks soluble from a superclass of the instance context,
read 'Undecidable instances and loopy superclasses' in the user manual
• In the instance declaration for ‘Show1 (FunctorClassesDefault f)’
|
825 | instance (GShow1 NonV4 (Rep1 f), Generic1 f) => Show1 (FunctorClassesDefault f) where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
yaml:
src/Data/Yaml/Internal.hs:148:3: error:
Ambiguous occurrence ‘AesonException’
It could refer to
either ‘Data.Aeson.AesonException’,
imported from ‘Data.Aeson’ at src/Data/Yaml/Internal.hs:37:1-17
or ‘Data.Yaml.Internal.AesonException’,
defined at src/Data/Yaml/Internal.hs:98:23
|
148 | AesonException s -> "Aeson exception:\n" ++ s
| ^^^^^^^^^^^^^^
src/Data/Yaml/Internal.hs:366:26: error:
Ambiguous occurrence ‘AesonException’
It could refer to
either ‘Data.Aeson.AesonException’,
imported from ‘Data.Aeson’ at src/Data/Yaml/Internal.hs:37:1-17
or ‘Data.Yaml.Internal.AesonException’,
defined at src/Data/Yaml/Internal.hs:98:23
|
366 | Left e -> Left $ AesonException e
| ^^^^^^^^^^^^^^
src/Data/Yaml/Internal.hs:374:26: error:
Ambiguous occurrence ‘AesonException’
It could refer to
either ‘Data.Aeson.AesonException’,
imported from ‘Data.Aeson’ at src/Data/Yaml/Internal.hs:37:1-17
or ‘Data.Yaml.Internal.AesonException’,
defined at src/Data/Yaml/Internal.hs:98:23
|
374 | Left e -> Left $ AesonException e
| ^^^^^^^^^^^^^^
I just was struck by the likelihood that head.hackage does not test a static set of packages, but pulls the latest data from Hackage. Thus it may be sensitive to new incompatibilities caused by breaking changes and lax upper bounds. Is that so?