GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-02-12T13:02:19Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/20890Multiple home units and Backpack together2024-02-12T13:02:19ZMatthew PickeringMultiple home units and Backpack togetherMultiple Home Units opens up some more natural implementation strategies for backpack but currently
Opportunities
* Unit instantiations can be expressed more naturally in terms of unit dependencies rather than shoe-horned into the mod...Multiple Home Units opens up some more natural implementation strategies for backpack but currently
Opportunities
* Unit instantiations can be expressed more naturally in terms of unit dependencies rather than shoe-horned into the module graph.
Known Problems
* Hole units assume a singular home unit (see the special case for `loadInterface` for `isHoleModule`).
* No tests at all combining MHU/Backpack
All we need is a backpack lover to try and wrangle things so that things work nicely!https://gitlab.haskell.org/ghc/ghc/-/issues/24357Backpack Regression for Representation-Polymorphic Binders2024-01-30T14:59:19ZAndrew MartinBackpack Regression for Representation-Polymorphic Binders## Summary
If you use `let x = Z`, where the type of `Z` is `TYPE R`, where `R` is an abstract top-level runtime rep from a signature, you get a compiler panic. But if you write `case Z of {x -> ...}`, the panic goes away.
This did not...## Summary
If you use `let x = Z`, where the type of `Z` is `TYPE R`, where `R` is an abstract top-level runtime rep from a signature, you get a compiler panic. But if you write `case Z of {x -> ...}`, the panic goes away.
This did not happen in GHC 8.10 or in GHC 9.2 (I have not tested GHC 9.0), but it happens in GHC 9.4 and every release since then.
## Steps to reproduce
Here is a minimal reproducer:
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE UnboxedTuples #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE PolyKinds #-}
unit example where
signature Order where
import GHC.Exts
data R :: RuntimeRep
data E :: TYPE R
pickMinimum :: E -> E -> E
pickMaximum :: E -> E -> E
module OrderedPair where
import Order (E,pickMinimum,pickMaximum)
makeOrderedPair :: E -> E -> (# E, E #)
makeOrderedPair a b =
let greater = pickMaximum a b
lesser = pickMinimum a b
in (# greater, lesser #)
Building this with `ghc --backpack buggy.bkp` results in:
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.6.4:
isUnliftedType
E :: TYPE R
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:189:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Core/Type.hs:2257:7 in ghc:GHC.Core.Type
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:454:29 in ghc:GHC.Utils.Error
Notice that we do not have to instantiate the indefinite unit to trigger the bug. Merely defining it is enough. The problematic lines (not indicated by the error message) are the binding sites of `greater` and `lesser`. If we bind using `case` instead of `let`, GHC is able to compile the program. My observation in larger projects that instantiate functions like this is that everything else downstream works once we trick GHC into correctly compiling the function. Here is the workaround using `case` instead of `let`:
makeOrderedPair :: E -> E -> (# E, E #)
makeOrderedPair a b = case pickMaximum a b of
greater -> case pickMinimum a b of
lesser -> (# greater, lesser #)
## Context Around Why This Might Be Happening
I'm not sure why this is happening, and I am not able to dig into it. Here's what I've considered. In GHC, `isUnliftedType` is defined like this:
```
isUnliftedType :: HasDebugCallStack => Type -> Bool
isUnliftedType ty =
case typeLevity_maybe ty of
Just Lifted -> False
Just Unlifted -> True
Nothing -> pprPanic "isUnliftedType" (ppr ty <+> dcolon <+> ppr (typeKind ty))
```
So representation-polymorphic types lead to panics. In an indefinite module, we still want to panic when we encounter a binding whose type's runtime representation includes a locally bound `Rep`. But we do not want to panic when the representation is a top-level abstract representation. I've not been able to investigate this further.
## Environment
* GHC versions that trigger the panic: 9.4, 9.6, 9.8
* GHC versions that do not trigger the panic: 8.10, 9.2sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/24202DataToTag instances in signature files don't work2023-11-21T23:06:40ZMatthew Cravenclyring@gmail.comDataToTag instances in signature files don't work## Summary
Since !8912 landed, signature files are allowed to contain/request instances for the special `DataToTag` class. But these are not actually usable, and fail with a very unhelpful error message.
In principle there is no reason...## Summary
Since !8912 landed, signature files are allowed to contain/request instances for the special `DataToTag` class. But these are not actually usable, and fail with a very unhelpful error message.
In principle there is no reason it shouldn't be possible to support `DataToTag` instances in signatures, but doing so doesn't appear completely trivial and there seems to be little or no demand for this feature.
See also the test case `T15379-DataToTag`.https://gitlab.haskell.org/ghc/ghc/-/issues/10749Boot file instances should imply superclasses2023-11-21T15:48:07ZEdward Z. YangBoot file instances should imply superclassesCurrently, if I write the following program:
```haskell
-- A.hs-boot
module A where
data T
instance Ord T
-- B.hs
module B where
import {-# SOURCE #-} A
f :: T -> T -> Bool
f x y = x == y
```
I get:
```
B.hs:4:11:
No instance fo...Currently, if I write the following program:
```haskell
-- A.hs-boot
module A where
data T
instance Ord T
-- B.hs
module B where
import {-# SOURCE #-} A
f :: T -> T -> Bool
f x y = x == y
```
I get:
```
B.hs:4:11:
No instance for (Eq T) arising from a use of `=='
Possible fix: add an instance declaration for (Eq T)
In the expression: x == y
In an equation for `f': f x y = x == y
```
This is a bit confusing, because Ord instances are supposed to imply Eq instances.
GHC should either:
1. Reject A.hs-boot (claiming that it could not find evidence that T had an Eq instance), or
1. Accept B.hs, since the instance requirement for Ord should imply Eq.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Boot file instances should imply superclasses","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.11","keywords":["backpack"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently, if I write the following program:\r\n\r\n{{{\r\n-- A.hs-boot\r\nmodule A where\r\ndata T\r\ninstance Ord T\r\n\r\n-- B.hs\r\nmodule B where\r\nimport {-# SOURCE #-} A\r\nf :: T -> T -> Bool\r\nf x y = x == y \r\n}}}\r\n\r\nI get:\r\n\r\n{{{\r\nB.hs:4:11:\r\n No instance for (Eq T) arising from a use of `=='\r\n Possible fix: add an instance declaration for (Eq T)\r\n In the expression: x == y\r\n In an equation for `f': f x y = x == y\r\n}}}\r\n\r\nThis is a bit confusing, because Ord instances are supposed to imply Eq instances.\r\n\r\nGHC should either:\r\n\r\n1. Reject A.hs-boot (claiming that it could not find evidence that T had an Eq instance), or\r\n2. Accept B.hs, since the instance requirement for Ord should imply Eq.","type_of_failure":"OtherFailure","blocking":[]} -->Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/20358Allow "instances" for non-typeclass constraints in signature files2023-11-21T15:47:16Zsheafsam.derbyshire@gmail.comAllow "instances" for non-typeclass constraints in signature filesThe [`contiguous`](https://hackage.haskell.org/package/contiguous/docs/Data-Primitive-Contiguous-Class.html) library defines a typeclass for primitive arrays, with an associated constraint:
```haskell
type Contiguous :: ( Type -> Type )...The [`contiguous`](https://hackage.haskell.org/package/contiguous/docs/Data-Primitive-Contiguous-Class.html) library defines a typeclass for primitive arrays, with an associated constraint:
```haskell
type Contiguous :: ( Type -> Type ) -> Constraint
class Contiguous arr where
type Element arr :: Type -> Constraint
-- ... array methods
```
Now, with backpack one might want to declare:
- an array type that is an instance of `Contiguous`,
- a key type which is an allowed element of the array.
Specifically:
```haskell
data Key
data Array k
instance Contiguous Array
instance Element Array Key
```
This currently isn't allowed:
```haskell
* Illegal instance for a associated type family
A class instance must be for a class
* In the instance declaration for `Element Array Key'
|
| instance Element Array Key
| ^^^^^^^^^^^^^^^^^
```
However I think it would make sense to allow this; I don't think there's any other available mechanism to specify that any instantiation of `Key` and `Array` should satisfy the additional constraint `Element Array Key`. Of course it's not strictly an instance (as `Element` is not a typeclass, but a constraint synonym), but the alternative would be to invent backpack-specific syntax.https://gitlab.haskell.org/ghc/ghc/-/issues/18563-Wunused-packages doesn't understand backpack semantics2023-11-08T23:23:31ZGesh-Wunused-packages doesn't understand backpack semantics## Summary
`-Wunused-packages` warns that signatures don't need their dependencies and that indefinite packages don't need their signatures.
## Steps to reproduce
Consider this simple backpack project:
```
==> bug.cabal <==
cabal-vers...## Summary
`-Wunused-packages` warns that signatures don't need their dependencies and that indefinite packages don't need their signatures.
## Steps to reproduce
Consider this simple backpack project:
```
==> bug.cabal <==
cabal-version: 3.0
name: bug
version: 0.1.0.0
common default
ghc-options: -Werror -Wunused-packages
default-language: Haskell2010
default-extensions: NoImplicitPrelude
build-depends: base
library sig
import: default
signatures: Sig
build-depends: semigroups
hs-source-dirs: sig
library lib
import: default
exposed-modules: Lib
hs-source-dirs: lib
build-depends: sig
library imp
import: default
exposed-modules: Imp
build-depends: semigroups
hs-source-dirs: imp
executable app
import: default
main-is: App.hs
hs-source-dirs: app
build-depends:
, imp
, lib
mixins: imp (Imp as Sig)
==> sig/Sig.hsig <==
signature Sig (T, t, f) where
import Data.List.NonEmpty (NonEmpty)
import Prelude (Show)
data T
instance Show T
t :: T
f :: NonEmpty T -> T
==> lib/Lib.hs <==
module Lib (u) where
import Sig (T, f, t)
u :: T
u = f t
==> imp/Imp.hs <==
module Imp (T, t, f) where
import Data.List.NonEmpty (NonEmpty, head)
import Prelude (Show)
data T = L | R deriving (Show)
t :: T
t = L
f :: NonEmpty T -> T
f = head
==> app/App.hs <==
import Lib (u)
import Prelude (print, IO)
main :: IO ()
main = print u
```
Then `cabal build sig` and `imp` complain that
```
<no location info>: error: [-Wunused-packages, -Werror=unused-packages]
The following packages were specified via -package or -package-id flags,
but were not needed for compilation:
- semigroups-0.19.1
```
If we suppress this by passing `-Wno-unused-packages` to the `sig` build,
then `cabal build lib` complains that
```
<no location info>: error: [-Wunused-packages, -Werror=unused-packages]
The following packages were specified via -package or -package-id flags,
but were not needed for compilation:
- bug-0.1.0.0:sig[Sig=<Sig>]
```
Full error logs have been posted at ix.io, for [no suppression](http://ix.io/2tSF), [sig suppression](http://ix.io/2tSJ) and [sig+lib suppression](http://ix.io/2tSS)
## Expected behavior
This shouldn't complain at all. However, judging by #13493, this might be a bit difficult to implement, so at least having this check have a toggle to switch between off/no-backpack/on would help.
## Environment
* GHC version used: 8.10.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24065panic: Given constraint without given origin2023-10-10T14:18:53ZRodrigo Mesquitapanic: Given constraint without given origin## Summary
During compilation of a backpack heavy library I get the following error:
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.6.2:
Given constraint without given origin
$dApplicative_aafq
...## Summary
During compilation of a backpack heavy library I get the following error:
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.6.2:
Given constraint without given origin
$dApplicative_aafq
arising when attempting to show that
instance [safe] Applicative m => Applicative (CommandM m)
-- Defined in ‘Ghengin.Vulkan.Renderer.Command’
is provided by ‘Ghengin.Vulkan.Renderer.Command’
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:189:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Tc/Solver/Canonical.hs:600:31 in ghc:GHC.Tc.Solver.Canonical
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:454:29 in ghc:GHC.Utils.Error
```
Unfortunately, my reproducer is *far* from minimal.
It's reproducible by cloning at a particular commit a considerably large project...
Nonetheless, I figured I should report it.
## Steps to reproduce
```
git clone https://github.com/alt-romes/ghengin.git && cd ghengin
git checkout 2e007f0c9bf88018db424d11c96b2de9b0b4d14a
cabal build ghengin-core
```
## Environment
* GHC version used: 9.6.2
Optional:
* Operating System: macOS
* System Architecture: M2 / Aarch64https://gitlab.haskell.org/ghc/ghc/-/issues/10660.dyn_o isn't generated for .hsig files with -dynamic-too2023-08-17T11:28:19Zspinda.dyn_o isn't generated for .hsig files with -dynamic-tooThis causes the linker to error out later on, as it expects a .dyn_o file to exist for each .hsig file.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Ver...This causes the linker to error out later on, as it expects a .dyn_o file to exist for each .hsig file.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":".dyn_o isn't generated for .hsig files with -dynamic-too","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This causes the linker to error out later on, as it expects a .dyn_o file to exist for each .hsig file.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.3spindaspindahttps://gitlab.haskell.org/ghc/ghc/-/issues/17190Backpack signatures fail to compile when referencing class associated types w...2023-08-08T10:32:35ZEdward KmettBackpack signatures fail to compile when referencing class associated types with defaults## Summary
Backpack signatures fail to compile when they reference class associated types with default definitions.
## Steps to reproduce
Build a library that contains a class associated type along with a default definition and requir...## Summary
Backpack signatures fail to compile when they reference class associated types with default definitions.
## Steps to reproduce
Build a library that contains a class associated type along with a default definition and require an instance of that class in a backpack signature.
Example:
`backpack-test.cabal`:
```
cabal-version: 2.4
name: backpack-test
version: 0
library common
build-depends: base
default-language: Haskell2010
exposed-modules: Class
hs-source-dirs: common
library consumer
build-depends: base, common
default-language: Haskell2010
signatures: Instance
hs-source-dirs: consumer
```
`common/Class.hs`:
```haskell
{-# language TypeFamilies #-}
module Class where
class C x where
type T x
type T x = ()
```
`consumer/Instance.hsig`:
```haskell
signature Instance where
import Class
data I
instance C I
```
Error given:
```
<no location info>: error:
The identifier R:TI does not exist in the local signature.
(Try adding it to the export list of the hsig file.)
```
Note: Removing the default `type T x = ()` results in this code compiling.
## Expected behavior
I'd expect this to work.
## Environment
* GHC version used: 8.8
Optional:
* Operating System: All
* System Architecture: AllJohn EricsonJohn Ericsonhttps://gitlab.haskell.org/ghc/ghc/-/issues/23648bkpcabal08 now has non-deterministic output2023-08-04T16:26:25ZBen Gamaribkpcabal08 now has non-deterministic outputSince updating the `Cabal` submodule in 1228d3a4a08d30eaf0138a52d1be25b38339ef0b, the `bkpcabal08` test now has non-deterministic output. Specifically, we see spurious changes of the shape:
```patch
--- /var/folders/4t/wfp01mj9693c09ymg0...Since updating the `Cabal` submodule in 1228d3a4a08d30eaf0138a52d1be25b38339ef0b, the `bkpcabal08` test now has non-deterministic output. Specifically, we see spurious changes of the shape:
```patch
--- /var/folders/4t/wfp01mj9693c09ymg070wvs40000hm/T/ghctest-yx1dtmlg/test spaces/testsuite/tests/backpack/cabal/bkpcabal08/bkpcabal08.run/bkpcabal08.stdout.normalised 2023-07-13 02:55:25.000000000 -0400
+++ /var/folders/4t/wfp01mj9693c09ymg070wvs40000hm/T/ghctest-yx1dtmlg/test spaces/testsuite/tests/backpack/cabal/bkpcabal08/bkpcabal08.run/bkpcabal08.run.stdout.normalised 2023-07-13 02:55:25.000000000 -0400
@@ -1,11 +1,11 @@
-Preprocessing library 'impl' for bkpcabal08-<VERSION>-<HASH>
-Building library 'impl' for bkpcabal08-<VERSION>-<HASH>
Preprocessing library 'p' for bkpcabal08-<VERSION>-<HASH>
Building library 'p' instantiated with
A = <A>
B = <B>
for bkpcabal08-<VERSION>-<HASH>
[2 of 2] Compiling B[sig] ( p/B.hsig, nothing )
+Preprocessing library 'impl' for bkpcabal08-<VERSION>-<HASH>
+Building library 'impl' for bkpcabal08-<VERSION>-<HASH>
Preprocessing library 'q' for bkpcabal08-<VERSION>-<HASH>
Building library 'q' instantiated with
A = <A>
@@ -19,7 +19,7 @@
A = bkpcabal08-<VERSION>-<HASH>:A
B = bkpcabal08-<VERSION>-<HASH>:B
for bkpcabal08-<VERSION>-<HASH>
-[1 of 3] Compiling A[sig] ( q/A.hsig, dist/build/bkpcabal08-<VERSION>-<HASH>+5IA1jA4bEzCFcXtraqAC38/A.o ) [Prelude package changed]
-[2 of 3] Compiling B[sig] ( q/B.hsig, dist/build/bkpcabal08-<VERSION>-<HASH>+5IA1jA4bEzCFcXtraqAC38/B.o ) [Prelude package changed]
+[1 of 3] Compiling A[sig] ( q/A.hsig, dist/build/bkpcabal08-<VERSION>-<HASH>+J0rW2GVAn1n7KqPCQDq1Pq/A.o ) [Prelude package changed]
+[2 of 3] Compiling B[sig] ( q/B.hsig, dist/build/bkpcabal08-<VERSION>-<HASH>+J0rW2GVAn1n7KqPCQDq1Pq/B.o ) [Prelude package changed]
Preprocessing library 'r' for bkpcabal08-<VERSION>-<HASH>
Building library 'r' for bkpcabal08-<VERSION>-<HASH>
```https://gitlab.haskell.org/ghc/ghc/-/issues/23315Documentation declarations not attached to signature module ASTs2023-07-21T12:02:33ZFinley McIlwaineDocumentation declarations not attached to signature module ASTs## Summary
The parser for signature modules does not include docs in the resulting AST as the parser for regular modules does.
## Steps to reproduce
A fairly minimal reproducer follows.
`sig-parse.cabal`:
```
cabal-version: 3.8
name:...## Summary
The parser for signature modules does not include docs in the resulting AST as the parser for regular modules does.
## Steps to reproduce
A fairly minimal reproducer follows.
`sig-parse.cabal`:
```
cabal-version: 3.8
name: sig-parse
version: 0.1.0
library
build-depends: base
signatures: A
exposed-modules: B
```
`A.hsig`:
```
signature A where
-- | Just '()'
a :: ()
-- ^ More docs
```
`B.hs`:
```
module B where
-- | Just '()'
b :: ()
-- ^ More docs
```
Although this will fail to build due to the lack of an accompanying binding for `b`, it will still parse. I've made the modules as similar as possible for the sake of comparison between their ASTs.
Running `cabal build --ghc-options=-haddock -ddump-to-file -ddump-parsed-ast` yields the following dumps.
`A.dump-parsed-ast`:
```
==================== Parser AST ====================
2023-04-28 01:56:46.534016 UTC
(L
{ A.hsig:1:1 }
(HsModule
(XModulePs
(EpAnn
(Anchor
{ A.hsig:1:1 }
(UnchangedAnchor))
(AnnsModule
[(AddEpAnn AnnSignature (EpaSpan { A.hsig:1:1-9 }))
,(AddEpAnn AnnWhere (EpaSpan { A.hsig:1:13-17 }))]
(AnnList
(Nothing)
(Nothing)
(Nothing)
[]
[]))
(EpaComments
[]))
(VirtualBraces
(1))
(Nothing)
(Nothing))
(Just
(L
(SrcSpanAnn (EpAnnNotUsed) { A.hsig:1:11 })
{ModuleName: A}))
(Nothing)
[]
[(L
(SrcSpanAnn (EpAnn
(Anchor
{ A.hsig:4:1-7 }
(UnchangedAnchor))
(AnnListItem
[])
(EpaComments
[])) { A.hsig:4:1-7 })
(SigD
(NoExtField)
(TypeSig
(EpAnn
(Anchor
{ A.hsig:4:1 }
(UnchangedAnchor))
(AnnSig
(AddEpAnn AnnDcolon (EpaSpan { A.hsig:4:3-4 }))
[])
(EpaComments
[]))
[(L
(SrcSpanAnn (EpAnnNotUsed) { A.hsig:4:1 })
(Unqual
{OccName: a}))]
(HsWC
(NoExtField)
(L
(SrcSpanAnn (EpAnnNotUsed) { A.hsig:4:6-7 })
(HsSig
(NoExtField)
(HsOuterImplicit
(NoExtField))
(L
(SrcSpanAnn (EpAnnNotUsed) { A.hsig:4:6-7 })
(HsTupleTy
(EpAnn
(Anchor
{ A.hsig:4:6 }
(UnchangedAnchor))
(AnnParen
(AnnParens)
(EpaSpan { A.hsig:4:6 })
(EpaSpan { A.hsig:4:7 }))
(EpaComments
[]))
(HsBoxedOrConstraintTuple)
[]))))))))]))
```
`B.dump-parsed-ast`:
```
==================== Parser AST ====================
2023-04-28 01:56:46.556019 UTC
(L
{ B.hs:1:1 }
(HsModule
(XModulePs
(EpAnn
(Anchor
{ B.hs:1:1 }
(UnchangedAnchor))
(AnnsModule
[(AddEpAnn AnnModule (EpaSpan { B.hs:1:1-6 }))
,(AddEpAnn AnnWhere (EpaSpan { B.hs:1:10-14 }))]
(AnnList
(Nothing)
(Nothing)
(Nothing)
[]
[]))
(EpaCommentsBalanced
[]
[(L
(Anchor
{ B.hs:6:1 }
(UnchangedAnchor))
(EpaComment
(EpaEofComment)
{ B.hs:6:1 }))]))
(VirtualBraces
(1))
(Nothing)
(Nothing))
(Just
(L
(SrcSpanAnn (EpAnnNotUsed) { B.hs:1:8 })
{ModuleName: B}))
(Nothing)
[]
[(L
(SrcSpanAnn (EpAnnNotUsed) { B.hs:3:1-14 })
(DocD
(NoExtField)
(DocCommentNext
(L
{ B.hs:3:1-14 }
(WithHsDocIdentifiers
(MultiLineDocString
(HsDocStringNext)
(:|
(L
{ B.hs:3:5-14 }
(HsDocStringChunk
" Just '()'"))
[]))
[])))))
,(L
(SrcSpanAnn (EpAnn
(Anchor
{ B.hs:4:1-7 }
(UnchangedAnchor))
(AnnListItem
[])
(EpaComments
[])) { B.hs:4:1-7 })
(SigD
(NoExtField)
(TypeSig
(EpAnn
(Anchor
{ B.hs:4:1 }
(UnchangedAnchor))
(AnnSig
(AddEpAnn AnnDcolon (EpaSpan { B.hs:4:3-4 }))
[])
(EpaComments
[]))
[(L
(SrcSpanAnn (EpAnnNotUsed) { B.hs:4:1 })
(Unqual
{OccName: b}))]
(HsWC
(NoExtField)
(L
(SrcSpanAnn (EpAnnNotUsed) { B.hs:4:6-7 })
(HsSig
(NoExtField)
(HsOuterImplicit
(NoExtField))
(L
(SrcSpanAnn (EpAnnNotUsed) { B.hs:4:6-7 })
(HsTupleTy
(EpAnn
(Anchor
{ B.hs:4:6 }
(UnchangedAnchor))
(AnnParen
(AnnParens)
(EpaSpan { B.hs:4:6 })
(EpaSpan { B.hs:4:7 }))
(EpaComments
[]))
(HsBoxedOrConstraintTuple)
[]))))))))
,(L
(SrcSpanAnn (EpAnnNotUsed) { B.hs:5:1-14 })
(DocD
(NoExtField)
(DocCommentPrev
(L
{ B.hs:5:1-14 }
(WithHsDocIdentifiers
(MultiLineDocString
(HsDocStringPrevious)
(:|
(L
{ B.hs:5:5-14 }
(HsDocStringChunk
" More docs"))
[]))
[])))))]))
```
Notice that the signature module AST (`A.hsig`) lacks any `DocD` declarations in its AST.
## Expected behavior
I would expect signature module ASTs to be populated with `DocD` declarations, as regular modules are.
## Environment
* GHC version used: 9.6.1 (reproduced on HEAD as well)
* Cabal version used: 3.6.2.0Finley McIlwaineFinley McIlwainehttps://gitlab.haskell.org/ghc/ghc/-/issues/23322Backpack: Import standalone modules from indefinite packages in instancing mo...2023-07-02T23:06:56ZRodrigo MesquitaBackpack: Import standalone modules from indefinite packages in instancing modules failsSay I have the following modules and signatures in a cabal project
```haskell
module A where
data SomeUsefulThing = SomeUsefulThing
```
```haskell
signature B where
import A
someUsefulFun :: SomeUsefulThing -> ()
```
```haskell
module...Say I have the following modules and signatures in a cabal project
```haskell
module A where
data SomeUsefulThing = SomeUsefulThing
```
```haskell
signature B where
import A
someUsefulFun :: SomeUsefulThing -> ()
```
```haskell
module B.Instance where
import A
someUsefulFun :: SomeUsefulThing -> ()
someUsefulFun SomeUsefulThing = ()
```
Note that in B's signature and instance, `someUsefulFun` share the same type `SomeUsefulThing` imported from `A`.
```haskell
import A
import B
main = pure (someUsefulFun SomeUsefulThing)
```
```cabal
cabal-version: 3.4
name: ex2
version: 0.1.0.0
build-type: Simple
library pa
build-depends: base
exposed-modules: A
signatures: B
hs-source-dirs: pa
library pb
build-depends: base, ex2:pa
exposed-modules: B.Instance
hs-source-dirs: pb
library
exposed-modules: Main
build-depends: base, ex2:pa, ex2:pb
mixins: ex2:pa requires (B as B.Instance),
hs-source-dirs: main
```
When compiling this project, it fails with
```
<no location info>: error:
• Identifier ‘someUsefulFun’ has conflicting definitions in the module
and its hsig file
Main module: someUsefulFun ::
ex2-0.1.0.0:pa[B=<B>]:A.SomeUsefulThing -> ()
Hsig file: someUsefulFun :: A.SomeUsefulThing -> ()
The two types are different
• while checking that B.Instance implements signature B in ex2-0.1.0.0:pa[B=B.Instance]
```
The cause is `SomeUsefulThing`, in the context of `pa` is imported from `A`, but in the context of `pb`, is imported from `ex2:pa[B=<B>]:A`.
I think it should be possible to use the shared definition of `SomeUsefulThing`, since `A` is a completely standalone module (doesn't depend on any indefinite signatures). Even if it did, it is reasonable to think it should also work.
Is this a fundamental limitation or something we can overcome?
Many thanks.sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23443Backpack silently substitutes missing signatures with empty ones instead of t...2023-05-30T15:09:36ZBartłomiej CieślarBackpack silently substitutes missing signatures with empty ones instead of throwing an error## Motivation
It's easy to mistakenly name signature files with .sig instead of .hsig. In such a situation, instead of throwing an error, backpack will assume a file with no definitions and proceed to throw an error during renaming inst...## Motivation
It's easy to mistakenly name signature files with .sig instead of .hsig. In such a situation, instead of throwing an error, backpack will assume a file with no definitions and proceed to throw an error during renaming instead of on the cabal-level. With how buggy that part of the codebase can sometimes be, it makes it often difficult to figure out whether the error stems from backpack or the code compiled with it.
## Proposal
Throw an error when a signature file is not found instead of silently assuming an empty signaturehttps://gitlab.haskell.org/ghc/ghc/-/issues/23437Backpack shadowing of same-named signatures necessitates different home units...2023-05-23T15:08:40ZBartłomiej CieślarBackpack shadowing of same-named signatures necessitates different home units for signatures in different home units in bkp files## Motivation
Because backpack currently does not differentiate between modules with the same name in the same bkp file, trying to add features that load interface files during the processing of backpack (e.g. [!10283](https://gitlab.ha...## Motivation
Because backpack currently does not differentiate between modules with the same name in the same bkp file, trying to add features that load interface files during the processing of backpack (e.g. [!10283](https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10283)) introduces aliasing issues in some cases.
For example, in test `bkp44` trying to load signature `p:B` when `q:A` has been merged, it causes the type checking of `p:B` to try to import `q:A` instead of `p:A`, which in turn causes an error where `A.T` was not found in `A` (because `q:A` restricts the imports of `p:A`)
## Proposal
Like with GHCi, make bkp signatures from different units be cached in different home units, which will remove the aliasing issue. In that case, also remove the workaround for export deprecations in signature merging where the ImpSpec module is set to a hole module instead of the actual source signaturehttps://gitlab.haskell.org/ghc/ghc/-/issues/23344Backpack accepts invalid impredicativity in implementation of abstract data2023-05-15T22:33:56Zsheafsam.derbyshire@gmail.comBackpack accepts invalid impredicativity in implementation of abstract dataWhen checking that `type T = rhs` is a valid implementation of an abstract data declaration `data T`, backpack fails to check whether `rhs` contains any nested foralls, which means it accepts e.g.
```haskell
{-# LANGUAGE StandaloneKindS...When checking that `type T = rhs` is a valid implementation of an abstract data declaration `data T`, backpack fails to check whether `rhs` contains any nested foralls, which means it accepts e.g.
```haskell
{-# LANGUAGE StandaloneKindSignatures #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE ImpredicativeTypes #-}
unit p where
module M where
import Data.Kind
type C :: Type -> Constraint
class C a where
type family F a :: Type
unit q where
dependency p
signature H where
data T
module N where
import M ( C(F) )
import H ( T )
instance C T where
type F T = T
unit r where
dependency p
module H where
import Data.Kind
type S :: Type -> Type
data S a = MkS
type T = S (forall (a :: Type). a -> a)
unit s where
dependency p
dependency r
dependency q[H=r:H]
```
There should be a check that mirrors the check that there are no type family applications in the RHS.sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23342Backpack: poor error message implementing abstract data with a forall type2023-05-15T22:33:56Zsheafsam.derbyshire@gmail.comBackpack: poor error message implementing abstract data with a forall typeBackpack currently accepts an abstract data type to be implemented as a forall or quantified type:
```haskell
unit p where
signature H where
data T1
data T2
data T3
unit q where
module H where
class C a where {}
...Backpack currently accepts an abstract data type to be implemented as a forall or quantified type:
```haskell
unit p where
signature H where
data T1
data T2
data T3
unit q where
module H where
class C a where {}
data S
type T1 = forall a. a -> a
type T2 = forall a. C a => a
type T3 = C S => S -> S
unit r where
dependency q
dependency p[H=q:H]
```
We get errors like the following:
```
* Type constructor `T3' has conflicting definitions in the module
and its hsig file
Main module: type T3 :: *
type T3 = C S => S -> S
Hsig file: type T3 :: *
data T3
```
It doesn't specify what the issue is (that a quantified type is not allowed in the RHS of the type synonym implementing the abstract datatype).sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23350Backpack panic: Duplicate nodes keys in backpack file2023-05-05T13:01:10Zsheafsam.derbyshire@gmail.comBackpack panic: Duplicate nodes keys in backpack fileConsider this `.bkp` file:
```haskell
unit p where
signature H where
unit q where
module H where
unit r where
dependency p
dependency q[H=p:H]
```
There's a mistake: we mixed up `p` and `q` in the unit `r`.
This causes the f...Consider this `.bkp` file:
```haskell
unit p where
signature H where
unit q where
module H where
unit r where
dependency p
dependency q[H=p:H]
```
There's a mistake: we mixed up `p` and `q` in the unit `r`.
This causes the following panic:
```
ghc: panic! (the 'impossible' happened)
GHC version 9.7.20230504:
Duplicate nodes keys in backpack file
[q+q-9dU7VXZcSfk3MwGleJHyst:H, q+q-9dU7VXZcSfk3MwGleJHyst:H]
```
I am inclined to believe this is a bkpism (affects only the `.bkp` format and not `cabal` projects that use Backpack), but I haven't checked.https://gitlab.haskell.org/ghc/ghc/-/issues/20489Backpack error message prints out data from interface file instead of source ...2023-05-05T13:00:27Zsheafsam.derbyshire@gmail.comBackpack error message prints out data from interface file instead of source file```haskell
unit sig where
signature Sig where
data A
instance Show A
unit impl where
module Impl where
type A = Int -> Int
unit main where
dependency sig[Sig=impl:Impl]
module Main where
import Impl
main = p...```haskell
unit sig where
signature Sig where
data A
instance Show A
unit impl where
module Impl where
type A = Int -> Int
unit main where
dependency sig[Sig=impl:Impl]
module Main where
import Impl
main = print "no"
```
```
ghc --backpack Error3.bkp
[1 of 3] Processing sig
[1 of 1] Compiling Sig[sig] ( sig\Sig.hsig, nothing ) [Flags changed]
[2 of 3] Processing impl
Instantiating impl
[1 of 1] Compiling Impl ( impl\Impl.hs, impl\Impl.o ) [Flags changed]
[3 of 3] Processing main
Instantiating main
[1 of 1] Including sig[Sig=impl:Impl]
Instantiating sig[Sig=impl:Impl]
[1 of 1] Compiling Sig[sig] ( sig\Sig.hsig, sig\sig-Absk5cIXTXe6UYhGMYGber\Sig.o )
sig\sig-Absk5cIXTXe6UYhGMYGber\..\Sig.hi:1:1: error:
* No instance for (GHC.Show.Show A)
arising when attempting to show that
instance [safe] GHC.Show.Show A -- Defined at Error3.bkp:4:14
is provided by `impl:Impl'
(maybe you haven't applied a function to enough arguments?)
* while checking that impl:Impl implements signature Sig in sig[Sig=impl:Impl]
|
1 | ☺??d♂90320210928?????☻???☺???☺?☺?☺☺☻☺☺☺☻☺☻??????☺????X?☺?Ã?????☺?????<???????☺???◄►???????????????☺?v????☺????????☺???
?????☺???????B???????☺☻???☻?☻♥?☻♦
| ^
```
It seems the problem is that we decide to report information contained in the interface file `Sig.hi`, which doesn't make any sense.https://gitlab.haskell.org/ghc/ghc/-/issues/20488Incorrect module name in .bkp instantiation causes a "Failed to load interfac...2023-05-05T13:00:21Zsheafsam.derbyshire@gmail.comIncorrect module name in .bkp instantiation causes a "Failed to load interface" errorWhen attempting to compile the following .bkp file:
```haskell
unit basic where
signature Basic where
unit mod where
module Mod where
unit main where
dependency basic
[ Basic = mod:Nonsense ]
```
GHC produces the error:
``...When attempting to compile the following .bkp file:
```haskell
unit basic where
signature Basic where
unit mod where
module Mod where
unit main where
dependency basic
[ Basic = mod:Nonsense ]
```
GHC produces the error:
```
ghc --backpack Error2.bkp
[1 of 3] Processing basic
[2 of 3] Processing mod
Instantiating mod
[1 of 1] Compiling Mod ( mod\Mod.hs, mod\Mod.o )
[3 of 3] Processing main
Instantiating main
[1 of 1] Including basic[Basic=mod:Nonsense]
Instantiating basic[Basic=mod:Nonsense]
[1 of 1] Compiling Basic[sig] ( basic\Basic.hsig, basic\basic-ER8okxhuIcsFJ32OYv1Qcp\Basic.o )
<no location info>: error:
Failed to load interface for `Nonsense'
There are files missing in the `mod' package,
try running 'ghc-pkg check'.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
```
It would be better to catch this problem earlier on, and report a proper error message.https://gitlab.haskell.org/ghc/ghc/-/issues/17522Document .bkp files2023-05-05T12:59:39ZRichard Eisenbergrae@richarde.devDocument .bkp filesBackpack testing uses `.bkp` files, which are slurped in when GHC is passed the `-backpack` flag. From some conversations I've had, this flag is meant only for internal use, in our testsuite.
Yet this aspect of GHC seems entirely undocu...Backpack testing uses `.bkp` files, which are slurped in when GHC is passed the `-backpack` flag. From some conversations I've had, this flag is meant only for internal use, in our testsuite.
Yet this aspect of GHC seems entirely undocumented. `.bkp` files have a concrete syntax implemented in the parser, a potentially user-accessible flag, and quite a bit of code to support it all... but with no description that I have seen. (Maybe I've just looked in the wrong place.)
This ticket is therefore to track the documentation of this feature. Generally, I would expect at least a passing mention in the manual ("GHC has this `-backpack` flag, meant for internal use only; not a user-facing feature") and a long Note describing how the files are used in practice in the testsuite and how they are implemented.
(This was born from a discussion in !1767, but no need to look there to understand this ticket.)