GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:37:59Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9997"A module cannot import itself"-regression2019-07-07T18:37:59ZHerbert Valerio Riedelhvr@gnu.org"A module cannot import itself"-regressionThe following module could be compiled with GHC 7.8.4 and older, but fails with GHC 7.10:
```hs
{-# LANGUAGE PackageImports #-}
module Control.DeepSeq where
import "deepseq" Control.DeepSeq
```
```
$ ghci -Wall DeepSeq.hs
GHCi, versi...The following module could be compiled with GHC 7.8.4 and older, but fails with GHC 7.10:
```hs
{-# LANGUAGE PackageImports #-}
module Control.DeepSeq where
import "deepseq" Control.DeepSeq
```
```
$ ghci -Wall DeepSeq.hs
GHCi, version 7.10.0.20141227: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Control.DeepSeq ( DeepSeq.hs, interpreted )
DeepSeq.hs:5:1: A module cannot import itself: Control.DeepSeq
Failed, modules loaded: none.
λ:2>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ezyang |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"A module cannot import itself\"-regression","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc1","keywords":["regression"],"differentials":[],"test_case":"","architecture":"","cc":["ezyang"],"type":"Bug","description":"The following module could be compiled with GHC 7.8.4 and older, but fails with GHC 7.10:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE PackageImports #-}\r\n\r\nmodule Control.DeepSeq where\r\n\r\nimport \"deepseq\" Control.DeepSeq\r\n}}}\r\n\r\n{{{\r\n$ ghci -Wall DeepSeq.hs\r\nGHCi, version 7.10.0.20141227: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Control.DeepSeq ( DeepSeq.hs, interpreted )\r\n\r\nDeepSeq.hs:5:1: A module cannot import itself: Control.DeepSeq\r\nFailed, modules loaded: none.\r\nλ:2> \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/9961compile-time performance regression compiling genprimcode2019-07-07T18:38:12ZHerbert Valerio Riedelhvr@gnu.orgcompile-time performance regression compiling genprimcodecompiling `utils/genprimopcode` (where compiling the Alex-generated Lexer takes up the most amount of time) with GHC 7.8.4:
```
$ time /opt/ghc/7.8.4/bin/ghc -Rghc-timing --make -O Main.hs
[1 of 5] Compiling ParserM ( ParserM...compiling `utils/genprimopcode` (where compiling the Alex-generated Lexer takes up the most amount of time) with GHC 7.8.4:
```
$ time /opt/ghc/7.8.4/bin/ghc -Rghc-timing --make -O Main.hs
[1 of 5] Compiling ParserM ( ParserM.hs, ParserM.o )
[2 of 5] Compiling Lexer ( Lexer.hs, Lexer.o )
[3 of 5] Compiling Syntax ( Syntax.hs, Syntax.o )
[4 of 5] Compiling Parser ( Parser.hs, Parser.o )
[5 of 5] Compiling Main ( Main.hs, Main.o )
Linking Main ...
<<ghc: 20742311240 bytes, 2092 GCs, 60174814/140258264 avg/max bytes residency (33 samples), 332M in use, 0.00 INIT (0.00 elapsed), 7.84 MUT (8.35 elapsed), 6.93 GC (6.93 elapsed) :ghc>>
real 0m15.331s
user 0m15.173s
sys 0m0.172s
```
(btw, is it ok that GC takes up so much?)
the same with a GHC 7.10 snapshot takes \*alot\* longer:
```
$ time /opt/ghc/7.10.1/bin/ghc -Rghc-timing --make -O Main.hs
[1 of 5] Compiling ParserM ( ParserM.hs, ParserM.o )
[2 of 5] Compiling Lexer ( Lexer.hs, Lexer.o )
[3 of 5] Compiling Syntax ( Syntax.hs, Syntax.o )
[4 of 5] Compiling Parser ( Parser.hs, Parser.o )
[5 of 5] Compiling Main ( Main.hs, Main.o )
Linking Main ...
<<ghc: 147681534568 bytes, 37824 GCs, 203338614/375314176 avg/max bytes residency (538 samples), 876M in use, 0.001 INIT (0.001 elapsed), 81.374 MUT (81.888 elapsed), 235.240 GC (235.136 elapsed) :ghc>>
real 5m17.061s
user 5m16.702s
sys 0m0.499s
```
1. ..and here the GC/MUT ratio is even more off.7.10.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/9857GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2`2019-07-07T18:38:44ZHerbert Valerio Riedelhvr@gnu.orgGHC 7.9 panics (simplifier ticks exhausted) on `half-0.2`Compiling hackage:half-0.2 results in a GHC Panic:
```
$ ghc --version && ghc --print-project-git-commit-id
The Glorious Glasgow Haskell Compilation System, version 7.9.20141202
bf2d75417b5be7e8a79a26ee57a81e00682dabd4
$ cabal get half...Compiling hackage:half-0.2 results in a GHC Panic:
```
$ ghc --version && ghc --print-project-git-commit-id
The Glorious Glasgow Haskell Compilation System, version 7.9.20141202
bf2d75417b5be7e8a79a26ee57a81e00682dabd4
$ cabal get half-0.2 && cd half-0.2/src/Numeric/
Unpacking to half-0.2/
$ ghc -Wall -O -fforce-recomp -c Half.hs
ghc: panic! (the 'impossible' happened)
(GHC version 7.9.20141202 for x86_64-unknown-linux):
Simplifier ticks exhausted
When trying UnfoldingDone lvl_s5yo
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
To see detailed counts use -ddump-simpl-stats
Total ticks: 125160
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2`","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"Bug","description":"Compiling hackage:half-0.2 results in a GHC Panic:\r\n\r\n{{{\r\n$ ghc --version && ghc --print-project-git-commit-id\r\nThe Glorious Glasgow Haskell Compilation System, version 7.9.20141202\r\nbf2d75417b5be7e8a79a26ee57a81e00682dabd4\r\n\r\n$ cabal get half-0.2 && cd half-0.2/src/Numeric/\r\nUnpacking to half-0.2/\r\n\r\n$ ghc -Wall -O -fforce-recomp -c Half.hs \r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.9.20141202 for x86_64-unknown-linux):\r\n\tSimplifier ticks exhausted\r\n When trying UnfoldingDone lvl_s5yo\r\n To increase the limit, use -fsimpl-tick-factor=N (default 100)\r\n If you need to do this, let GHC HQ know, and what factor you needed\r\n To see detailed counts use -ddump-simpl-stats\r\n Total ticks: 125160\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/9771Excessive memory usage compiling T30642019-07-07T18:39:07ZHerbert Valerio Riedelhvr@gnu.orgExcessive memory usage compiling T3064With 64dc4d1085a7db375f6532362bf7e23fac3a25eb the testsuite suffers from T3064 allocating an excessive amount of memory (several GiBs) and finally getting killed due to timeout and/or out-of-memory.
```
=====> T3064(normal) 3054 of 4150...With 64dc4d1085a7db375f6532362bf7e23fac3a25eb the testsuite suffers from T3064 allocating an excessive amount of memory (several GiBs) and finally getting killed due to timeout and/or out-of-memory.
```
=====> T3064(normal) 3054 of 4150 [0, 0, 0]
cd ./perf/compiler && '/home/hvr/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1
Compile failed (status 35072) errors were:
Killed
Failed to find field: peak_megabytes_allocated
*** framework failure for T3064(normal) do_test exception
Traceback (most recent call last):
File "/home/hvr/ghc/testsuite/driver/testlib.py", line 793, in do_test
result = func(*[name,way] + args)
File "/home/hvr/ghc/testsuite/driver/testlib.py", line 995, in compile
return do_compile( name, way, 0, '', [], extra_hc_opts )
File "/home/hvr/ghc/testsuite/driver/testlib.py", line 1024, in do_compile
result = simple_build( name, way, extra_hc_opts, should_fail, top_mod, 0, 1, force, override_flags )
File "/home/hvr/ghc/testsuite/driver/testlib.py", line 1262, in simple_build
statsResult = checkStats(name, way, stats_file, opts.compiler_stats_range_fields)
File "/home/hvr/ghc/testsuite/driver/testlib.py", line 1136, in checkStats
val = int(m.group(1))
AttributeError: 'NoneType' object has no attribute 'group'
OVERALL SUMMARY for test run started at Wed Nov 5 08:29:10 2014 CET
0:04:14 spent to go through
4150 total tests, which gave rise to
16187 test cases, of which
16186 were skipped
0 had missing libraries
0 expected passes
0 expected failures
1 caused framework failures
0 unexpected passes
0 unexpected failures
0 unexpected stat failures
make[1]: Leaving directory '/home/hvr/ghc/testsuite/tests'
real 4m13.317s
user 3m49.476s
sys 0m5.831s
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Excessive memory usage compiling T3064","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nWith 64dc4d1085a7db375f6532362bf7e23fac3a25eb the testsuite suffers from T3064 allocating an excessive amount of memory (several GiBs) and finally getting killed due to timeout and/or out-of-memory.\r\n\r\n{{{\r\n=====> T3064(normal) 3054 of 4150 [0, 0, 0] \r\ncd ./perf/compiler && '/home/hvr/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1\r\nCompile failed (status 35072) errors were:\r\nKilled\r\n\r\nFailed to find field: peak_megabytes_allocated\r\n*** framework failure for T3064(normal) do_test exception \r\nTraceback (most recent call last):\r\n File \"/home/hvr/ghc/testsuite/driver/testlib.py\", line 793, in do_test\r\n result = func(*[name,way] + args)\r\n File \"/home/hvr/ghc/testsuite/driver/testlib.py\", line 995, in compile\r\n return do_compile( name, way, 0, '', [], extra_hc_opts )\r\n File \"/home/hvr/ghc/testsuite/driver/testlib.py\", line 1024, in do_compile\r\n result = simple_build( name, way, extra_hc_opts, should_fail, top_mod, 0, 1, force, override_flags )\r\n File \"/home/hvr/ghc/testsuite/driver/testlib.py\", line 1262, in simple_build\r\n statsResult = checkStats(name, way, stats_file, opts.compiler_stats_range_fields)\r\n File \"/home/hvr/ghc/testsuite/driver/testlib.py\", line 1136, in checkStats\r\n val = int(m.group(1))\r\nAttributeError: 'NoneType' object has no attribute 'group'\r\n\r\nOVERALL SUMMARY for test run started at Wed Nov 5 08:29:10 2014 CET\r\n 0:04:14 spent to go through\r\n 4150 total tests, which gave rise to\r\n 16187 test cases, of which\r\n 16186 were skipped\r\n\r\n 0 had missing libraries\r\n 0 expected passes\r\n 0 expected failures\r\n\r\n 1 caused framework failures\r\n 0 unexpected passes\r\n 0 unexpected failures\r\n 0 unexpected stat failures\r\n\r\nmake[1]: Leaving directory '/home/hvr/ghc/testsuite/tests'\r\n\r\nreal\t4m13.317s\r\nuser\t3m49.476s\r\nsys\t0m5.831s\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/9318Type error reported in wrong place with repeated type family expressions2019-07-07T18:40:54ZRichard Eisenbergrae@richarde.devType error reported in wrong place with repeated type family expressionsWhen I say
```
{-# LANGUAGE TypeFamilies #-}
type family F x
type instance F Int = Bool
foo :: F Int -> ()
foo True = ()
bar :: F Int -> ()
bar 'x' = ()
```
I get
```
/Users/rae/temp/Bug.hs:7:5:
Couldn't match type ‘Char’ with ...When I say
```
{-# LANGUAGE TypeFamilies #-}
type family F x
type instance F Int = Bool
foo :: F Int -> ()
foo True = ()
bar :: F Int -> ()
bar 'x' = ()
```
I get
```
/Users/rae/temp/Bug.hs:7:5:
Couldn't match type ‘Char’ with ‘Bool’
Expected type: F Int
Actual type: Bool
In the pattern: True
In an equation for ‘foo’: foo True = ()
/Users/rae/temp/Bug.hs:10:5:
Couldn't match type ‘Bool’ with ‘Char’
Expected type: F Int
Actual type: Char
In the pattern: 'x'
In an equation for ‘bar’: bar 'x' = ()
```
The second error is most certainly correct, but the first one is most certainly not. Note that the first error is reported on the definition of `foo`, which should type-check. Also, the "Couldn't match ..." bit doesn't correspond at all with the expected/actual bit. And, the expected/actual bit shows two types that are in fact equal.
This behavior can be seen in HEAD (as of Jul. 2), 7.8.3, and 7.8.2. This is a regression from 7.6.3, where this behavior does not appear.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type error reported in wrong place with repeated type family expressions","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I say\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\ntype family F x\r\ntype instance F Int = Bool\r\n\r\nfoo :: F Int -> ()\r\nfoo True = ()\r\n\r\nbar :: F Int -> ()\r\nbar 'x' = ()\r\n}}}\r\n\r\nI get\r\n\r\n{{{\r\n/Users/rae/temp/Bug.hs:7:5:\r\n Couldn't match type ‘Char’ with ‘Bool’\r\n Expected type: F Int\r\n Actual type: Bool\r\n In the pattern: True\r\n In an equation for ‘foo’: foo True = ()\r\n\r\n/Users/rae/temp/Bug.hs:10:5:\r\n Couldn't match type ‘Bool’ with ‘Char’\r\n Expected type: F Int\r\n Actual type: Char\r\n In the pattern: 'x'\r\n In an equation for ‘bar’: bar 'x' = ()\r\n}}}\r\n\r\nThe second error is most certainly correct, but the first one is most certainly not. Note that the first error is reported on the definition of `foo`, which should type-check. Also, the \"Couldn't match ...\" bit doesn't correspond at all with the expected/actual bit. And, the expected/actual bit shows two types that are in fact equal.\r\n\r\nThis behavior can be seen in HEAD (as of Jul. 2), 7.8.3, and 7.8.2. This is a regression from 7.6.3, where this behavior does not appear.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/7643Kind application error2019-07-07T18:48:52ZgmainlandKind application errorCompiling the attached program with -dcore-lint fails. This failure is a reduced version of code taken from the primitive package, version 0.5.0.1.
To see the failure:
```
ghc -dcore-lint --make Main.hs
```
The failure does not occur ...Compiling the attached program with -dcore-lint fails. This failure is a reduced version of code taken from the primitive package, version 0.5.0.1.
To see the failure:
```
ghc -dcore-lint --make Main.hs
```
The failure does not occur with GHC 7.4.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Kind application error","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling the attached program with -dcore-lint fails. This failure is a reduced version of code taken from the primitive package, version 0.5.0.1.\r\n\r\nTo see the failure:\r\n\r\n{{{\r\nghc -dcore-lint --make Main.hs\r\n}}}\r\n\r\nThe failure does not occur with GHC 7.4.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/6056INLINABLE pragma prevents worker-wrapper to happen.2022-03-23T16:32:40ZmilanINLINABLE pragma prevents worker-wrapper to happen.When working on containers I found out that a method returning a pair marked as INLINABLE does not go through a worker/wrapper transformation to get a worker that would return unboxed pair.
For example:
```
module Test where
smallerAn...When working on containers I found out that a method returning a pair marked as INLINABLE does not go through a worker/wrapper transformation to get a worker that would return unboxed pair.
For example:
```
module Test where
smallerAndRest :: Ord a => a -> [a] -> (Maybe a, [a])
smallerAndRest x [] = (Nothing, [])
smallerAndRest x (y:ys) | y < x = (Just y, ys)
| otherwise = smallerAndRest x ys
{-# INLINABLE smallerAndRest #-}
```
With the `INLINABLE` pragma, `-ddump-prep` prints
```
==================== CorePrep ====================
Result size = 42
lvl_rkg :: forall a_ajz. (Data.Maybe.Maybe a_ajz, [a_ajz])
[GblId, Caf=NoCafRefs, Str=DmdType m, Unf=OtherCon []]
lvl_rkg =
\ (@ a_ajz) -> (Data.Maybe.Nothing @ a_ajz, GHC.Types.[] @ a_ajz)
Rec {
Test.smallerAndRest [InlPrag=INLINABLE[ALWAYS], Occ=LoopBreaker]
:: forall a_a9I.
GHC.Classes.Ord a_a9I =>
a_a9I -> [a_a9I] -> (Data.Maybe.Maybe a_a9I, [a_a9I])
[GblId, Arity=3, Caf=NoCafRefs, Str=DmdType LLSm, Unf=OtherCon []]
Test.smallerAndRest =
\ (@ a_ajz)
($dOrd_sko :: GHC.Classes.Ord a_ajz)
(x_skq :: a_ajz)
(ds_skk :: [a_ajz]) ->
case ds_skk of _ {
[] -> lvl_rkg @ a_ajz;
: y_skp ys_sks ->
case GHC.Classes.< @ a_ajz $dOrd_sko y_skp x_skq of _ {
GHC.Types.False ->
Test.smallerAndRest @ a_ajz $dOrd_sko x_skq ys_sks;
GHC.Types.True ->
let {
sat_skw :: Data.Maybe.Maybe a_ajz
[LclId]
sat_skw = Data.Maybe.Just @ a_ajz y_skp } in
(sat_skw, ys_sks)
}
}
end Rec }
```
but without the `INLINABLE` pragma, we get
```
==================== CorePrep ====================
Result size = 57
Rec {
Test.$wsmallerAndRest [Occ=LoopBreaker]
:: forall a_a9I.
GHC.Classes.Ord a_a9I =>
a_a9I -> [a_a9I] -> (# Data.Maybe.Maybe a_a9I, [a_a9I] #)
[GblId, Arity=3, Caf=NoCafRefs, Str=DmdType LLS, Unf=OtherCon []]
Test.$wsmallerAndRest =
\ (@ a_a9I)
(w_skC :: GHC.Classes.Ord a_a9I)
(w1_skE :: a_a9I)
(w2_sky :: [a_a9I]) ->
case w2_sky of _ {
[] -> (# Data.Maybe.Nothing @ a_a9I, GHC.Types.[] @ a_a9I #);
: y_skD ys_skG ->
case GHC.Classes.< @ a_a9I w_skC y_skD w1_skE of _ {
GHC.Types.False ->
Test.$wsmallerAndRest @ a_a9I w_skC w1_skE ys_skG;
GHC.Types.True ->
let {
sat_skV :: Data.Maybe.Maybe a_a9I
[LclId]
sat_skV = Data.Maybe.Just @ a_a9I y_skD } in
(# sat_skV, ys_skG #)
}
}
end Rec }
Test.smallerAndRest [InlPrag=INLINE[0]]
:: forall a_a9I.
GHC.Classes.Ord a_a9I =>
a_a9I -> [a_a9I] -> (Data.Maybe.Maybe a_a9I, [a_a9I])
[GblId, Arity=3, Caf=NoCafRefs, Str=DmdType LLSm, Unf=OtherCon []]
Test.smallerAndRest =
\ (@ a_a9I)
(w_skL :: GHC.Classes.Ord a_a9I)
(w1_skM :: a_a9I)
(w2_skN :: [a_a9I]) ->
case Test.$wsmallerAndRest @ a_a9I w_skL w1_skM w2_skN
of _ { (# ww1_skR, ww2_skS #) ->
(ww1_skR, ww2_skS)
}
```
Here the worker-wrapper creates a variant, which returns unboxed pair.
I assume that there is no simple solution to this, because the worker/wrapper changes the INLINABLE on `smallerAndRest` to INLINE. The INLINABLE could be added to `$wsmallerAndRest`, but then #5928 causes the specialization to fail.
Maybe at least both `smallerAndRest` and `$wsmallerAndRest` could be marked `INLINABLE`? Then it is not sure that `smallerAndRest` gets INLINED and `$wsmallerAndRest` exposed, but it is not worse than current situation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | fox@ucw.cz |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"INLINABLE pragma prevents worker-wrapper to happen.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["fox@ucw.cz"],"type":"Bug","description":"When working on containers I found out that a method returning a pair marked as INLINABLE does not go through a worker/wrapper transformation to get a worker that would return unboxed pair.\r\n\r\nFor example:\r\n\r\n{{{\r\nmodule Test where\r\n\r\nsmallerAndRest :: Ord a => a -> [a] -> (Maybe a, [a])\r\nsmallerAndRest x [] = (Nothing, [])\r\nsmallerAndRest x (y:ys) | y < x = (Just y, ys)\r\n | otherwise = smallerAndRest x ys\r\n\r\n{-# INLINABLE smallerAndRest #-}\r\n}}}\r\n\r\nWith the `INLINABLE` pragma, `-ddump-prep` prints\r\n{{{\r\n==================== CorePrep ====================\r\nResult size = 42\r\n\r\nlvl_rkg :: forall a_ajz. (Data.Maybe.Maybe a_ajz, [a_ajz])\r\n[GblId, Caf=NoCafRefs, Str=DmdType m, Unf=OtherCon []]\r\nlvl_rkg =\r\n \\ (@ a_ajz) -> (Data.Maybe.Nothing @ a_ajz, GHC.Types.[] @ a_ajz)\r\n\r\nRec {\r\nTest.smallerAndRest [InlPrag=INLINABLE[ALWAYS], Occ=LoopBreaker]\r\n :: forall a_a9I.\r\n GHC.Classes.Ord a_a9I =>\r\n a_a9I -> [a_a9I] -> (Data.Maybe.Maybe a_a9I, [a_a9I])\r\n[GblId, Arity=3, Caf=NoCafRefs, Str=DmdType LLSm, Unf=OtherCon []]\r\nTest.smallerAndRest =\r\n \\ (@ a_ajz)\r\n ($dOrd_sko :: GHC.Classes.Ord a_ajz)\r\n (x_skq :: a_ajz)\r\n (ds_skk :: [a_ajz]) ->\r\n case ds_skk of _ {\r\n [] -> lvl_rkg @ a_ajz;\r\n : y_skp ys_sks ->\r\n case GHC.Classes.< @ a_ajz $dOrd_sko y_skp x_skq of _ {\r\n GHC.Types.False ->\r\n Test.smallerAndRest @ a_ajz $dOrd_sko x_skq ys_sks;\r\n GHC.Types.True ->\r\n let {\r\n sat_skw :: Data.Maybe.Maybe a_ajz\r\n [LclId]\r\n sat_skw = Data.Maybe.Just @ a_ajz y_skp } in\r\n (sat_skw, ys_sks)\r\n }\r\n }\r\nend Rec }\r\n}}}\r\n\r\nbut without the `INLINABLE` pragma, we get\r\n{{{\r\n==================== CorePrep ====================\r\nResult size = 57\r\n\r\nRec {\r\nTest.$wsmallerAndRest [Occ=LoopBreaker]\r\n :: forall a_a9I.\r\n GHC.Classes.Ord a_a9I =>\r\n a_a9I -> [a_a9I] -> (# Data.Maybe.Maybe a_a9I, [a_a9I] #)\r\n[GblId, Arity=3, Caf=NoCafRefs, Str=DmdType LLS, Unf=OtherCon []]\r\nTest.$wsmallerAndRest =\r\n \\ (@ a_a9I)\r\n (w_skC :: GHC.Classes.Ord a_a9I)\r\n (w1_skE :: a_a9I)\r\n (w2_sky :: [a_a9I]) ->\r\n case w2_sky of _ {\r\n [] -> (# Data.Maybe.Nothing @ a_a9I, GHC.Types.[] @ a_a9I #);\r\n : y_skD ys_skG ->\r\n case GHC.Classes.< @ a_a9I w_skC y_skD w1_skE of _ {\r\n GHC.Types.False ->\r\n Test.$wsmallerAndRest @ a_a9I w_skC w1_skE ys_skG;\r\n GHC.Types.True ->\r\n let {\r\n sat_skV :: Data.Maybe.Maybe a_a9I\r\n [LclId]\r\n sat_skV = Data.Maybe.Just @ a_a9I y_skD } in\r\n (# sat_skV, ys_skG #)\r\n }\r\n }\r\nend Rec }\r\n\r\nTest.smallerAndRest [InlPrag=INLINE[0]]\r\n :: forall a_a9I.\r\n GHC.Classes.Ord a_a9I =>\r\n a_a9I -> [a_a9I] -> (Data.Maybe.Maybe a_a9I, [a_a9I])\r\n[GblId, Arity=3, Caf=NoCafRefs, Str=DmdType LLSm, Unf=OtherCon []]\r\nTest.smallerAndRest =\r\n \\ (@ a_a9I)\r\n (w_skL :: GHC.Classes.Ord a_a9I)\r\n (w1_skM :: a_a9I)\r\n (w2_skN :: [a_a9I]) ->\r\n case Test.$wsmallerAndRest @ a_a9I w_skL w1_skM w2_skN\r\n of _ { (# ww1_skR, ww2_skS #) ->\r\n (ww1_skR, ww2_skS)\r\n }\r\n}}}\r\nHere the worker-wrapper creates a variant, which returns unboxed pair.\r\n\r\n\r\nI assume that there is no simple solution to this, because the worker/wrapper changes the INLINABLE on `smallerAndRest` to INLINE. The INLINABLE could be added to `$wsmallerAndRest`, but then #5928 causes the specialization to fail.\r\n\r\nMaybe at least both `smallerAndRest` and `$wsmallerAndRest` could be marked `INLINABLE`? Then it is not sure that `smallerAndRest` gets INLINED and `$wsmallerAndRest` exposed, but it is not worse than current situation.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/6022GHC infers over-general types2019-07-07T18:52:31ZSimon Peyton JonesGHC infers over-general typesConsider
```
f x = x + head
```
GHC will (with no flags) will compile this almost-certainly-wrong program, giving `f` the type
```
f :: forall a. Num ([a] -> a) => ([a] -> a) -> [a] -> a
```
There's nothing wrong with that type, ...Consider
```
f x = x + head
```
GHC will (with no flags) will compile this almost-certainly-wrong program, giving `f` the type
```
f :: forall a. Num ([a] -> a) => ([a] -> a) -> [a] -> a
```
There's nothing wrong with that type, and in principle someone might later define a suitable instance of `Num`, but (a) it's not Haskell 98, and (b) it's unlikely to be right, so we've deferred a type error from the definition site of `f` to the (perhaps much later) call site.
I think GHC should complain, and require a type signature if that's what you really want. This came up on [Stackoverflow](http://stackoverflow.com/questions/10091874/haskell-why-is-there-no-type-mismatch-and-why-does-this-compile)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC infers over-general types","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider\r\n{{{\r\nf x = x + head\r\n}}}\r\nGHC will (with no flags) will compile this almost-certainly-wrong program, giving `f` the type\r\n{{{\r\n f :: forall a. Num ([a] -> a) => ([a] -> a) -> [a] -> a\r\n}}}\r\nThere's nothing wrong with that type, and in principle someone might later define a suitable instance of `Num`, but (a) it's not Haskell 98, and (b) it's unlikely to be right, so we've deferred a type error from the definition site of `f` to the (perhaps much later) call site.\r\n\r\nI think GHC should complain, and require a type signature if that's what you really want. This came up on [http://stackoverflow.com/questions/10091874/haskell-why-is-there-no-type-mismatch-and-why-does-this-compile Stackoverflow]","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5763Confusing error message2019-07-07T18:53:42ZSimon Peyton JonesConfusing error messageFor test `indexed-types/should_fail/T4272` we get this type error
```
T4272.hs:11:16:
Occurs check: cannot construct the infinite type:
x0 = TermFamily x0 x0
Expected type: TermFamily x0 x0
Actual type: TermFamily a ...For test `indexed-types/should_fail/T4272` we get this type error
```
T4272.hs:11:16:
Occurs check: cannot construct the infinite type:
x0 = TermFamily x0 x0
Expected type: TermFamily x0 x0
Actual type: TermFamily a a
In the first argument of `prune', namely `t'
In the expression: prune t (terms (undefined :: TermFamily a a))
In an equation for `laws':
laws t = prune t (terms (undefined :: TermFamily a a))
```
It's not at all obvious why unifying `(TermFamily x0 x0)` with `(TermFamily a a)` should yield an occurs check. Especially as `TermFamily` is a type function with arity 1, and `x0` is a unification variable. So the natural way to solve this constraint would be to unify `x0` with `a`, and then the constraint is satisfied.
What goes wrong is that there is *another* insolube constraint (which is also reported):
```
T4272.hs:11:19:
Could not deduce (a ~ TermFamily x0 x0)
from the context (TermLike a)
bound by the type signature for
laws :: TermLike a => TermFamily a a -> b
at T4272.hs:11:1-54
`a' is a rigid type variable bound by
the type signature for laws :: TermLike a => TermFamily a a -> b
at T4272.hs:11:1
In the return type of a call of `terms'
In the second argument of `prune', namely
`(terms (undefined :: TermFamily a a))'
In the expression: prune t (terms (undefined :: TermFamily a a))
```
The constraint solver finds this latter constraint, can't solve it, *but still uses it to simplify the first one*, by substituting `(TermFamily x0 x0)` for `a`; and that is what gives the occurs check error.
I don't think that we should use *insoluble* constraints to rewrite unsolved constraints. But it's delicate, so I am not trying to fiddle right now. Hence making this ticket.
(Incidentally, it's not a regression; it's been like this forever.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------- |
| Version | 7.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | indexed-types/should_fail/T4272 |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | dimitris@microsoft.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Confusing error message","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.2","keywords":[],"differentials":[],"test_case":"indexed-types/should_fail/T4272","architecture":"","cc":["dimitris@microsoft.com"],"type":"Bug","description":"For test `indexed-types/should_fail/T4272` we get this type error\r\n{{{\r\nT4272.hs:11:16:\r\n Occurs check: cannot construct the infinite type:\r\n x0 = TermFamily x0 x0\r\n Expected type: TermFamily x0 x0\r\n Actual type: TermFamily a a\r\n In the first argument of `prune', namely `t'\r\n In the expression: prune t (terms (undefined :: TermFamily a a))\r\n In an equation for `laws':\r\n laws t = prune t (terms (undefined :: TermFamily a a))\r\n}}}\r\nIt's not at all obvious why unifying `(TermFamily x0 x0)` with `(TermFamily a a)` should yield an occurs check. Especially as `TermFamily` is a type function with arity 1, and `x0` is a unification variable. So the natural way to solve this constraint would be to unify `x0` with `a`, and then the constraint is satisfied.\r\n\r\nWhat goes wrong is that there is ''another'' insolube constraint (which is also reported):\r\n{{{\r\nT4272.hs:11:19:\r\n Could not deduce (a ~ TermFamily x0 x0)\r\n from the context (TermLike a)\r\n bound by the type signature for\r\n laws :: TermLike a => TermFamily a a -> b\r\n at T4272.hs:11:1-54\r\n `a' is a rigid type variable bound by\r\n the type signature for laws :: TermLike a => TermFamily a a -> b\r\n at T4272.hs:11:1\r\n In the return type of a call of `terms'\r\n In the second argument of `prune', namely\r\n `(terms (undefined :: TermFamily a a))'\r\n In the expression: prune t (terms (undefined :: TermFamily a a))\r\n}}}\r\nThe constraint solver finds this latter constraint, can't solve it, ''but still uses it to simplify the first one'', by substituting `(TermFamily x0 x0)` for `a`; and that is what gives the occurs check error.\r\n\r\nI don't think that we should use ''insoluble'' constraints to rewrite unsolved constraints. But it's delicate, so I am not trying to fiddle right now. Hence making this ticket.\r\n\r\n(Incidentally, it's not a regression; it's been like this forever.)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Simon Peyton JonesSimon Peyton Jones