GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-01T16:51:46Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24465Man page missing from bindists2024-03-01T16:51:46ZBryan Rbryan@haskell.foundationMan page missing from bindistsAs noted at https://github.com/haskell/ghcup-hs/issues/990#issuecomment-1957326918
I can confirm there is a man page in ghc-9.8.1-x86_64-fedora33-linux.tar.lz, but **not** in ghc-9.8.1-x86_64-rocky8-linux.tar.lz.As noted at https://github.com/haskell/ghcup-hs/issues/990#issuecomment-1957326918
I can confirm there is a man page in ghc-9.8.1-x86_64-fedora33-linux.tar.lz, but **not** in ghc-9.8.1-x86_64-rocky8-linux.tar.lz.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24464Core lint error when compiling distributed-closure-0.5.0.0 with 9.8.12024-02-27T15:21:12ZZubinCore lint error when compiling distributed-closure-0.5.0.0 with 9.8.1```bash
$ cabal get distributed-closure-0.5.0.0
$ cd distributed-closure-0.5.0.0
$ cat > cabal.project << EOF
packages: .
package distributed-closure
ghc-options: -dlint
EOF
$ cabal build -w ghc-9.8.1
```
```
[ 5 of 10] Compiling Cont...```bash
$ cabal get distributed-closure-0.5.0.0
$ cd distributed-closure-0.5.0.0
$ cat > cabal.project << EOF
packages: .
package distributed-closure
ghc-options: -dlint
EOF
$ cabal build -w ghc-9.8.1
```
```
[ 5 of 10] Compiling Control.Comonad.Static ( src/Control/Comonad/Static.hs, dist/build/Control/Comonad/Static.o, dist/build/Control/Comonad/Static.dyn_o )
*** Core Lint errors : in result of Float out(FOS {Lam = Just 0,
Consts = True,
OverSatApps = False}) ***
src/Control/Comonad/Static.hs:18:22: warning:
Found makeStatic nested in an expression
In the RHS of $dmstaticDuplicate :: forall (w :: * -> *) a.
(StaticExtend w, Typeable a) =>
w a -> w (w a)
In the unfolding of $dmstaticDuplicate :: forall (w :: * -> *) a.
(StaticExtend w, Typeable a) =>
w a -> w (w a)
In the body of lambda with binder w_adSi :: * -> *
In the body of lambda with binder $dStaticExtend_adUy :: StaticExtend
w_adSi
In the body of lambda with binder a_adUB :: *
In the body of lambda with binder eta_B0 :: Typeable a_adUB
In an occurrence of makeStatic :: forall a.
(Int, Int) -> a -> StaticPtr a
Substitution: <InScope = {w_adSi a_adUB}
IdSubst = []
TvSubst = [adSi :-> w_adSi, adUB :-> a_adUB]
CvSubst = []>
```9.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/24463Core lint error when compiling grisette-0.4.1.0 with 9.8.12024-02-29T14:41:57ZZubinCore lint error when compiling grisette-0.4.1.0 with 9.8.1```bash
$ cabal get grisette-0.4.1.0
$ cd grisette-0.4.1.1
$ cat > cabal.project << EOF
packages: .
package grisette
ghc-options: -dlint
EOF
$ cabal build -w ghc-9.8.1
```
```
*** Core Lint errors : in result of CorePrep ***
src/Grise...```bash
$ cabal get grisette-0.4.1.0
$ cd grisette-0.4.1.1
$ cat > cabal.project << EOF
packages: .
package grisette
ghc-options: -dlint
EOF
$ cabal build -w ghc-9.8.1
```
```
*** Core Lint errors : in result of CorePrep ***
src/Grisette/IR/SymPrim/Data/Prim/Model.hs:407:1: warning:
The coercion variable co2_adsr
:: (f4_X5 :~~: (-->)) ~# (Any :~~: Any)
[LclId[CoVarId]]
is out of scope
In the RHS of evaluateSomeTerm :: Bool
-> Model -> SomeTerm -> SomeTerm
In the body of lambda with binder fillDefault_s2X07 :: Bool
In the body of lambda with binder m_s2X08 :: Model
In the body of lambda with binder eta_s2X09 :: SomeTerm
In the RHS of gomemo_s2X0a :: SomeTerm -> SomeTerm
In the body of lambda with binder c_s2X0b :: SomeTerm
In a case alternative: (SomeTerm a_a2QcX :: *,
$dSupportedPrim_s2X0d :: SupportedPrim a_a2QcX,
ds_s2X0e :: Term a_a2QcX)
In a case alternative: (ConTerm $dSupportedPrim1_s2X0g :: SupportedPrim
a_a2QcX,
bx_s2X0h :: Int#,
cv_s2X0i :: a_a2QcX)
In a case alternative: (IsApp k'_a2nRD :: *,
f1_a2nRE :: k'_a2nRD -> *,
x_a2nRF :: k'_a2nRD,
co_a2nRG :: a_a2QcX ~# f1_a2nRE x_a2nRF,
f2_s2X0l :: TypeRep f1_a2nRE,
x1_s2X0m :: TypeRep x_a2nRF)
In a case alternative: (IsApp k'1_X4 :: *,
f4_X5 :: k'1_X4 -> k'_a2nRD -> *,
x2_X6 :: k'1_X4,
co1_X7 :: f1_a2nRE ~# f4_X5 x2_X6,
f5_s2X0o :: TypeRep f4_X5,
x3_s2X0p :: TypeRep x2_X6)
In a case alternative: (True)
In a case alternative: (GeneralFun $dSupportedPrim2_s2X0s :: SupportedPrim
(x2_X6 |> SelCo:Fun(arg)
(Sym (Sym (SelCo:Tc(1)
(Sub (Sym Univ(nominal CorePrep
:: f4_X5
:~~: (-->), Any
:~~: Any))))
; SelCo:Tc(0)
(Sub (Sym Univ(nominal CorePrep
:: f4_X5
:~~: (-->), Any
:~~: Any)))))),
$dSupportedPrim3_s2X0t :: SupportedPrim
(x_a2nRF |> SelCo:Fun(arg)
(SelCo:Fun(res)
(Sym (Sym (SelCo:Tc(1)
(Sub (Sym Univ(nominal CorePrep
:: f4_X5
:~~: (-->), Any
:~~: Any))))
; SelCo:Tc(0)
(Sub (Sym Univ(nominal CorePrep
:: f4_X5
:~~: (-->), Any
:~~: Any))))))),
ds1_s2X0u :: TypedSymbol
(x2_X6 |> SelCo:Fun(arg)
(Sym (Sym (SelCo:Tc(1)
(Sub (Sym Univ(nominal CorePrep
:: f4_X5
:~~: (-->), Any
:~~: Any))))
; SelCo:Tc(0)
(Sub (Sym Univ(nominal CorePrep
:: f4_X5
:~~: (-->), Any
:~~: Any)))))),
ds2_s2X0v :: Term
(x_a2nRF |> SelCo:Fun(arg)
(SelCo:Fun(res)
(Sym (Sym (SelCo:Tc(1)
(Sub (Sym Univ(nominal CorePrep
:: f4_X5
:~~: (-->), Any
:~~: Any))))
; SelCo:Tc(0)
(Sub (Sym Univ(nominal CorePrep
:: f4_X5
:~~: (-->), Any
:~~: Any))))))))
In a case alternative: (False)
In the body of letrec with binders sat_s2X0x :: SomeTerm
In the result-type of a case with scrutinee: gomemo_s2X0a sat_s2X0x
In the type ‘Term
(x_a2nRF |> SelCo:Fun(arg)
(SelCo:Fun(res)
(Sym (Sym (SelCo:Tc(1) (Sub (Sym co2_adsr)))
; SelCo:Tc(0) (Sub (Sym co2_adsr))))))’
Substitution: <InScope = {k'1_X4 f4_X5 x2_X6 co1_X7 k'_a2nRD
f1_a2nRE x_a2nRF co_a2nRG a_a2QcX}
IdSubst = []
TvSubst = [X4 :-> k'1_X4, X5 :-> f4_X5, X6 :-> x2_X6,
a2nRD :-> k'_a2nRD, a2nRE :-> f1_a2nRE, a2nRF :-> x_a2nRF,
a2QcX :-> a_a2QcX]
CvSubst = [X7 :-> co1_X7, a2nRG :-> co_a2nRG]>
```https://gitlab.haskell.org/ghc/ghc/-/issues/24462Exponentially increasing compilation w/ Higher-Kinded Data under 9.8.12024-03-27T17:08:50Zm4dc4pExponentially increasing compilation w/ Higher-Kinded Data under 9.8.1## Summary
GHC 9.8.1 takes increasingly longer (and uses radically more memory) to compile a module as fields are added to a data type; the same did not occur with GHC 9.6.
## Steps to reproduce
The repo at https://github.com/m4dc4p/g...## Summary
GHC 9.8.1 takes increasingly longer (and uses radically more memory) to compile a module as fields are added to a data type; the same did not occur with GHC 9.6.
## Steps to reproduce
The repo at https://github.com/m4dc4p/ghc98-bug can demonstrate the issue. You can just run `cabal build` to try it.
The file `AAAX.hs` contains the `HKDType` data type. As you uncomment fields, the compilation times (`cabal build`) take longer and longer.
For example, on my M2, with GHC 9.8, I get these timings & peak memory usage:
* 1 field - 2.5s, 198MB peak
* 2 fields - 7s, 1.0GB peak
* 3 fields - 26.8s, 4.6GB peak
* 4 fields - 82.9s, 14.5GB peak
Note that with -O0, there is no problem - compilation time does not increase. Also, removing the standalone `Eq` instance also causes the problem to go away (but, of course, I want that instance).
Under GHC 9.6, with -O1, compilation times do not increase either (even up to 10 fields on the data type).
I found this on MacOS 14.2.1, using an M2 chip.
(Note I also reported this as a bug against the Barbies library - https://github.com/jcpetruzza/barbies/issues/51)9.8.3Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/24461Don't warn about an inaccessible `undefined`2024-02-22T11:21:39ZAndreas AbelDon't warn about an inaccessible `undefined`This is the "Hello world!" of dependent types (safe indexing) in GHC:
```haskell
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
data Nat where
Zero :: Nat
Suc :: Nat -> Nat
data Vec a n where
Nil :: Vec a Zero
Cons :: a -> ...This is the "Hello world!" of dependent types (safe indexing) in GHC:
```haskell
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
data Nat where
Zero :: Nat
Suc :: Nat -> Nat
data Vec a n where
Nil :: Vec a Zero
Cons :: a -> Vec a n -> Vec a (Suc n)
data Fin n where
FZero :: Fin (Suc n)
FSuc :: Fin n -> Fin (Suc n)
look :: Vec a n -> Fin n -> a
look (Cons x xs) FZero = x
look (Cons x xs) (FSuc i) = look xs i
look !_ !_ = undefined
```
The last clause indicates that the pattern matching is complete. Without it, I get an `incomplete-patterns` warning.
However, with it, I get:
```
warning: [-Woverlapping-patterns]
Pattern match has inaccessible right hand side
In an equation for ‘look’: look !_ !_ = ...
|
25 | look !_ !_ = undefined
| ^^^^^^^^^^^^^^^^^^^^^^
```
It would be nice if exception raisers like `undefined` or `error` as rhs would silence this warning.
I mean, the user indicates with a `undefined` rhs their awareness that this case is impossible.
The alternative would be a special syntax that allows to omit the rhs altogether in contradictory cases. (That's what Agda's absurd clauses do.) However, detecting `undefined` might be less invasive to the language.https://gitlab.haskell.org/ghc/ghc/-/issues/24460Strange typechecking errors to do with Generics in a module with ANN and a ty...2024-02-27T15:12:18ZTeo CamarasuStrange typechecking errors to do with Generics in a module with ANN and a type error## Summary
This is a reproducer extracted from something we encountered in the wild.
Adding a new field to datatype led to a bunch of strange errors about `Generic`s.
In this minimal reproducer, the generics error is quite small, but i...## Summary
This is a reproducer extracted from something we encountered in the wild.
Adding a new field to datatype led to a bunch of strange errors about `Generic`s.
In this minimal reproducer, the generics error is quite small, but it becomes huge in any non-trivial example.
## Steps to reproduce
Compile the following module:
```
{-# LANGUAGE DeriveAnyClass #-}
module Repro where
import GHC.Generics
data IHaveNoFields = IHaveNoFields { } deriving (Generic)
getField
(IHaveNoFields field1 )
= field1
{-# ANN iHaveAnn ("" :: String) #-}
iHaveAnn = undefined
```
Here is the output:
```
Repro.hs:5:50: error:
• Couldn't match type: Rep IHaveNoFields
with: M1 i0 c0 (M1 i1 c1 U1)
Expected: Rep IHaveNoFields x
Actual: M1 i0 c0 (M1 i1 c1 U1) x
• In the expression: M1 (case x of IHaveNoFields -> M1 U1)
In an equation for ‘from’:
from x = M1 (case x of IHaveNoFields -> M1 U1)
When typechecking the code for ‘from’
in a derived instance for ‘Generic IHaveNoFields’:
To see the code I am typechecking, use -ddump-deriv
In the instance declaration for ‘Generic IHaveNoFields’
|
5 | data IHaveNoFields = IHaveNoFields { } deriving (Generic)
| ^^^^^^^
Repro.hs:5:50: error:
• Couldn't match type: Rep IHaveNoFields
with: M1 i2 c2 (M1 i3 c3 U1)
Expected: Rep IHaveNoFields x
Actual: M1 i2 c2 (M1 i3 c3 U1) x
• In the pattern: M1 x
In an equation for ‘to’:
to (M1 x) = case x of (M1 U1) -> IHaveNoFields
When typechecking the code for ‘to’
in a derived instance for ‘Generic IHaveNoFields’:
To see the code I am typechecking, use -ddump-deriv
In the instance declaration for ‘Generic IHaveNoFields’
|
5 | data IHaveNoFields = IHaveNoFields { } deriving (Generic)
| ^^^^^^^
Repro.hs:8:4: error:
• The constructor ‘IHaveNoFields’ should have no arguments, but has been given 1
• In the pattern: IHaveNoFields field1
In an equation for ‘getField’:
getField (IHaveNoFields field1) = field1
|
8 | (IHaveNoFields field1 )
|
```
## Expected behavior
This should error but should only output:
And indeed this is what we get if we comment out the `ANN` line.
```
Repro.hs:8:4: error:
• The constructor ‘IHaveNoFields’ should have no arguments, but has been given 1
• In the pattern: IHaveNoFields field1
In an equation for ‘getField’:
getField (IHaveNoFields field1) = field1
|
8 | (IHaveNoFields field1 )
| ^^^^^^^^^^^^^^^^^^^^
```
## Environment
* GHC version used: 9.4.8, 9.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/24459GHCi :info uses an outdated mechanism to show type synonym arity2024-03-12T07:30:25ZVladislav ZavialovGHCi :info uses an outdated mechanism to show type synonym arityCurrent GHCi behavior:
```
ghci> type T = Maybe
ghci> :i T
type T :: * -> *
type T = Maybe :: * -> *
-- Defined at <interactive>:24:1
```
I expect to see `type T = Maybe` without the `* -> *` annotation, which is redundant: there's ...Current GHCi behavior:
```
ghci> type T = Maybe
ghci> :i T
type T :: * -> *
type T = Maybe :: * -> *
-- Defined at <interactive>:24:1
```
I expect to see `type T = Maybe` without the `* -> *` annotation, which is redundant: there's a standalone kind signature on the preceding line.
## Historical remark
Such annotations were not wholly redundant in the past, as they could influence arity inference. Compare, for example
```
ghci> type T0 :: forall k. k -> Type; type T0 = Proxy :: forall k. k -> Type
ghci> type T1 :: forall k. k -> Type; type T1 = Proxy
```
GHC 9.6 assigns different arities to T0 and T1:
```
ghci> :i T0
type T0 :: forall k. k -> *
type T0 = Proxy :: forall k. k -> *
-- Defined at <interactive>:4:33
ghci> :i T1
type T1 :: forall k. k -> *
type T1 = Proxy :: k -> *
-- Defined at <interactive>:5:33
```
However, this arcane mechanism has been removed in e89aa0721ca5c594f6811f2108d49cd051488ce1. Here's what GHC HEAD has to say about these declarations:
```
ghci> :i T0
type T0 :: forall k. k -> *
type T0 = Proxy :: forall k. k -> *
-- Defined at <interactive>:4:33
ghci> :i T1
type T1 :: forall k. k -> *
type T1 = Proxy :: forall k. k -> *
-- Defined at <interactive>:5:33
```
That is, they are equivalent. The modern mechanism for controlling arity is the use of @-binders.
## Current status
The pretty-printer has not been updated to use @-binders. Consider this GHCi session (GHC HEAD)
```
ghci> :set -XTypeAbstractions
ghci> type T2 :: forall k. k -> Type; type T2 @k = Proxy
ghci> :i T2
type T2 :: forall k. k -> *
type T2 = Proxy :: k -> *
-- Defined at <interactive>:5:33
```
The arity of the printed declaration is _not_ equivalent to the user-written declaration. It should use `@k` to include the kind variable in the arity: `type T2 @k = Proxy`.
(A further complication is that the printed example triggers a panic, see #24470).
## Proposed fix
1. In the pretty-printer, omit the redundant kind annotation on the RHS of type synonyms
2. In the pretty-printer, use @-binders to control the arity
Also, I've only checked type synonyms. There might be similar issues affecting type families.Andrei BorzenkovAndrei Borzenkovhttps://gitlab.haskell.org/ghc/ghc/-/issues/24458A possible bug on `ghc-pkg check`: "haddock doesn't exist or isn't a file" on...2024-03-05T11:30:41ZSiyuan ChenA possible bug on `ghc-pkg check`: "haddock doesn't exist or isn't a file" on Windows## Summary
There seems some path mismatch on Windows when run `ghc-pkg check`.
## Steps to reproduce
To see which packages are currently available:
<details>
<summary>run `ghc-pkg list`</summary>
```
$ ghc-pkg list
C:\env\haskell\gh...## Summary
There seems some path mismatch on Windows when run `ghc-pkg check`.
## Steps to reproduce
To see which packages are currently available:
<details>
<summary>run `ghc-pkg list`</summary>
```
$ ghc-pkg list
C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib\package.conf.d
Cabal-3.10.2.0
Cabal-syntax-3.10.2.0
Win32-2.13.4.0
array-0.5.6.0
base-4.19.0.0
binary-0.8.9.1
bytestring-0.12.0.2
containers-0.6.8
deepseq-1.5.0.0
directory-1.3.8.1
exceptions-0.10.7
filepath-1.4.100.4
(ghc-9.8.1)
ghc-bignum-1.3
ghc-boot-9.8.1
ghc-boot-th-9.8.1
ghc-compact-0.1.0.0
ghc-heap-9.8.1
ghc-prim-0.11.0
ghci-9.8.1
haskeline-0.8.2.1
hpc-0.7.0.0
integer-gmp-1.1
mtl-2.3.1
parsec-3.1.17.0
pretty-1.1.3.6
process-1.6.18.0
rts-1.0.2
semaphore-compat-1.0.0
stm-2.5.2.1
system-cxx-std-lib-1.0
template-haskell-2.21.0.0
text-2.1
time-1.12.2
transformers-0.6.1.0
xhtml-3000.2.2.1
C:\Users\Chansey\AppData\Roaming\ghc\x86_64-mingw32-9.8.1\package.conf.d
(no packages)
```
</details>
Then check consistency of dependencies in the package database, and report packages that have missing dependencies.
<details>
<summary>run `ghc-pkg check`</summary>
```
$ ghc-pkg check
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/xhtml-3000
.2.2.1-02d5\xhtml.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/xhtml-3000.2.2.1
-02d5 doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/Win32-2.13
.4.0-ba29\Win32.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/Win32-2.13.4.0-b
a29 doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/transforme
rs-0.6.1.0-a711\transformers.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/transformers-0.6
.1.0-a711 doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/time-1.12.
2-4739\time.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/time-1.12.2-4739
doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/text-2.1-3
ba4\text.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/text-2.1-3ba4 do
esn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/template-h
askell-2.21.0.0-7924\template-haskell.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/template-haskell
-2.21.0.0-7924 doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/stm-2.5.2.
1-8422\stm.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/stm-2.5.2.1-8422
doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/semaphore-
compat-1.0.0-265c\semaphore-compat.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/semaphore-compat
-1.0.0-265c doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/rts-1.0.2\
rts.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/rts-1.0.2 doesn'
t exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/process-1.
6.18.0-b64d\process.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/process-1.6.18.0
-b64d doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/pretty-1.1
.3.6-5bc6\pretty.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/pretty-1.1.3.6-5
bc6 doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/parsec-3.1
.17.0-ad46\parsec.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/parsec-3.1.17.0-
ad46 doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/mtl-2.3.1-
54c6\mtl.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/mtl-2.3.1-54c6 d
oesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/integer-gm
p-1.1-8e1c\integer-gmp.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/integer-gmp-1.1-
8e1c doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/hpc-0.7.0.
0-888b\hpc.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/hpc-0.7.0.0-888b
doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/haskeline-
0.8.2.1-cbcb\haskeline.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/haskeline-0.8.2.
1-cbcb doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghci-9.8.1
-91ef\ghci.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghci-9.8.1-91ef
doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghc-prim-0
.11.0-d2c2\ghc-prim.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghc-prim-0.11.0-
d2c2 doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghc-heap-9
.8.1-fe2f\ghc-heap.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghc-heap-9.8.1-f
e2f doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghc-compac
t-0.1.0.0-1e8d\ghc-compact.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghc-compact-0.1.
0.0-1e8d doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghc-boot-t
h-9.8.1-fdfa\ghc-boot-th.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghc-boot-th-9.8.
1-fdfa doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghc-boot-9
.8.1-39f5\ghc-boot.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghc-boot-9.8.1-3
9f5 doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghc-bignum
-1.3-daf9\ghc-bignum.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghc-bignum-1.3-d
af9 doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghc-9.8.1-
f4f4\ghc.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/ghc-9.8.1-f4f4 d
oesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/filepath-1
.4.100.4-6b44\filepath.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/filepath-1.4.100
.4-6b44 doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/exceptions
-0.10.7-9474\exceptions.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/exceptions-0.10.
7-9474 doesn't exist or isn't a directory
Warning: include-dirs: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib\x86_64-windows-ghc-9.8.1\directory-1.3.8.
1-a9dc\include doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/directory-
1.3.8.1-a9dc\directory.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/directory-1.3.8.
1-a9dc doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/deepseq-1.
5.0.0-3a5b\deepseq.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/deepseq-1.5.0.0-
3a5b doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/containers
-0.6.8-18cf\containers.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/containers-0.6.8
-18cf doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/Cabal-synt
ax-3.10.2.0-540c\Cabal-syntax.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/Cabal-syntax-3.1
0.2.0-540c doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/Cabal-3.10
.2.0-9ea7\Cabal.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/Cabal-3.10.2.0-9
ea7 doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/bytestring
-0.12.0.2-14e0\bytestring.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/bytestring-0.12.
0.2-14e0 doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/binary-0.8
.9.1-f682\binary.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/binary-0.8.9.1-f
682 doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/base-4.19.
0.0-efcd\base.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/base-4.19.0.0-ef
cd doesn't exist or isn't a directory
Warning: haddock-interfaces: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/array-0.5.
6.0-edc7\array.haddock doesn't exist or isn't a file
Warning: haddock-html: C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/array-0.5.6.0-ed
c7 doesn't exist or isn't a directory
```
</details>
It seems that `ghc-pkg` can not find haddock. However, if you look the directory carefully, these files definitely exist in the folders.
For example,
```
C:\env\haskell\ghc\ghc-9.8.1-x86_64-unknown-mingw32\lib/../../doc/html/libraries/xhtml-3000.2.2.1-02d5\xhtml.haddock doesn't exist or isn't a file
```
the path after normalization is
```
C:/env/haskell/ghc/doc/html/libraries/xhtml-3000.2.2.1-02d5/xhtml.haddock
```
but this is obviously wrong.
The correct one is
```
C:/env/haskell/ghc/ghc-9.8.1-x86_64-unknown-mingw32/doc/html/libraries/xhtml-3000.2.2.1-02d5/xhtml.haddock
```
There seems some path mismatch on Windows.
P.s. This phenomenon only occurs on windows.
## Expected behavior
No Warning.
## Environment
* GHC version used: ghc-9.8.1
* Operating System: Windows 7/10https://gitlab.haskell.org/ghc/ghc/-/issues/24457Allow ignoring duplicate imports warnings for identifiers from Prelude2024-02-27T15:07:30ZTeo CamarasuAllow ignoring duplicate imports warnings for identifiers from Prelude<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appr...<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appropriate for a GitLab feature request, include GHC API/plugin
innovations, new low-impact compiler flags, or other similar additions to GHC.
-->
## Motivation
There's been a general trend to re-export more things from `Prelude`. In my opinion this is a good trend.
A recent example is the addition of `Control.Applicative.liftA2` to `Prelude` in `ghc-9.6`.
I've recently helped prepare a codebase for `9.8` and a bunch of source files had to be updated to not trigger `-Wredundant-imports` warnings.
Our codebase, as is common in industry, uses `-Wall`. This warning is often a helpful one. It helps avoid overly long import lists, and is especially helpful with workflows where people use HLS or another automated tool that adds imports automatically (and sometimes overzealously).
So, there's two good things that are coming into conflict and causing a bit of churn, namely we need to update our imports whenever stuff is newly re-exported from `Prelude`. I imagine this is even worse for library authors where you want to support several versions of `base`, so you either have to ignore/disable this warning or use CPP.
While splitting [the warning into two](https://gitlab.haskell.org/ghc/ghc/-/issues/21879) is helpful, it doesn't solve this issue, since I would like to get warnings on duplicate imports of identifiers -- just not ones from `Prelude`. For the rest of this I'll assume that's been implemented.
## Proposal
I think we could avoid this conflict by allowing one to opt-out of `-Wduplicate-imports` warnings for duplicated identifiers exported from `Prelude`.
I think this could come in one of two forms:
1. `-Wno-duplicate-imports-from-prelude` explicitly opt-out of `Prelude` warnings. This might seem ad-hoc, but `Prelude` is special anyway.
2. `-Wno-duplicate-imports=Prelude`. Allow opting out of specific modules. This is less ad-hoc but slightly more complicated.
The semantics would be: not specifying a module selects all modules, and then specifying a specific module let's you opt-in/-out for that module.
In either case, such a feature would allow avoiding this papercut. This would be helpful for users like me who do care about redundant duplicated imports, but who don't want to update a bunch of imports when stuff is added to `base`.
What do folks think? Would something like this require a GHC proposal (I'm guessing yes but I wanted to double-check)?https://gitlab.haskell.org/ghc/ghc/-/issues/24456Exception when reading interface files2024-02-27T15:58:39ZArtin Ghasivandghasivand.artin@gmail.comException when reading interface files![Screenshot 2024-02-20 at 11.46.15 at night.jpg](/uploads/f360bec23daa21e30789471dc10459aa/Screenshot_2024-02-20_at_11.46.15_at_night.jpg)
I did a `cabal build` in one of my projects, and then I encountered this error. `cabal clean && ...![Screenshot 2024-02-20 at 11.46.15 at night.jpg](/uploads/f360bec23daa21e30789471dc10459aa/Screenshot_2024-02-20_at_11.46.15_at_night.jpg)
I did a `cabal build` in one of my projects, and then I encountered this error. `cabal clean && cabal build` fixed the issue.
GHC version: 9.8.1
Operating System: macOS 14.3.1
System Architecture: Armhttps://gitlab.haskell.org/ghc/ghc/-/issues/24455Allow annotating fields to be lazy even if the module is not using StrictData2024-03-18T19:54:59ZOleg GrenrusAllow annotating fields to be lazy even if the module is not using StrictDataThis comes up when using Template Haskell.
There is no convenient way to say that the field of data field in generated declaration to be explicitly lazy.
The current go to approach is to query whether `StrictData` extension is enabled ...This comes up when using Template Haskell.
There is no convenient way to say that the field of data field in generated declaration to be explicitly lazy.
The current go to approach is to query whether `StrictData` extension is enabled and then generate `data Foo = Foo ~Int ~Char` or `data = Foo Int Char` based on that.
Or maybe library functions like [`normalC`](https://hackage.haskell.org/package/template-haskell-2.21.0.0/docs/Language-Haskell-TH-Lib-Internal.html#v:normalC) or `sourceLazy` should query whether `StrictData` is enabled and just work.
---
Note, that for terms, one can ask people to enable `BangPatterns` so one could generate explicitly banged code like, `let !foo = 2 + 2 in ...`, but there is no extensions to just enable writing `data Foo = Foo ~Int ~Char` without also changing the meaning of `data Foo = Foo Int Char`, i.e. there is no `LazyDataAnnotations`. In my opinion that is design flaw in `StrictData` extension: it bundles syntax *and* changes defaults.https://gitlab.haskell.org/ghc/ghc/-/issues/24454Feasibility of Splitting CLabel?2024-02-27T14:56:14Zdoyougnujmy6342@gmail.comFeasibility of Splitting CLabel?This isn't an issue per se, but more of an idea that I had while working on https://gitlab.haskell.org/ghc/ghc/-/issues/15560 `CLabel` is a bit of a beast, here is its description:
```
{- |
'CLabel' is an abstract type that supports ...This isn't an issue per se, but more of an idea that I had while working on https://gitlab.haskell.org/ghc/ghc/-/issues/15560 `CLabel` is a bit of a beast, here is its description:
```
{- |
'CLabel' is an abstract type that supports the following operations:
- Pretty printing
- In a C file, does it need to be declared before use? (i.e. is it
guaranteed to be already in scope in the places we need to refer to it?)
- If it needs to be declared, what type (code or data) should it be
declared to have?
- Is it visible outside this object file or not?
- Is it "dynamic" (see details below)
- Eq and Ord, so that we can make sets of CLabels (currently only
used in outputting C as far as I can tell, to avoid generating
more than one declaration for any given label).
- Converting an info table label into an entry label.
CLabel usage is a bit messy in GHC as they are used in a number of different
contexts:
- By the C-- AST to identify labels
- By the unregisterised C code generator (\"PprC\") for naming functions (hence
the name 'CLabel')
- By the native and LLVM code generators to identify labels
For extra fun, each of these uses a slightly different subset of constructors
(e.g. 'AsmTempLabel' and 'AsmTempDerivedLabel' are used only in the NCG and
LLVM backends).
In general, we use 'IdLabel' to represent Haskell things early in the
pipeline. However, later optimization passes will often represent blocks they
create with 'LocalBlockLabel' where there is no obvious 'Name' to hang off the
label.
-}
```
The key part is the `is a bit messy in GHC`. My proposal is to split `CLabel` into parts that satisfy each of the listed needs in the note:
- For c-- AST labels
- For the C code generator
- native and LLVM labels
and remove `CostCentre` `CostCenterStack` `IPE_Label` and `PicBaseLabel`.
### What's the purpose
The code generator does a lot of set manipulation and handling, but because of the above constructors these passes must use `Data.Set` which is a much slower data structure than the intmaps we use all over the compiler. So by re-designing `CLabel` we pave the way to use more efficient data structures and (possibly) speed up the `StgToCmm` pass and its optimizations.doyougnujmy6342@gmail.comdoyougnujmy6342@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/24453Merge ghc-prim and ghc-bignum into ghc-internal2024-03-24T20:19:03ZSylvain HenryMerge ghc-prim and ghc-bignum into ghc-internal- 2008: `ghc-prim` and `integer` packages were spun off `base` to support several `integer` libraries (see fcf6b22d0478be20e27c2245f3e34dd272e12522)
- 2020: `ghc-bignum` replaced the two integer libraries (`integer-simple` and `integer-g...- 2008: `ghc-prim` and `integer` packages were spun off `base` to support several `integer` libraries (see fcf6b22d0478be20e27c2245f3e34dd272e12522)
- 2020: `ghc-bignum` replaced the two integer libraries (`integer-simple` and `integer-gmp`). Instead bignum backends are selected with cabal flags for `ghc-bignum` since then.
- 2024: `base` has been split into `ghc-internal` and `base`
The proposal is to merge `ghc-bignum` and `ghc-prim` packages with `ghc-internal`. Reasons:
1. The split doesn't serve its initial purpose
1. We couldn't merge everything into `base` before (it wasn't supposed to contain GHC internal things), but in `ghc-internal` we can/should
2. Having 3 packages adds extra complexity (dependency bounds, hackage uploads, etc.). It's much simpler to explain that everything GHC exposes to Haskell programs comes from `ghc-internal` and that it is the only package tightly bound to a specific GHC (with `template-haskell`, but I think we could merge part of it into `ghc-internal` too and only expose a stable TH interface from `template-haskell` package).
3. `ghc-prim` and `ghc-bignum` have implicit restrictions: they can't depend on anything defined in `ghc-internal`, yet GHC may introduce references to entities defined in `ghc-internal` (e.g. exceptions, see #18157). With a single package we could even use `.hs-boot` files for real cyclic dependencies like throwing an exception from `ghc-bignum`: for now we use a hack (ghc primops---defined in the rts---that raise a (wired-in) exception---defined in `ghc-internal`).
For backward compatibility we could provide shallow `ghc-prim` and `ghc-bignum` packages that reexport modules that have been merged into `ghc-internal` (for a few releases).https://gitlab.haskell.org/ghc/ghc/-/issues/24452Confusing "Ambiguous occurrence" error message in the presence of qualified i...2024-02-20T15:05:23ZRyan ScottConfusing "Ambiguous occurrence" error message in the presence of qualified importsCompiling this program:
```hs
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
module Bug where
import Control.Applicative (Alternative)
import qualified Data.Map as Map
import qualified Data.Set as Set
newtype Foo a = MkFoo [a] deriving (...Compiling this program:
```hs
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
module Bug where
import Control.Applicative (Alternative)
import qualified Data.Map as Map
import qualified Data.Set as Set
newtype Foo a = MkFoo [a] deriving (Functor, Applicative)
instance Alternative Foo where
empty = undefined
```
Yields the following error message (I've tried GHC 8.10 through 9.8):
```
$ ghc-9.8.1 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:11:3: error: [GHC-87543]
Ambiguous occurrence ‘empty’.
It could refer to
either ‘Map.empty’,
imported qualified from ‘Data.Map’ at Bug.hs:5:1-32
(and originally defined in ‘Data.Map.Internal’),
or ‘Set.empty’,
imported qualified from ‘Data.Set’ at Bug.hs:6:1-32
(and originally defined in ‘Data.Set.Internal’).
|
11 | empty = undefined
| ^^^^^
```
This program _is_ invalid, but not for the reasons stated in this error message. `empty` isn't ambiguous at all. Rather, it's not in scope in the first place! The fix is to bring it into scope like so:
```diff
-import Control.Applicative (Alternative)
+import Control.Applicative (Alternative(empty))
```
The error message would have you believe that the problem is that GHC cannot pick between `Map.empty` and `Set.empty`. But this isn't the case at all, as the program would not be valid if you substituted either of these identifiers into the instance. For instance, if you wrote this:
```hs
instance Alternative Foo where
Map.empty = undefined
```
Then GHC would instead produce this error message:
```
$ ghc-9.8.1 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:11:3: error: [GHC-87543]
Ambiguous occurrence ‘Map.empty’.
It could refer to
either ‘Map.empty’,
imported qualified from ‘Data.Map’ at Bug.hs:5:1-32
(and originally defined in ‘Data.Map.Internal’),
or ‘Set.empty’,
imported qualified from ‘Data.Set’ at Bug.hs:6:1-32
(and originally defined in ‘Data.Set.Internal’).
|
11 | Map.empty = undefined
| ^^^^^^^^^
Bug.hs:11:3: error: [GHC-28329]
Qualified name in binding position: Map.empty
|
11 | Map.empty = undefined
| ^^^^^^^^^
```
It took several minutes of head-scratching to realize what the _actual_ issue was. It would be nice if GHC could tell me the actual problem (`empty` not being in scope) in the first place.https://gitlab.haskell.org/ghc/ghc/-/issues/24451hadrian: New untracked dependencies after ghc-internal patch?2024-03-11T15:20:25ZAndreas Klebingerhadrian: New untracked dependencies after ghc-internal patch?## Summary
I got one of these errors that sounds like we try to load an interface file before it's compiled because hadrian doesn't track the dependencies correctly.
## Steps to reproduce
hadrian/build -j6 (for me anyway).
This was t...## Summary
I got one of these errors that sounds like we try to load an interface file before it's compiled because hadrian doesn't track the dependencies correctly.
## Steps to reproduce
hadrian/build -j6 (for me anyway).
This was the end of the output:
```
Command line: _build/stage0/bin/ghc -Wall -Wcompat -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage1/inplace/package.conf.d' '-this-unit-id base-4.19.0.0-inplace' '-this-package-name base' '-package-id ghc-internal-0.1.0.0-inplace' -i -i/home/andi/ghc_expose_overloaded_unfoldings/_build/stage1/libraries/base/build -i/home/andi/ghc_expose_overloaded_unfoldings/_build/stage1/libraries/base/build/autogen -i/home/andi/ghc_expose_overloaded_unfoldings/libraries/base/src -Irts/include -I_build/stage1/libraries/base/build -I/home/andi/ghc_expose_overloaded_unfoldings/libraries/ghc-internal/include -I/home/andi/ghc_expose_overloaded_unfoldings/_build/stage1/libraries/ghc-internal/build/include -I/home/andi/ghc_expose_overloaded_unfoldings/libraries/ghc-bignum/include/ -I/home/andi/ghc_expose_overloaded_unfoldings/_build/stage1/libraries/ghc-bignum/build/include/ -I/home/andi/ghc_expose_overloaded_unfoldings/rts/include -I/home/andi/ghc_expose_overloaded_unfoldings/_build/stage1/rts/build/include -optP-include -optP_build/stage1/libraries/base/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/base/build -fdiagnostics-color=always -this-unit-id base -XHaskell2010 -no-global-package-db -package-db=/home/andi/ghc_expose_overloaded_unfoldings/_build/stage1/inplace/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -Wnoncanonical-monad-instances -optc-Wno-error=inline -c libraries/base/src/Data/Char.hs -o _build/stage1/libraries/base/build/Data/Char.p_o -O2 -H32m -haddock -Wno-deprecated-flags -Wno-trustworthy-safe
===> Command failed with error code: 1
/home/andi/ghc_expose_overloaded_unfoldings/_build/stage1/inplace/../libraries/ghc-internal/build/GHC/Err.p_hi
Declaration for errorWithoutStackTrace
Unfolding of errorWithoutStackTrace:
SomeException ErrorWithoutFlag
Failed to load interface for ‘GHC.Exception.Type’.
Perhaps you haven't installed the profiling libraries for package ‘ghc-internal-0.1.0.0’?
Use -v to see a list of the files searched for.
Cannot continue after interface file error
Command failed
Build failed.
```
## Expected behavior
No errors.
## Environment
* GHC version used:
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/24450Apparently deadlock in write to closed handle2024-02-18T18:50:57ZBen GamariApparently deadlock in write to closed handle@hvr reported that the following program non-deterministically hang:
```haskell
import System.IO
main :: IO ()
main = do
hPutChar stderr 'A' -- unbuffered
hPutChar stdout 'X' -- buffered -- will indeterministically cause delayed lo...@hvr reported that the following program non-deterministically hang:
```haskell
import System.IO
main :: IO ()
main = do
hPutChar stderr 'A' -- unbuffered
hPutChar stdout 'X' -- buffered -- will indeterministically cause delayed lock-ups
hPutChar stderr 'Z' -- unbuffered
hPutChar stderr '\n' -- unbuffered
```
```sh
$ ghc -threaded -O Main.hs
$ while :; do ./Main >&- ; done
AZ
AZ
*hang*
```
I can confirm that the program hangs almost immediately on Linux with GHC 9.2.8, 9.6.3, and 9.8.1. @hvr says that the issue may have been introduced in GHC 8.2.1.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24449T23540 is fragile on i3862024-03-25T19:13:15ZCheng ShaoT23540 is fragile on i386Over the past few weeks, T23540 has been fragile on i386, failing on multiple MRs and relevant marge pipelines. An incomplete list of victims:
- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11530
- https://gitlab.haskell.org/ghc/...Over the past few weeks, T23540 has been fragile on i386, failing on multiple MRs and relevant marge pipelines. An incomplete list of victims:
- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11530
- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11973
- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11983
It is unclear at this point why T23540 worked on i386 in the past but starts failing only on i386 when you change some ghc frontend internals. It may be related to the unique fragility again (another instance of #24261), and while 615eb855416ce536e02ed935ecc5a6f25519ae16 was sufficient to prevent T23540 regression on !11530 !11973, it wasn't sufficient to prevent the error from surfacing in !11983.
This issue tracks the T23540 fragility on i386. To avoid blocking work on other fronts, while we look into it further, I'll land a patch that marks it fragile.https://gitlab.haskell.org/ghc/ghc/-/issues/24448Confusing error message when illegally using `forall` in type signature.2024-03-08T18:56:41ZJadeConfusing error message when illegally using `forall` in type signature.with `-XNoExplicitForAll` and the snippet
```hs
my_id :: forall a. a -> a
my_id x = x
```
ghc throws an error and suggests the following:
```
Perhaps you intended to use RankNTypes
or a similar language extension to enable explicit-foral...with `-XNoExplicitForAll` and the snippet
```hs
my_id :: forall a. a -> a
my_id x = x
```
ghc throws an error and suggests the following:
```
Perhaps you intended to use RankNTypes
or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type>
```
this seems entirely wrong to me, because the extension for enabling this syntax is `-XExplicitForAll` which could be suggested here. `RankNTypes` implies `ExplicitForAll`, but you get the same error message if you attempt to compile the above with `-XRankNTypes -XNoExplicitForAll`.
In my opinion the error message should instead say:
```
Perhaps you intended to use the ExplicitForAll language extension
to enable explicit-forall syntax: forall <tvs>. <type>
```https://gitlab.haskell.org/ghc/ghc/-/issues/24447Suggest `-XScopedTypeVariables` with an out-of-scope type variable2024-02-20T20:45:19ZJadeSuggest `-XScopedTypeVariables` with an out-of-scope type variableGiven the setup of
```hs
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE ExplicitForAll #-}
import Data.Data (Proxy(Proxy))
import GHC.TypeLits (symbolVal, KnownSymbol, Symbol)
```
both
```hs
class Foo f...Given the setup of
```hs
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE ExplicitForAll #-}
import Data.Data (Proxy(Proxy))
import GHC.TypeLits (symbolVal, KnownSymbol, Symbol)
```
both
```hs
class Foo f where
whatever :: Proxy f -> String
data Bar (s :: Symbol)
instance KnownSymbol s => Foo (Bar s) where
whatever _ = symbolVal (Proxy @s)
```
and
```hs
whatever :: forall s. KnownSymbol s => Proxy s -> String
whatever _ = symbolVal (Proxy @s)
```
fail with `[GHC-76037] Not in scope: type variable ‘s’`
I think it would be sensible to suggest enabling `ScopedTypeVariables` here. The only other place where the extension is suggested is when type signatures occur in patterns.https://gitlab.haskell.org/ghc/ghc/-/issues/24446STM: Locking approach during transaction validation can cause lack of progress2024-03-12T21:45:56ZAndreas KlebingerSTM: Locking approach during transaction validation can cause lack of progress## Summary
The current STM implementation can result in situations where even two read-only transactions running in parallel offer no guarantee of the transactions making progress. (However nothing suggests this behaviour is limited to ...## Summary
The current STM implementation can result in situations where even two read-only transactions running in parallel offer no guarantee of the transactions making progress. (However nothing suggests this behaviour is limited to read-only transactions).
This is one of the STM issues surfaced by https://gitlab.haskell.org/ghc/ghc/-/issues/24142
## Steps to reproduce
This can reproduced on these files:
stm-starvation.cabal :
```cabal
cabal-version: 3.0
name: stm-starvation
version: 0.1.0.0
maintainer: Xander van der Goot
build-type: Simple
extra-doc-files: README
common opt
ghc-options:
-Wall -Wpartial-fields -O2 -rtsopts -debug -threaded -Wunused-packages
"-with-rtsopts=-N"
build-depends:
async,
base,
stm,
executable map
import: opt
main-is: Map.hs
hs-source-dirs: app
default-language: Haskell2010
build-depends:
stm-containers,
list-t
```
Map.hs:
```haskell
{-# LANGUAGE NumericUnderscores #-}
import Control.Concurrent (ThreadId, myThreadId)
import qualified Control.Concurrent.Async as Async
import Control.Concurrent.STM (STM, atomically)
import Data.IORef (IORef, modifyIORef', newIORef, readIORef)
import GHC.IO (unsafePerformIO)
import qualified ListT
import qualified StmContainers.Map as STMMap
import System.IO (hFlush, stdout)
main :: IO ()
main = do
let l = [(x,x) | x <- [1 :: Integer .. 100_000]]
stmmap <- STMMap.newIO
atomically $ mapM_ (\(x, y) -> STMMap.insert x y stmmap) l
print "Initialized the STM Map."
hFlush stdout
-- Show that a read from a single thread does succeed
readMap stmmap
-- read the stm map from two threads concurrently
foldr1 Async.concurrently_ [readMap stmmap, readMap stmmap]
-- | irrevocable counter to keep track of transaction restart.
restartCounter :: ThreadId -> IORef Integer -> STM ()
restartCounter threadId counter = unsafePerformIO $ do
r <- readIORef counter
print (threadId, r)
hFlush stdout
modifyIORef' counter (+ 1)
return (return ())
readMap :: (Show a, Show b) => STMMap.Map a b -> IO ()
readMap stmmap = do
threadId <- myThreadId
counter <- newIORef (0 :: Integer)
_ <- atomically $ do
restartCounter threadId counter
ListT.toList (STMMap.listT stmmap)
return ()
```
Just run the program and it will take a unreasonable long time to finish, or might never finish depending on the system it's run on and luck.
## Expected behavior
Since read-only transactions don't conflict with each other I would have assumed there is a guarantee of progress.
## Analysis:
When a running thread returns to the scheduler it will validate its current STM transaction. This involves locking all the TVars in the transaction optimistically. If locking of any of the tvars fails the validation will fail and we will assume it's due to a data conflict and abort the transaction, forcing it to be restarted.
This is problematic if multiple threads running transactions on the same set of tvars return to the scheduler in parallel. Both threads will try to lock the same set of tvars in parallel, guaranteeing one of them fails. Resulting in one of the two transactions being aborted and restarted.
Since it's dependent on timing which of the two transactions get's forcibly restarted, it's possible that both transactions get restarted repeatedly, in the worst case infinitely often preventing any progress.
This for example might look something like this:
```
Thread1: run_t-> validate -> run_t -> validate -> run_t -> validate fails -> abort -> restart -> run_t -> ..
Thread2: run_t-> validate fails -> abort -> restart -> run_t -> validate -> run_t -> validate -> run_t -> ..
Thread1: validate -> run_t -> validate -> run_t -> ...
Thread2: -> validate fails -> abort -> restart -> ...
```
## Solutions:
I think the underlying issue is that the current algorithm causes transaction validation to fail if a tvar is only temporarily locked, even if the memory is still consistent with the transactions view of memory.
The solution is to allow us to distinguish between locks failing because of inconsistent memory states, and locks failing for "spurious" reasons.
## Environment
* GHC version used: Any
Optional:
* Operating System:
* System Architecture: Any SMPAndreas KlebingerAndreas Klebinger