GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-02-25T00:10:49Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24472Eliminate string-y Id lookups in Wasm backend2024-02-25T00:10:49ZBen GamariEliminate string-y Id lookups in Wasm backendIt appears that the Wasm backend has a rather atypical way of referring to `base` declarations. For instance, `GHC.HsToCore.Foreign.Wasm` has many mentions like:
```haskell
unsafeDupablePerformIO_id <-
lookupGhcInternalVarId
...It appears that the Wasm backend has a rather atypical way of referring to `base` declarations. For instance, `GHC.HsToCore.Foreign.Wasm` has many mentions like:
```haskell
unsafeDupablePerformIO_id <-
lookupGhcInternalVarId
"GHC.Internal.IO.Unsafe"
"unsafeDupablePerformIO"
```
This is very brittle and inconsistent with how similar references occur elsewhere in GHC. Specifically, this sort of reference should be realized by giving the declaration a known-key name (c.f. `GHC.Builtin.Names`) and using `dsLookupGlobalId` to lookup the identifier.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24471Float out can take quadratic time2024-03-06T19:19:35ZJaro ReindersFloat out can take quadratic time## Summary
I've written a simple Template Haskell program that produces nested expressions. If these programs get large then it can take very long to compile them.
## Steps to reproduce
```haskell
{-# LANGUAGE TemplateHaskell #-}
modu...## Summary
I've written a simple Template Haskell program that produces nested expressions. If these programs get large then it can take very long to compile them.
## Steps to reproduce
```haskell
{-# LANGUAGE TemplateHaskell #-}
module Common where
data List_ a f = Nil_ | Cons_ a f deriving Functor
between alg a b
| a == b = [|| $$alg Nil_ ||]
| otherwise = [|| $$alg (Cons_ a $$(between alg (a + 1) b)) ||]
```
```haskell
{-# LANGUAGE TemplateHaskell #-}
module Foo where
import Common
foo :: (List_ Int a -> a) -> a
foo alg = $$(between [|| alg ||] 0 1000)
```
If we compile this with `ghc -O Foo.hs -ddump-timings` we will see the float out timings. If I change the third argument of between from 1000 we can see how it scales:
| size | 2nd float-out time (ms) |
| ------: | ------: |
| 1000 | 601 |
| 2000 | 2595 |
| 3000 | 5862 |
| 4000 | 10944 |
| 5000 | 18825 |
| 6000 | 25289 |
| 7000 | 34933 |
| 8000 | 49785 |
| 9000 | 61680 |
| 10000 | 76162 |
So it seems float-out takes quadratic time in this case.
In particular, I'm looking at the second float out pass, which looks like this in the dump:
```
*** Float out(FOS {Lam = Just 0,
Consts = True,
OverSatApps = True}) [Foo]:
Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [Foo]: alloc=205141562384 time=76162.434
```
Also the remaining timings do seem to scale linearly. With code generation taking the most time besides that second float out pass.
## Expected behavior
Compile faster.
## Environment
* GHC version used: 9.8.1Jaro ReindersJaro Reindershttps://gitlab.haskell.org/ghc/ghc/-/issues/24470Implicit RHS quantification in type synonyms crashes GHC2024-03-25T19:13:15ZVladislav ZavialovImplicit RHS quantification in type synonyms crashes GHCThis example is accepted by GHC 9.8 but crashes GHC HEAD:
```haskell
type SynBad :: forall k. k -> Type
type SynBad = Proxy :: j -> Type
```
```
Test.hs:7:24: error: [GHC-76329]
• GHC internal error: ‘j’ is not in scope during type...This example is accepted by GHC 9.8 but crashes GHC HEAD:
```haskell
type SynBad :: forall k. k -> Type
type SynBad = Proxy :: j -> Type
```
```
Test.hs:7:24: error: [GHC-76329]
• GHC internal error: ‘j’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [rDP :-> ATcTyCon SynBad :: forall k.
k -> *]
• In the kind ‘j -> Type’
In the type ‘Proxy :: j -> Type’
In the type declaration for ‘SynBad’
|
7 | type SynBad = Proxy :: j -> Type
|
```
While this one is accepted by both compilers:
```haskell
type SynOK :: forall k. k -> Type
type SynOK @t = Proxy :: j -> Type
```
The difference between `SynBad` and `SynOK` is the arity. Adding the `@t` binder changes the arity of `SynOK` so that it includes `j` (in fact, `j=t=k`.)
This is an example of rather exotic interaction between SAKS, arity, and implicit RHS quantification in type synonyms.
Long-term, both examples should be rejected, as implicit RHS quantification in type synonyms is deprecated anyway
```
Test.hs:8:24: warning: [GHC-16382] [-Wimplicit-rhs-quantification]
The variable ‘j’ occurs free on the RHS of the type declaration
In the future GHC will no longer implicitly quantify over such variables
Suggested fix: Bind ‘j’ on the LHS of the type declaration
|
8 | type SynBad = Proxy :: j -> Type
| ^
Test.hs:11:26: warning: [GHC-16382] [-Wimplicit-rhs-quantification]
The variable ‘j’ occurs free on the RHS of the type declaration
In the future GHC will no longer implicitly quantify over such variables
Suggested fix: Bind ‘j’ on the LHS of the type declaration
|
11 | type SynOK @t = Proxy :: j -> Type
| ^
Ok, one module loaded.
```
Short-term (for the next few releases while we still supported implicit RHS quantification in type synonyms), we probably want a proper error message for `SynBad`. Arity inference has been removed in e89aa0721ca5c594f6811f2108d49cd051488ce1, so that rules out accepting `SynBad`. And if we reject it, it's much better to do so with a proper error message rather than a compiler panic.Andrei BorzenkovAndrei Borzenkovhttps://gitlab.haskell.org/ghc/ghc/-/issues/24469Lexer is too permissive with numbers followed by an identifier (e.g. "1foo")2024-02-28T18:22:40ZVaibhav SagarLexer is too permissive with numbers followed by an identifier (e.g. "1foo")## Summary
GHC's lexer lexes numbers followed by an identifier as two separate tokens (number and then identifier) when I think it should reject this as invalid.
## Steps to reproduce
```
GHCi, version 9.8.1: https://www.haskell.org/g...## Summary
GHC's lexer lexes numbers followed by an identifier as two separate tokens (number and then identifier) when I think it should reject this as invalid.
## Steps to reproduce
```
GHCi, version 9.8.1: https://www.haskell.org/ghc/ :? for help
ghci> foo = 1
ghci> (+) 1foo
2
```
## Expected behavior
I would expect the lexer to throw an error.
## Environment
* GHC version used: 9.8.1
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/24468RTS: GC assertion failed - rts/sm/GC.c, line 15672024-02-27T15:27:47ZAndreas KlebingerRTS: GC assertion failed - rts/sm/GC.c, line 1567## Summary
On ghc HEAD built with:
`hadrian/build --flavour=default+no_profiled_libs+omit_pragmas -j7`
And compiling the program below I trigger an assertion failure.
repovec.cabal:
```
cabal-version: 3.0
name: re...## Summary
On ghc HEAD built with:
`hadrian/build --flavour=default+no_profiled_libs+omit_pragmas -j7`
And compiling the program below I trigger an assertion failure.
repovec.cabal:
```
cabal-version: 3.0
name: repovec
version: 0.1.0.0
license: BSD-3-Clause
license-file: LICENSE
author: Andreas Klebinger
build-type: Simple
extra-doc-files: CHANGELOG.md
common warnings
ghc-options: -Wall -O2 -rtsopts -debug -with-rtsopts "-H200M -M206M -N2 -ki10M" -g3 -threaded
executable repovec
import: warnings
main-is: Main.hs
build-depends: base, vector, array
hs-source-dirs: app
default-language: GHC2021
```
app/Main.hs
```
module Main where
import Data.Vector as V
import System.Mem (performMajorGC)
import Prelude as P
main :: IO ()
main = do
let !vec = V.replicate 1_100_000 (1111111111 :: Int)
performMajorGC
print "post gc"
print $ V.length vec
```
If I run this with `cabal --storedir store2 run -w /home/andi/ghc_mem_limit/_build/stage1/bin/ghc`
```
andi@horzube Thu 20:44:~/repos/agda/repo_vec$ cabal --storedir store run -w /home/andi/ghc_mem_limit/_build/stage1/bin/ghc
Up to date
repovec: internal error: ASSERTION FAILED: file rts/sm/GC.c, line 1567
(GHC version 9.9.20240221 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
## Environment
* GHC version used:
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/24467Print the resulting data type declaration of explicitly instantiated type par...2024-02-27T16:42:10ZArtin Ghasivandghasivand.artin@gmail.comPrint the resulting data type declaration of explicitly instantiated type parameters using the :info command in ghciAssume the following code is loaded into GHCi:
```haskell
data Foo a = Blah1 (XXBlah1 a) | Blah2 (XXBlah2 a)
type family XXBlah1 a where
XXBlah1 Int = String
XXBlah1 String = Bool
type family XXBlah2 a where
XXBlah2 Char = Stri...Assume the following code is loaded into GHCi:
```haskell
data Foo a = Blah1 (XXBlah1 a) | Blah2 (XXBlah2 a)
type family XXBlah1 a where
XXBlah1 Int = String
XXBlah1 String = Bool
type family XXBlah2 a where
XXBlah2 Char = String
XXBlah2 String = Int
```
The user can write `:info Foo` and then GHCi will print the following to the screen:
```plaintext
type role Foo nominal
type Foo :: * -> *
data Foo a = Blah1 (XXBlah1 a) | Blah2 (XXBlah2 a)
-- Defined at /Users/artin/Programming/ghciinfocommand.hs
```
It would be pretty useful if we could write:
`:info (Foo String)`
and get:
`data Foo String = Blah1 Bool | Blah2 Int`
(The parenthesis is needed, because if not explicitly written, the info command will print the info of `Foo` and `String` separately.
I find myself looking for this feature whenever I'm working with TTG data types.Artin Ghasivandghasivand.artin@gmail.comArtin Ghasivandghasivand.artin@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/24466Improve FloatIn for case expressions2024-02-29T09:30:13ZSimon Peyton JonesImprove FloatIn for case expressionsRelated tickets:
* #2988
Consider this function:
```
f :: Int -> Int -> (Int,Int)
f z x = let y = x+1 in
case z of
0 -> (y,y)
1 -> (y,y+1)
_ -> (99,1)
```
It would be better if we floated that `y` t...Related tickets:
* #2988
Consider this function:
```
f :: Int -> Int -> (Int,Int)
f z x = let y = x+1 in
case z of
0 -> (y,y)
1 -> (y,y+1)
_ -> (99,1)
```
It would be better if we floated that `y` thunk into the two case branches, thus
```
f z x = let y = x+1 in
case z of
0 -> let y = x+1 in (y,y)
1 -> let y = x+1 in (y,y+1)
_ -> (99,1)
```
We get a bit of code duplication (just as we do with inlining) but in exchange we may never
allocate that thunk, which may matter if the default branch is the hot path.
Also `y` might be used strictly. Suppose one RHS was simply `g y y` where `g` is strict.
Then if we float the thunk into that RHS we can use call-by-value for it.
Currently we sort-of handle this case in `postInlineUnconditionally`; see
this Note in GHC.Core.Opt.Simplify.Utils:
```
{- Note [Inline small things to avoid creating a thunk]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The point of examining occ_info here is that for *non-values* that
occur outside a lambda, the call-site inliner won't have a chance
(because it doesn't know that the thing only occurs once). The
pre-inliner won't have gotten it either, if the thing occurs in more
than one branch So the main target is things like
let x = f y in
case v of
True -> case x of ...
False -> case x of ...
This is very important in practice; e.g. wheel-seive1 doubles
in allocation if you miss this out. And bits of GHC itself start
to allocate more. An egregious example is test perf/compiler/T14697,
where GHC.Driver.CmdLine.$wprocessArgs allocated hugely more.
```
But it's very ad-hoc. It only applies if `x` is used exactly once in each branch!
## A better plan
A better plan would be for FloatIn to float `y` inwards, perhaps entirely replacing this
stuff in `postInlineUnconditionally`. This ticket records the idea.
## A problem
Consider
```
foo1 z = let x = <thunk> in
join j y = .x..x... in
case z of
A -> j 1
B -> j 2
C -> x+1
foo2 z = let x = <thunk> in
join j y = ...x... in
case h x z of
A -> j 1
B -> j 2
C -> x+1
```
* In the case of `foo1` we can float `x` inwards, both into the RHS of the join point `j`, and into the C branch.
* But we **must not** do that for `foo2` because it would lose sharing. We would evaluate `<thunk>` twice,
once in the call `h <thunk z`, and once in the RHS of `j`
Annoyingly, if we inlined the join point we would do the Right Thing in both cases.
How can we do the Right Thing even when the join point is there?
Note that no occurrence analysis (which pins a single OccInfo on each binder) can get this right. Consider this combination of `foo1` and `foo2`:
```
foo1 z = let x = <thunk> in
join j1 y = .x..x... in
case z of
A -> j1 1
B -> j1 2
C -> join j2 p = ...x...
case h x z of
A -> j2 1
B -> j2 2
C -> x+1
```
Here we can push `x` into the RHS of `j1` and into the `C` branch; but **not** into the RHS of `j2` for the same reason as `foo2`.Simon Peyton JonesSimon Peyton Joneshttps://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/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/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 Gamari