GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-11-29T09:13:46Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/14103Retypechecking the loop in --make mode is super-linear when there are many .h...2021-11-29T09:13:46ZDouglas Wilsondouglas@well-typed.comRetypechecking the loop in --make mode is super-linear when there are many .hs-boot modulesAt time of writing master is at commit 14457cf6a50f708eecece8f286f08687791d51f7.
In GhcMake.hs, both upsweep and parUpsweep call getModLoop for each module. getModLoop is (at least) linear when called on a .hs-boot ModSummary. See comme...At time of writing master is at commit 14457cf6a50f708eecece8f286f08687791d51f7.
In GhcMake.hs, both upsweep and parUpsweep call getModLoop for each module. getModLoop is (at least) linear when called on a .hs-boot ModSummary. See comments in Phab:3646.
This isn't a big deal in practice, since .hs-boot modules are uncommon, but it does irk me, and it will be easy to fix. Fixing this would also be an opportunity to de-duplicate some logic in upsweep and parUpsweep.
ccing niteria as he has worked with this code recently.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | niteria |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":["hs-boot"],"differentials":[],"test_case":"","architecture":"","cc":["niteria"],"type":"Bug","description":"At time of writing master is at commit 14457cf6a50f708eecece8f286f08687791d51f7.\r\n\r\nIn GhcMake.hs, both upsweep and parUpsweep call getModLoop for each module. getModLoop is (at least) linear when called on a .hs-boot ModSummary. See comments in Phab:3646.\r\n\r\nThis isn't a big deal in practice, since .hs-boot modules are uncommon, but it does irk me, and it will be easy to fix. Fixing this would also be an opportunity to de-duplicate some logic in upsweep and parUpsweep.\r\n\r\nccing niteria as he has worked with this code recently. ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16136Broken link to GHC-Prim.html#chr%232021-11-28T14:55:14ZMikolaj KonarskiBroken link to GHC-Prim.html#chr%23When on page
http://downloads.haskell.org/\~ghc/latest/docs/html/libraries/base-4.12.0.0/GHC-Exts.html\#v:chr-35-
you click on Source of chr\#, you get "404 Not Found" at this address
http://downloads.haskell.org/\~ghc/latest/docs/htm...When on page
http://downloads.haskell.org/\~ghc/latest/docs/html/libraries/base-4.12.0.0/GHC-Exts.html\#v:chr-35-
you click on Source of chr\#, you get "404 Not Found" at this address
http://downloads.haskell.org/\~ghc/latest/docs/html/libraries/ghc-prim-0.5.3/src/GHC-Prim.html\#chr%23
It works fine for
https://hackage.haskell.org/package/ghc-prim-0.5.3/docs/src/GHC.Prim.html\#chr%23
so I think it's GHC's problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Broken link to GHC-Prim.html#chr%23","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When on page \r\n\r\nhttp://downloads.haskell.org/~ghc/latest/docs/html/libraries/base-4.12.0.0/GHC-Exts.html#v:chr-35-\r\n\r\nyou click on Source of chr#, you get \"404 Not Found\" at this address\r\n\r\nhttp://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-prim-0.5.3/src/GHC-Prim.html#chr%23\r\n\r\nIt works fine for \r\n\r\nhttps://hackage.haskell.org/package/ghc-prim-0.5.3/docs/src/GHC.Prim.html#chr%23\r\n\r\nso I think it's GHC's problem.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9421Problems and workarounds when installing and using a 32bit GHC on 64bit Linux...2021-11-28T14:50:47ZMikolaj KonarskiProblems and workarounds when installing and using a 32bit GHC on 64bit Linux machineI'm compiling i386 binaries on amd64 linux and reporting problems and workarounds in this meta ticket.
The very first problem I encounter is a magic number mismatch message.
This is basically the same problem as reported here:
https://...I'm compiling i386 binaries on amd64 linux and reporting problems and workarounds in this meta ticket.
The very first problem I encounter is a magic number mismatch message.
This is basically the same problem as reported here:
https://www.mail-archive.com/ghc-devs\@haskell.org/msg04439.html
I have empty .cabal and .ghc, no ghc in paths and I have old Ubuntu LTS (12.04.4) so I was able to install ia32-libs and a few other libs
I've downloaded
http://www.haskell.org/ghc/dist/7.8.3/ghc-7.8.3-i386-unknown-linux-deb7.tar.xz
configured, and make install says:
```
Installing library in
/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell98-2.0.0.3
"utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/haskell2010 dist-install "strip" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' 'v p dyn'
Installing library in
/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/haskell2010-1.1.2.0
"/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" --force --global-package-db "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/package.conf.d" update rts/dist/package.conf.install
Reading package info from "rts/dist/package.conf.install" ... done.
"utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register libraries/ghc-prim dist-install "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc" "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3/bin/ghc-pkg" "/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3" '' '/mikolaj/env/7.8.3i386/local/src/ghc' '/mikolaj/env/7.8.3i386/local/src/ghc/lib/ghc-7.8.3' '/mikolaj/env/7.8.3i386/local/src/ghc/share/doc/ghc/html/libraries' NO
ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi
magic number mismatch: old/corrupt interface file? (wanted 33214052, got
129742)
make[1]: *** [install_packages] Error 1
make: *** [install] Error 2
```Mikolaj KonarskiMikolaj Konarskihttps://gitlab.haskell.org/ghc/ghc/-/issues/15603ref6 example from StaticPointers documentation doesn't type check2021-11-25T17:04:14ZMatthew Pickeringref6 example from StaticPointers documentation doesn't type checkThe [documentation](https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/glasgow_exts.html?highlight=static%20pointers#extension-StaticPointers) for `StaticPointers` contains the following example.
```
ref6 y = let x = 1 in st...The [documentation](https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/glasgow_exts.html?highlight=static%20pointers#extension-StaticPointers) for `StaticPointers` contains the following example.
```
ref6 y = let x = 1 in static x
```
but this doesn't get accepted by the type checker.
```
sp.hs:27:23: error:
• ‘x’ is used in a static form but it is not closed because it
has a non-closed type because it contains the
type variables: ‘p_a7KP’
• In the expression: static x
In the expression: let x = 1 in static x
In an equation for ‘ref6’: ref6 y = let x = 1 in static x
|
27 | ref6 y = let x = 1 in static x
| ^^^^^^^
```
I tested on 8.6.1, 8.4.3, 8.2.2, 8.02, 7.10.3 and all fail.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ref6 example from StaticPointers documentation doesn't type check","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The [https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/glasgow_exts.html?highlight=static%20pointers#extension-StaticPointers documentation] for `StaticPointers` contains the following example.\r\n\r\n{{{\r\nref6 y = let x = 1 in static x\r\n}}}\r\n\r\nbut this doesn't get accepted by the type checker.\r\n\r\n{{{\r\nsp.hs:27:23: error:\r\n • ‘x’ is used in a static form but it is not closed because it\r\n has a non-closed type because it contains the\r\n type variables: ‘p_a7KP’\r\n • In the expression: static x\r\n In the expression: let x = 1 in static x\r\n In an equation for ‘ref6’: ref6 y = let x = 1 in static x\r\n |\r\n27 | ref6 y = let x = 1 in static x\r\n | ^^^^^^^\r\n}}}\r\n\r\nI tested on 8.6.1, 8.4.3, 8.2.2, 8.02, 7.10.3 and all fail. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/6084Add stg_ap_pnnv and related call patterns2021-11-25T10:02:05ZSimonMeierAdd stg_ap_pnnv and related call patternsIn the implementation of bytestring encoding and decoding libraries, the call patterns stg_ap_pnnv and stg_ap_nnv occur very often. These call patterns are required to avoid boxing the pointers denoting the start and end of the memory ar...In the implementation of bytestring encoding and decoding libraries, the call patterns stg_ap_pnnv and stg_ap_nnv occur very often. These call patterns are required to avoid boxing the pointers denoting the start and end of the memory area to write to/read from. The first 'p' often stems from using continuation passing style or from a record of configuration paramters. For example, the type of a bytestring builder looks about as follows.
```
newtype Builder = Builder ((Addr# -> Addr# -> IO BuildSignal) -> Addr# -> Addr# -> IO BuildSignal)
```
The first Addr\# is the pointer to the next free byte and the second Addr\# is the pointer to the first byte after the buffer being filled. The current implementation of the bytestring builder in the bytestring-0.10. library however uses
```
newtype Builder = Builder ((Ptr Word8 -> Ptr Word8 -> IO BuildSignal) -> Ptr Word8 -> Ptr Word8 -> IO BuildSignal)
```
as the benchmarks demonstrated that the repeated boxing is cheaper than the unknown calls implemented through a series of stg_ap_p, stg_ap_n, stg_ap_n, stg_ap_v calls.
I therefore suggest adding the following call patterns
ppnnv, pnnv, nnv, and nv.
to allow more efficient implementations of bytestring and text decoding/encoding. Note that the 'ppnnv' is used for a constant environment, a continuation, and a range resulting in a side-effecting function.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add stg_ap_pnnv and related call patterns","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"In the implementation of bytestring encoding and decoding libraries, the call patterns stg_ap_pnnv and stg_ap_nnv occur very often. These call patterns are required to avoid boxing the pointers denoting the start and end of the memory area to write to/read from. The first 'p' often stems from using continuation passing style or from a record of configuration paramters. For example, the type of a bytestring builder looks about as follows.\r\n\r\n{{{\r\nnewtype Builder = Builder ((Addr# -> Addr# -> IO BuildSignal) -> Addr# -> Addr# -> IO BuildSignal)\r\n}}}\r\n\r\nThe first Addr# is the pointer to the next free byte and the second Addr# is the pointer to the first byte after the buffer being filled. The current implementation of the bytestring builder in the bytestring-0.10. library however uses\r\n\r\n{{{\r\nnewtype Builder = Builder ((Ptr Word8 -> Ptr Word8 -> IO BuildSignal) -> Ptr Word8 -> Ptr Word8 -> IO BuildSignal)\r\n}}}\r\n\r\nas the benchmarks demonstrated that the repeated boxing is cheaper than the unknown calls implemented through a series of stg_ap_p, stg_ap_n, stg_ap_n, stg_ap_v calls.\r\n\r\nI therefore suggest adding the following call patterns\r\n\r\nppnnv, pnnv, nnv, and nv.\r\n\r\nto allow more efficient implementations of bytestring and text decoding/encoding. Note that the 'ppnnv' is used for a constant environment, a continuation, and a range resulting in a side-effecting function.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/15247Use empty types for TTG extension constructors2021-11-22T14:29:38ZAdam GundryUse empty types for TTG extension constructorsI happened to be looking at `AmbiguousFieldOcc` and noticed that it has gained an `XAmbiguousFieldOcc` extension constructor for Trees That Grow, but lots of the destructor functions in `HsTypes` panic if they see this constructor (which...I happened to be looking at `AmbiguousFieldOcc` and noticed that it has gained an `XAmbiguousFieldOcc` extension constructor for Trees That Grow, but lots of the destructor functions in `HsTypes` panic if they see this constructor (which is understandable, because they aren't expecting extensions).
In general, perhaps it should be the case that for concrete phase descriptors (e.g. `GhcRn`) where extension constructors are not expected, the extension constructor argument type should be empty? It would then be clear that they should not be expected (barring abuse of laziness) and pattern matching on them could eliminate the empty type.
That is, instead of the existing
```hs
data NoExt = NoExt
type instance XXAmbiguousFieldOcc (GhcPass _) = NoExt
```
we would define
```hs
data NoExtConstructor -- empty data type
noExtConstructor :: NoExtConstructor -> a
noExtConstructor x = case x of {}
type instance XXAmbiguousFieldOcc (GhcPass _) = NoExtConstructor
```
and similarly for other `XX...` type families.
Alan, Shayan, is there any reason this couldn't work?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.5 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Shayan-Najd, alanz |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Use empty types for TTG extension constructors","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["TTG"],"differentials":[],"test_case":"","architecture":"","cc":["Shayan-Najd","alanz"],"type":"Task","description":"I happened to be looking at `AmbiguousFieldOcc` and noticed that it has gained an `XAmbiguousFieldOcc` extension constructor for Trees That Grow, but lots of the destructor functions in `HsTypes` panic if they see this constructor (which is understandable, because they aren't expecting extensions).\r\n\r\nIn general, perhaps it should be the case that for concrete phase descriptors (e.g. `GhcRn`) where extension constructors are not expected, the extension constructor argument type should be empty? It would then be clear that they should not be expected (barring abuse of laziness) and pattern matching on them could eliminate the empty type.\r\n\r\nThat is, instead of the existing\r\n{{{#!hs\r\ndata NoExt = NoExt\r\n\r\ntype instance XXAmbiguousFieldOcc (GhcPass _) = NoExt\r\n}}}\r\nwe would define\r\n{{{#!hs\r\ndata NoExtConstructor -- empty data type\r\n\r\nnoExtConstructor :: NoExtConstructor -> a\r\nnoExtConstructor x = case x of {}\r\n\r\ntype instance XXAmbiguousFieldOcc (GhcPass _) = NoExtConstructor\r\n}}}\r\nand similarly for other `XX...` type families.\r\n\r\nAlan, Shayan, is there any reason this couldn't work?","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/21Can't split a string literal2021-11-22T14:14:55ZnobodyCan't split a string literal```
If I try to split a string literal across two lines,
using the syntax of two \ seperated by white space, I
get the error mesage:
error in character literal
The code lines in question looks like:
hPutStr h $
"GET "++pat...```
If I try to split a string literal across two lines,
using the syntax of two \ seperated by white space, I
get the error mesage:
error in character literal
The code lines in question looks like:
hPutStr h $
"GET "++path uri++" HTTP/1.1\r\n\
\Host: "++authority uri++"\r\n\
\User-Agent: Haber/0.2\r\n\r\n"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 5.02 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | ResolvedNoReason |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Can't split a string literal","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"ResolvedNoReason","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"5.02","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nIf I try to split a string literal across two lines,\nusing the syntax of two \\ seperated by white space, I \nget the error mesage:\nerror in character literal\n\nThe code lines in question looks like:\n\n hPutStr h $\n \"GET \"++path uri++\" HTTP/1.1\\r\\n\\\n \\Host: \"++authority uri++\"\\r\\n\\\n \\User-Agent: Haber/0.2\\r\\n\\r\\n\"\n\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/15073Unable to newtype derive `Prim` via DerivingStrategies2021-11-21T14:46:00ZfosskersUnable to newtype derive `Prim` via DerivingStrategiesThe following compiles with both GHC 8.2.2 and 8.4.1:
```hs
newtype Drain = Drain { _drain :: Word8 }
deriving stock (Eq, Ord, Show, Generic)
deriving newtype (Storable)
deriving anyclass (NFData)
```
However, adding `Prim` b...The following compiles with both GHC 8.2.2 and 8.4.1:
```hs
newtype Drain = Drain { _drain :: Word8 }
deriving stock (Eq, Ord, Show, Generic)
deriving newtype (Storable)
deriving anyclass (NFData)
```
However, adding `Prim` beside `Storable` in the `newtype` area yields the following with GHC 8.2.2:
```
/home/colin/code/haskell/mapalgebra/lib/Geography/MapAlgebra.hs:1148:21-24: error:
• Illegal unboxed tuple type as function argument:
(# ghc-prim-0.5.1.1:GHC.Prim.State# s1, Word8 #)
• In the expression:
ghc-prim-0.5.1.1:GHC.Prim.coerce
@(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep).
ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s
-> ghc-prim-0.5.1.1:GHC.Prim.Int#
-> ghc-prim-0.5.1.1:GHC.Prim.State# s
-> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Word8)
@(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep).
ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s
-> ghc-prim-0.5.1.1:GHC.Prim.Int#
-> ghc-prim-0.5.1.1:GHC.Prim.State# s
-> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Drain)
primitive-0.6.3.0:Data.Primitive.Types.readByteArray#
In an equation for ‘primitive-0.6.3.0:Data.Primitive.Types.readByteArray#’:
primitive-0.6.3.0:Data.Primitive.Types.readByteArray#
= ghc-prim-0.5.1.1:GHC.Prim.coerce
@(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep).
ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s
-> ghc-prim-0.5.1.1:GHC.Prim.Int#
-> ghc-prim-0.5.1.1:GHC.Prim.State# s
-> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Word8)
@(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep).
ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s
-> ghc-prim-0.5.1.1:GHC.Prim.Int#
-> ghc-prim-0.5.1.1:GHC.Prim.State# s
-> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Drain)
```
and this with GHC 8.4.1:
```
Illegal kind: ((:) (ghc-prim-0.5.2.0:GHC.Types.TupleRep ([] :: [] ghc-prim-0.5.2.0:GHC.Types.RuntimeR
ep)) ((:) ghc-prim-0.5.2.0:GHC.Types.LiftedRep ([] :: [] ghc-prim-0.5.2.0:GHC.Types.RuntimeRep) :: []
ghc-prim-0.5.2.0:GHC.Types.RuntimeRep) :: [] ghc-prim-0.5.2.0:GHC.Types.RuntimeRep)
Did you mean to enable TypeInType?
|
1132 | deriving newtype (Storable, Prim)
|
```
Turning on `TypeInType` as it suggests gives the same `Illegal unboxed tuple...` error.
I've hand-written `Storable` instances before so I'm confident in its derivation, but I otherwise know nothing about `Prim`. Is there something magical about it that prevents it from being newtype derived in the same way?
Thank you kindly,
Colin
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unable to newtype derive `Prim` via DerivingStrategies","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following compiles with both GHC 8.2.2 and 8.4.1:\r\n\r\n{{{#!hs\r\nnewtype Drain = Drain { _drain :: Word8 }\r\n deriving stock (Eq, Ord, Show, Generic)\r\n deriving newtype (Storable)\r\n deriving anyclass (NFData)\r\n}}}\r\n\r\nHowever, adding `Prim` beside `Storable` in the `newtype` area yields the following with GHC 8.2.2:\r\n\r\n{{{\r\n/home/colin/code/haskell/mapalgebra/lib/Geography/MapAlgebra.hs:1148:21-24: error:\r\n • Illegal unboxed tuple type as function argument:\r\n (# ghc-prim-0.5.1.1:GHC.Prim.State# s1, Word8 #)\r\n • In the expression:\r\n ghc-prim-0.5.1.1:GHC.Prim.coerce\r\n @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep).\r\n ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s\r\n -> ghc-prim-0.5.1.1:GHC.Prim.Int#\r\n -> ghc-prim-0.5.1.1:GHC.Prim.State# s\r\n -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Word8)\r\n @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep).\r\n ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s\r\n -> ghc-prim-0.5.1.1:GHC.Prim.Int#\r\n -> ghc-prim-0.5.1.1:GHC.Prim.State# s\r\n -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Drain)\r\n primitive-0.6.3.0:Data.Primitive.Types.readByteArray#\r\n In an equation for ‘primitive-0.6.3.0:Data.Primitive.Types.readByteArray#’:\r\n primitive-0.6.3.0:Data.Primitive.Types.readByteArray#\r\n = ghc-prim-0.5.1.1:GHC.Prim.coerce\r\n @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep).\r\n ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s\r\n -> ghc-prim-0.5.1.1:GHC.Prim.Int#\r\n -> ghc-prim-0.5.1.1:GHC.Prim.State# s\r\n -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Word8)\r\n @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep).\r\n ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s\r\n -> ghc-prim-0.5.1.1:GHC.Prim.Int#\r\n -> ghc-prim-0.5.1.1:GHC.Prim.State# s\r\n -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Drain)\r\n}}}\r\n\r\nand this with GHC 8.4.1:\r\n\r\n{{{\r\n Illegal kind: ((:) (ghc-prim-0.5.2.0:GHC.Types.TupleRep ([] :: [] ghc-prim-0.5.2.0:GHC.Types.RuntimeR\r\nep)) ((:) ghc-prim-0.5.2.0:GHC.Types.LiftedRep ([] :: [] ghc-prim-0.5.2.0:GHC.Types.RuntimeRep) :: [] \r\nghc-prim-0.5.2.0:GHC.Types.RuntimeRep) :: [] ghc-prim-0.5.2.0:GHC.Types.RuntimeRep)\r\n Did you mean to enable TypeInType?\r\n |\r\n1132 | deriving newtype (Storable, Prim)\r\n | \r\n}}}\r\nTurning on `TypeInType` as it suggests gives the same `Illegal unboxed tuple...` error.\r\n\r\nI've hand-written `Storable` instances before so I'm confident in its derivation, but I otherwise know nothing about `Prim`. Is there something magical about it that prevents it from being newtype derived in the same way?\r\n\r\nThank you kindly,\r\n\r\nColin","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14564CAF isn't floated2021-11-19T15:23:56ZNeil Mayhewneil@mayhew.nameCAF isn't floatedIn the following code, `pattern` isn't floated, and the execution time is 20x slower than it should be:
```hs
import Text.Regex.TDFA (Regex, makeRegex, match)
main :: IO ()
main = do
entries <- map parseFilename . lines <$> getCont...In the following code, `pattern` isn't floated, and the execution time is 20x slower than it should be:
```hs
import Text.Regex.TDFA (Regex, makeRegex, match)
main :: IO ()
main = do
entries <- map parseFilename . lines <$> getContents
let check (Right (_, t)) = last t == 'Z'
check _ = False
print $ all check entries
parseFilename :: String -> Either String (String, String)
parseFilename fn = case (pattern `match` fn :: [[String]]) of
[[_, full, _, time]] -> Right $ (full, time)
_ -> Left fn
where
pattern :: Regex
pattern = makeRegex
"^\\./duplicity-(full|inc|new)(-signatures)?\\.\
\([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]T[0-9][0-9][0-9][0-9][0-9][0-9]Z)\\."
```
Curiously, it is floated when profiling is enabled, so the profiled program ends up being 7x faster than the unprofiled one.
I can float the code manually (by taking out `where` and unindenting) and the program then runs at an acceptable speed.
I get the same behaviour with 8.0.2, 8.2.1 and 8.2.2 but 7.10.3 is OK. I don't think the OS and architecture makes a difference, but for the record I'm on various flavours of 64-bit Linux.
Test input data is [here](https://gist.github.com/neilmayhew/247a30738c0e294902e7c2830ca2c6f5)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"CAF isn't floated","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the following code, `pattern` isn't floated, and the execution time is 20x slower than it should be:\r\n\r\n{{{#!hs\r\nimport Text.Regex.TDFA (Regex, makeRegex, match)\r\n\r\nmain :: IO ()\r\nmain = do\r\n entries <- map parseFilename . lines <$> getContents\r\n let check (Right (_, t)) = last t == 'Z'\r\n check _ = False\r\n print $ all check entries\r\n\r\nparseFilename :: String -> Either String (String, String)\r\nparseFilename fn = case (pattern `match` fn :: [[String]]) of\r\n [[_, full, _, time]] -> Right $ (full, time)\r\n _ -> Left fn\r\n where\r\n pattern :: Regex\r\n pattern = makeRegex\r\n \"^\\\\./duplicity-(full|inc|new)(-signatures)?\\\\.\\\r\n \\([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]T[0-9][0-9][0-9][0-9][0-9][0-9]Z)\\\\.\"\r\n}}}\r\n\r\nCuriously, it is floated when profiling is enabled, so the profiled program ends up being 7x faster than the unprofiled one.\r\n\r\nI can float the code manually (by taking out `where` and unindenting) and the program then runs at an acceptable speed.\r\n\r\nI get the same behaviour with 8.0.2, 8.2.1 and 8.2.2 but 7.10.3 is OK. I don't think the OS and architecture makes a difference, but for the record I'm on various flavours of 64-bit Linux.\r\n\r\nTest input data is [https://gist.github.com/neilmayhew/247a30738c0e294902e7c2830ca2c6f5 here]","type_of_failure":"OtherFailure","blocking":[]} -->Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/7478setSessionDynFlags does not always work2021-11-19T13:58:45Zedsko@edsko.netsetSessionDynFlags does not always workThe attached test case runs GHC in a separate thread (with a single call to `runGhc` when the thread is started), waiting for compile requests on one channel and outputting "done" on another. Requests consist of a list of filenames to co...The attached test case runs GHC in a separate thread (with a single call to `runGhc` when the thread is started), waiting for compile requests on one channel and outputting "done" on another. Requests consist of a list of filenames to compile. These file names are added as targets and then `load LoadAddTargets` is called.
On every request we also call `setSessionDynFlags` with a different `log_action`. On the first request the `log_action` is set to `dispatcher 0` (defined in `forkGhc`), on the second request the `log_action` is set to `dispatcher 1`, and so on. This dispatcher just outputs the messages it receives from GHC, along with this integer; hence, all messages from the first request should include the integer 0, all messages from the second request should include the integer 1, and so on. However, when the program is run (in a directory containing all the specified source files), the output is
```
----- 0 ------
(0,"[1 of 2] Compiling B ( B.hs, B.o )")
(0,"[2 of 2] Compiling Main ( A.hs, A.o )")
----- 1 ------
(0,"[2 of 2] Compiling Main ( A.hs, A.o )")
----- 2 ------
(2,"[1 of 1] Compiling Main ( C.hs, C.o )")
(2,"Linking A ...")
```
On the first request we ask Ghc to compile A.hs and B.hs; A.hs here depends on B.hs, which is compiled first, but A.hs contains an error and cannot be compiled. Then on the second request we ask GHC to compile A.hs and B.hs again; since B.hs is already compiled it only tries to compile A.hs, but this still fails. On the third request we ask Ghc to compile C.hs, an independent source file.
Note that the integer listed for the second request is *0*, not *1*. For some reason the `setSessionDynFlags` does not seem to affect the recompilation of A.hs, even though when we compile C.hs in the third request, the output is *2*, as expected.
(This bug also occurs in GHC 7.4, but the API is slightly different so some minor modifications to to the code need to be made.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"setSessionDynFlags does not always work","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached test case runs GHC in a separate thread (with a single call to `runGhc` when the thread is started), waiting for compile requests on one channel and outputting \"done\" on another. Requests consist of a list of filenames to compile. These file names are added as targets and then `load LoadAddTargets` is called. \r\n\r\nOn every request we also call `setSessionDynFlags` with a different `log_action`. On the first request the `log_action` is set to `dispatcher 0` (defined in `forkGhc`), on the second request the `log_action` is set to `dispatcher 1`, and so on. This dispatcher just outputs the messages it receives from GHC, along with this integer; hence, all messages from the first request should include the integer 0, all messages from the second request should include the integer 1, and so on. However, when the program is run (in a directory containing all the specified source files), the output is\r\n\r\n{{{\r\n----- 0 ------\r\n(0,\"[1 of 2] Compiling B ( B.hs, B.o )\")\r\n(0,\"[2 of 2] Compiling Main ( A.hs, A.o )\")\r\n----- 1 ------\r\n(0,\"[2 of 2] Compiling Main ( A.hs, A.o )\")\r\n----- 2 ------\r\n(2,\"[1 of 1] Compiling Main ( C.hs, C.o )\")\r\n(2,\"Linking A ...\")\r\n}}}\r\n\r\nOn the first request we ask Ghc to compile A.hs and B.hs; A.hs here depends on B.hs, which is compiled first, but A.hs contains an error and cannot be compiled. Then on the second request we ask GHC to compile A.hs and B.hs again; since B.hs is already compiled it only tries to compile A.hs, but this still fails. On the third request we ask Ghc to compile C.hs, an independent source file.\r\n\r\nNote that the integer listed for the second request is ''0'', not ''1''. For some reason the `setSessionDynFlags` does not seem to affect the recompilation of A.hs, even though when we compile C.hs in the third request, the output is ''2'', as expected.\r\n\r\n(This bug also occurs in GHC 7.4, but the API is slightly different so some minor modifications to to the code need to be made.)","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1bherzogbherzoghttps://gitlab.haskell.org/ghc/ghc/-/issues/16083tests relying on <iostream> are broken on Mojave builder2021-11-19T10:07:10ZBen Gamaritests relying on <iostream> are broken on Mojave builderIt appears that something has changed in the Darwin toolchain such that `<iostream>` is no longer found by default:
```
cd "driver/recomp001/recomp001.run" && $MAKE -s --no-print-directory recomp001
Compile failed (exit code 1) errors...It appears that something has changed in the Darwin toolchain such that `<iostream>` is no longer found by default:
```
cd "driver/recomp001/recomp001.run" && $MAKE -s --no-print-directory recomp001
Compile failed (exit code 1) errors were:
warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
objcpp-hi.mm:2:9: error: fatal error: 'iostream' file not found
#import <iostream>
^~~~~~~~~~
1 warning and 1 error generated.
`gcc' failed in phase `C Compiler'. (Exit code: 1)
*** unexpected failure for objcpp-hi(normal)
Compile failed (exit code 1) errors were:
warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
/var/folders/pb/c3dc08v12yzc536lnrnngvd40000gq/T/ghc56064_0/ghc_2.cpp:1:10: error:
fatal error: 'iostream' file not found
#include <iostream>
^~~~~~~~~~
1 warning and 1 error generated.
`gcc' failed in phase `C Compiler'. (Exit code: 1)
*** unexpected failure for T13366(normal)
```
Marking as broken.https://gitlab.haskell.org/ghc/ghc/-/issues/14152Float exit paths out of recursive functions2021-11-16T15:21:25ZJoachim Breitnermail@joachim-breitner.deFloat exit paths out of recursive functionsThis is a spin off of a discussion from #14137.
## The problem
We generally avoid inlining or floating a binding into a recursive function, because we do not want to duplicat work/allocations.
But sometimes the binding is only used in...This is a spin off of a discussion from #14137.
## The problem
We generally avoid inlining or floating a binding into a recursive function, because we do not want to duplicat work/allocations.
But sometimes the binding is only used inside the recursive function on the “exit path”. In which case it would be good to inline. Example:
```hs
let x = f x0
in let go 10 = h x
go i = go (i+1)
in go (0::Int) + 100
```
It would be beneficial to inline `x`.
The problem is that it is not very obvious that this occurence of `x` is ok for inlining. In particular, it is not syntactically visible.
## Proposed solution
If we apply loopification (#14068), this would turn into
```hs
let x = f x0
in let go n =
joinrec jgo 10 = h x
jgo i = call jgo (i+1)
in jump jgo n
in go (0::Int) + 100
```
I’d like to call this *first joinrec normal form*, defined as “every recursive function where all recursive calls are tail-recursive is a recursive join point”.
This ticket proposes to transform this even further and *float out all case alternatives that do not mention `jgo` as non-recursive join-points*, as so:
```hs
let x = f x0
in let go n =
join jexit = h x
joinrec jgo 10 = call jexit
jgo i = call jgo (i+1)
in jump jgo n
in go (0::Int) + 100
```
I’d like to call this *second `joinrec` normal form*, defined as “in first `joinrec` normal form, and all subexpressions of a recursive join point `j` that are in tail-call position and do not mention `j` are join calls”.
If the floated expression has free variables that are bound inside the `joinrec`, they turn into parameters of the newly created joinpoint.
At this point, GHC can tell that `go` is called at most once, and will therefore happily inline `x` into the right hand side of `jexit.
== Alternative solutions ==
Ticket #10918 uses Call Arity results to learn that `x` is one-Shot, and inline it even in the original code. This works, but the problem is that float-out will undo this. See [ticket:10918#comment:5].
== Limitation ==
It only works for recursive functions that are join points, or can be turned into join points by loopification (#14068). It does not work forexample for
{{{#!hs
let x = f x0
let go 0 = h x
go n = (go (n-1) + 1
in go 10
}}}
although it would be equally desirable to float `h x` out of `go` so that `x\` can be inlined.
## Preservation
A remaining tricky point is that we need to stop one of these carefully-constructed non-recursive join points being inlined into a recursive join point, even if it is invoked at just one place. That should not be hard. And in a final run of the simplifer (or in CorePrep) we could switch off that restriction and let it inline. (Ticket #14137 is about inlining *more* join points into recursive join points, so it is the antithesis to the present ticket.)https://gitlab.haskell.org/ghc/ghc/-/issues/6077Respect XDG_CONFIG_HOME2021-11-15T15:07:17ZSo8resRespect XDG_CONFIG_HOMEAs of now, ghc creates and uses a "$HOME/.ghc" directory. This is annoying to those who like to keep their $HOME directory clean through use of the XDG_CONFIG_HOME variable. Specifically, it's nice to have all configuration files in "$HO...As of now, ghc creates and uses a "$HOME/.ghc" directory. This is annoying to those who like to keep their $HOME directory clean through use of the XDG_CONFIG_HOME variable. Specifically, it's nice to have all configuration files in "$HOME/.config" instead of polluting "$HOME".
It would be great if ghc could create and use its configuration directory in the configuration directory specified by the user.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Respect XDG_CONFIG_HOME","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"As of now, ghc creates and uses a \"$HOME/.ghc\" directory. This is annoying to those who like to keep their $HOME directory clean through use of the XDG_CONFIG_HOME variable. Specifically, it's nice to have all configuration files in \"$HOME/.config\" instead of polluting \"$HOME\".\r\n\r\nIt would be great if ghc could create and use its configuration directory in the configuration directory specified by the user.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15570Core transformations generate bad indexCharOffAddr# call2021-11-12T15:58:44ZAlp MestanogullariCore transformations generate bad indexCharOffAddr# callConsider the following functions, which only differ in a bang pattern on the local binding `q` in the inner loop:
```hs
{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE MagicHash #-}
module Bug where
import GHC.Prim
import GHC.Types
f :: In...Consider the following functions, which only differ in a bang pattern on the local binding `q` in the inner loop:
```hs
{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE MagicHash #-}
module Bug where
import GHC.Prim
import GHC.Types
f :: Int -> String
f n_
= go n_ ""
where
go n cs | n < 62
= let !c = chooseChar62 n in c : cs
| otherwise
= go q (c : cs) where (q, r) = quotRem n 62
!c = chooseChar62 r
chooseChar62 :: Int -> Char
{-# INLINE chooseChar62 #-}
chooseChar62 (I# n) = C# (indexCharOffAddr# chars62 n)
chars62 = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"#
g :: Int -> String
g n_
= go n_ ""
where
go n cs | n < 62
= let !c = chooseChar62 n in c : cs
| otherwise
= go q (c : cs) where (!q, r) = quotRem n 62 -- !!! Note the bang on q
!c = chooseChar62 r
chooseChar62 :: Int -> Char
{-# INLINE chooseChar62 #-}
chooseChar62 (I# n) = C# (indexCharOffAddr# chars62 n)
chars62 = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"#
```
When building with `-O -fPIC -dynamic -ddump-simpl`, this is the Core I see, with a HEAD checkout from earlier this week built by hadrian:
```hs
-- chararacter array, used by both
chars62_r30r :: Addr#
chars62_r30r
= "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"#
-- Used at the end of Bug.$wgo, in the -9223372036854775808# branch,
-- therefore only used by generated Core for f, but not g!
lvl_r30s :: Char
lvl_r30s
= case indexCharOffAddr# chars62_r30r -9223372036854775808# of v_B2
{ __DEFAULT ->
GHC.Types.C# v_B2
}
-- Core for f
Rec {
Bug.$wgo
:: Int# -> [Char] -> (# Char, [Char] #)
Bug.$wgo
= \ (ww_s2WU :: Int#) (w_s2WR :: [Char]) ->
case GHC.Real.even3 of { I# y_a2QI -> -- GHC.Real.even3 == -1
case y_a2QI of {
__DEFAULT ->
case quotRemInt# ww_s2WU 62# of { (# ipv_a2QN, ipv1_a2QO #) ->
case indexCharOffAddr# chars62_r30r ipv1_a2QO of wild2_X4
{ __DEFAULT ->
case <# ww_s2WU 62# of {
__DEFAULT ->
Bug.$wgo
ipv_a2QN (GHC.Types.: @ Char (GHC.Types.C# wild2_X4) w_s2WR);
1# ->
case indexCharOffAddr# chars62_r30r ww_s2WU of wild3_X1G
{ __DEFAULT ->
(# GHC.Types.C# wild3_X1G, w_s2WR #)
}
}
}
};
62# ->
case ww_s2WU of wild2_a2QQ {
__DEFAULT ->
case quotRemInt# wild2_a2QQ 62# of { (# ipv_a2QT, ipv1_a2QU #) ->
case indexCharOffAddr# chars62_r30r ipv1_a2QU of wild4_X4
{ __DEFAULT ->
case <# wild2_a2QQ 62# of {
__DEFAULT ->
Bug.$wgo
ipv_a2QT (GHC.Types.: @ Char (GHC.Types.C# wild4_X4) w_s2WR);
1# ->
case indexCharOffAddr# chars62_r30r wild2_a2QQ of wild5_X1G
{ __DEFAULT ->
(# GHC.Types.C# wild5_X1G, w_s2WR #)
}
}
}
};
-9223372036854775808# ->
case lvl_r30s of { C# v1_B2 -> (# GHC.Types.C# v1_B2, w_s2WR #) }
}
}
}
end Rec }
Bug.f_go :: Int -> [Char] -> [Char]
Bug.f_go
= \ (w_s2WQ :: Int) (w1_s2WR :: [Char]) ->
case w_s2WQ of { I# ww1_s2WU ->
case Bug.$wgo ww1_s2WU w1_s2WR of { (# ww3_s2Xa, ww4_s2Xb #) ->
GHC.Types.: @ Char ww3_s2Xa ww4_s2Xb
}
}
f :: Int -> String
f = \ (n__aXG :: Int) ->
case n__aXG of { I# ww1_s2WU ->
case Bug.$wgo ww1_s2WU (GHC.Types.[] @ Char) of
{ (# ww3_s2Xa, ww4_s2Xb #) ->
GHC.Types.: @ Char ww3_s2Xa ww4_s2Xb
}
}
-- Core for g
Rec {
Bug.$wgo1
:: Int# -> [Char] -> (# Char, [Char] #)
Bug.$wgo1
= \ (ww_s2X4 :: Int#) (w_s2X1 :: [Char]) ->
case GHC.Real.even3 of { I# y_a2QI ->
case y_a2QI of {
__DEFAULT ->
case quotRemInt# ww_s2X4 62# of { (# ipv_a2QN, ipv1_a2QO #) ->
case indexCharOffAddr# chars62_r30r ipv1_a2QO of wild2_X4
{ __DEFAULT ->
case <# ww_s2X4 62# of {
__DEFAULT ->
Bug.$wgo1
ipv_a2QN (GHC.Types.: @ Char (GHC.Types.C# wild2_X4) w_s2X1);
1# ->
case indexCharOffAddr# chars62_r30r ww_s2X4 of wild3_XY
{ __DEFAULT ->
(# GHC.Types.C# wild3_XY, w_s2X1 #)
}
}
}
};
62# ->
case ww_s2X4 of wild2_a2QQ {
__DEFAULT ->
case quotRemInt# wild2_a2QQ 62# of { (# ipv_a2QT, ipv1_a2QU #) ->
case indexCharOffAddr# chars62_r30r ipv1_a2QU of wild4_X4
{ __DEFAULT ->
case <# wild2_a2QQ 62# of {
__DEFAULT ->
Bug.$wgo1
ipv_a2QT (GHC.Types.: @ Char (GHC.Types.C# wild4_X4) w_s2X1);
1# ->
case indexCharOffAddr# chars62_r30r wild2_a2QQ of wild5_XY
{ __DEFAULT ->
(# GHC.Types.C# wild5_XY, w_s2X1 #)
}
}
}
};
-9223372036854775808# ->
case GHC.Real.overflowError of wild4_00 { }
}
}
}
end Rec }
Bug.g_go :: Int -> [Char] -> [Char]
Bug.g_go
= \ (w_s2X0 :: Int) (w1_s2X1 :: [Char]) ->
case w_s2X0 of { I# ww1_s2X4 ->
case Bug.$wgo1 ww1_s2X4 w1_s2X1 of { (# ww3_s2Xd, ww4_s2Xe #) ->
GHC.Types.: @ Char ww3_s2Xd ww4_s2Xe
}
}
g :: Int -> String
g = \ (n__a29X :: Int) ->
case n__a29X of { I# ww1_s2X4 ->
case Bug.$wgo1 ww1_s2X4 (GHC.Types.[] @ Char) of
{ (# ww3_s2Xd, ww4_s2Xe #) ->
GHC.Types.: @ Char ww3_s2Xd ww4_s2Xe
}
}
```
Of particular interest is:
```hs
-- chararacter array, used by both
chars62_r30r :: Addr#
chars62_r30r
= "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"#
lvl_r30s :: Char
lvl_r30s
= case indexCharOffAddr# chars62_r30r -9223372036854775808# of v_B2
{ __DEFAULT ->
GHC.Types.C# v_B2
}
```
which is only used in the Core for `f`, not `g`! We're trying to access index `minBound :: Int` of that array of chars. While this is only used when we pass `minBound` to our function, it is still wrong I think. Moreover, as [hadrian issue 861](https://github.com/snowleopard/hadrian/issues/861) showed, this can lead to... linker errors! Which got fixed by changing the implementation of `iToBase62` in Unique.hs from `f` to `g` :-)
Note that when I build the same commit with the make build system, then GHC generates Core close to `g`'s above for _both functions_.
I tried describing some of the transformations that occur in [this comment](https://github.com/snowleopard/hadrian/issues/641#issuecomment-415881512) on hadrian's issue tracker. The gist of it is that the lack of strictness in `q` leads GHC to not spotting it early and when we inline `quotRem`/`quotRemInt` and start floating things in/out and distributing `case ... of` branches around, we end up with a dedicated branch in the inner loop for `minBound` which actually makes use of the result of `indexAddrOffAddr#`, as you can see here:
```hs
-9223372036854775808# ->
-- lvl_r30s is our bad value
case lvl_r30s of { C# v1_B2 -> (# GHC.Types.C# v1_B2, w_s2WR #) }
```
whereas this is what this branch looks like for `g`:
```hs
-9223372036854775808# ->
case GHC.Real.overflowError of wild4_00 { }
```
The `overflowError` is still there and GHC therefore realised that there's no point in computing anything since we always raise an overflow error in that branch. This `overflowError` just disappears in `f`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Core transformations generate bad indexCharOffAddr# call","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following functions, which only differ in a bang pattern on the local binding `q` in the inner loop:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE BangPatterns #-}\r\n{-# LANGUAGE MagicHash #-}\r\nmodule Bug where\r\n\r\nimport GHC.Prim\r\nimport GHC.Types\r\n\r\nf :: Int -> String\r\nf n_\r\n = go n_ \"\"\r\n where\r\n go n cs | n < 62\r\n = let !c = chooseChar62 n in c : cs\r\n | otherwise\r\n = go q (c : cs) where (q, r) = quotRem n 62\r\n !c = chooseChar62 r\r\n\r\n chooseChar62 :: Int -> Char\r\n {-# INLINE chooseChar62 #-}\r\n chooseChar62 (I# n) = C# (indexCharOffAddr# chars62 n)\r\n chars62 = \"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ\"#\r\n\r\ng :: Int -> String\r\ng n_\r\n = go n_ \"\"\r\n where\r\n go n cs | n < 62\r\n = let !c = chooseChar62 n in c : cs\r\n | otherwise\r\n = go q (c : cs) where (!q, r) = quotRem n 62 -- !!! Note the bang on q\r\n !c = chooseChar62 r\r\n\r\n chooseChar62 :: Int -> Char\r\n {-# INLINE chooseChar62 #-}\r\n chooseChar62 (I# n) = C# (indexCharOffAddr# chars62 n)\r\n chars62 = \"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ\"#\r\n}}}\r\n\r\nWhen building with `-O -fPIC -dynamic -ddump-simpl`, this is the Core I see, with a HEAD checkout from earlier this week built by hadrian:\r\n\r\n{{{#!hs\r\n-- chararacter array, used by both\r\nchars62_r30r :: Addr#\r\nchars62_r30r\r\n = \"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ\"#\r\n\r\n-- Used at the end of Bug.$wgo, in the -9223372036854775808# branch,\r\n-- therefore only used by generated Core for f, but not g! \r\nlvl_r30s :: Char\r\nlvl_r30s\r\n = case indexCharOffAddr# chars62_r30r -9223372036854775808# of v_B2\r\n { __DEFAULT ->\r\n GHC.Types.C# v_B2\r\n }\r\n\r\n\r\n-- Core for f\r\n\r\nRec {\r\nBug.$wgo\r\n :: Int# -> [Char] -> (# Char, [Char] #)\r\nBug.$wgo\r\n = \\ (ww_s2WU :: Int#) (w_s2WR :: [Char]) ->\r\n case GHC.Real.even3 of { I# y_a2QI -> -- GHC.Real.even3 == -1\r\n case y_a2QI of {\r\n __DEFAULT ->\r\n case quotRemInt# ww_s2WU 62# of { (# ipv_a2QN, ipv1_a2QO #) ->\r\n case indexCharOffAddr# chars62_r30r ipv1_a2QO of wild2_X4\r\n { __DEFAULT ->\r\n case <# ww_s2WU 62# of {\r\n __DEFAULT ->\r\n Bug.$wgo\r\n ipv_a2QN (GHC.Types.: @ Char (GHC.Types.C# wild2_X4) w_s2WR);\r\n 1# ->\r\n case indexCharOffAddr# chars62_r30r ww_s2WU of wild3_X1G\r\n { __DEFAULT ->\r\n (# GHC.Types.C# wild3_X1G, w_s2WR #)\r\n }\r\n }\r\n }\r\n };\r\n 62# ->\r\n case ww_s2WU of wild2_a2QQ {\r\n __DEFAULT ->\r\n case quotRemInt# wild2_a2QQ 62# of { (# ipv_a2QT, ipv1_a2QU #) ->\r\n case indexCharOffAddr# chars62_r30r ipv1_a2QU of wild4_X4\r\n { __DEFAULT ->\r\n case <# wild2_a2QQ 62# of {\r\n __DEFAULT ->\r\n Bug.$wgo\r\n ipv_a2QT (GHC.Types.: @ Char (GHC.Types.C# wild4_X4) w_s2WR);\r\n 1# ->\r\n case indexCharOffAddr# chars62_r30r wild2_a2QQ of wild5_X1G\r\n { __DEFAULT ->\r\n (# GHC.Types.C# wild5_X1G, w_s2WR #)\r\n }\r\n }\r\n }\r\n };\r\n -9223372036854775808# ->\r\n case lvl_r30s of { C# v1_B2 -> (# GHC.Types.C# v1_B2, w_s2WR #) }\r\n }\r\n }\r\n }\r\nend Rec }\r\n\r\nBug.f_go :: Int -> [Char] -> [Char]\r\nBug.f_go\r\n = \\ (w_s2WQ :: Int) (w1_s2WR :: [Char]) ->\r\n case w_s2WQ of { I# ww1_s2WU ->\r\n case Bug.$wgo ww1_s2WU w1_s2WR of { (# ww3_s2Xa, ww4_s2Xb #) ->\r\n GHC.Types.: @ Char ww3_s2Xa ww4_s2Xb\r\n }\r\n }\r\n\r\nf :: Int -> String\r\nf = \\ (n__aXG :: Int) ->\r\n case n__aXG of { I# ww1_s2WU ->\r\n case Bug.$wgo ww1_s2WU (GHC.Types.[] @ Char) of\r\n { (# ww3_s2Xa, ww4_s2Xb #) ->\r\n GHC.Types.: @ Char ww3_s2Xa ww4_s2Xb\r\n }\r\n }\r\n\r\n\r\n-- Core for g\r\n\r\nRec {\r\nBug.$wgo1\r\n :: Int# -> [Char] -> (# Char, [Char] #)\r\nBug.$wgo1\r\n = \\ (ww_s2X4 :: Int#) (w_s2X1 :: [Char]) ->\r\n case GHC.Real.even3 of { I# y_a2QI ->\r\n case y_a2QI of {\r\n __DEFAULT ->\r\n case quotRemInt# ww_s2X4 62# of { (# ipv_a2QN, ipv1_a2QO #) ->\r\n case indexCharOffAddr# chars62_r30r ipv1_a2QO of wild2_X4\r\n { __DEFAULT ->\r\n case <# ww_s2X4 62# of {\r\n __DEFAULT ->\r\n Bug.$wgo1\r\n ipv_a2QN (GHC.Types.: @ Char (GHC.Types.C# wild2_X4) w_s2X1);\r\n 1# ->\r\n case indexCharOffAddr# chars62_r30r ww_s2X4 of wild3_XY\r\n { __DEFAULT ->\r\n (# GHC.Types.C# wild3_XY, w_s2X1 #)\r\n }\r\n }\r\n }\r\n };\r\n 62# ->\r\n case ww_s2X4 of wild2_a2QQ {\r\n __DEFAULT ->\r\n case quotRemInt# wild2_a2QQ 62# of { (# ipv_a2QT, ipv1_a2QU #) ->\r\n case indexCharOffAddr# chars62_r30r ipv1_a2QU of wild4_X4\r\n { __DEFAULT ->\r\n case <# wild2_a2QQ 62# of {\r\n __DEFAULT ->\r\n Bug.$wgo1\r\n ipv_a2QT (GHC.Types.: @ Char (GHC.Types.C# wild4_X4) w_s2X1);\r\n 1# ->\r\n case indexCharOffAddr# chars62_r30r wild2_a2QQ of wild5_XY\r\n { __DEFAULT ->\r\n (# GHC.Types.C# wild5_XY, w_s2X1 #)\r\n }\r\n }\r\n }\r\n };\r\n -9223372036854775808# ->\r\n case GHC.Real.overflowError of wild4_00 { }\r\n }\r\n }\r\n }\r\nend Rec }\r\n\r\nBug.g_go :: Int -> [Char] -> [Char]\r\nBug.g_go\r\n = \\ (w_s2X0 :: Int) (w1_s2X1 :: [Char]) ->\r\n case w_s2X0 of { I# ww1_s2X4 ->\r\n case Bug.$wgo1 ww1_s2X4 w1_s2X1 of { (# ww3_s2Xd, ww4_s2Xe #) ->\r\n GHC.Types.: @ Char ww3_s2Xd ww4_s2Xe\r\n }\r\n }\r\n\r\ng :: Int -> String\r\ng = \\ (n__a29X :: Int) ->\r\n case n__a29X of { I# ww1_s2X4 ->\r\n case Bug.$wgo1 ww1_s2X4 (GHC.Types.[] @ Char) of\r\n { (# ww3_s2Xd, ww4_s2Xe #) ->\r\n GHC.Types.: @ Char ww3_s2Xd ww4_s2Xe\r\n }\r\n }\r\n}}}\r\n\r\nOf particular interest is:\r\n\r\n{{{#!hs\r\n-- chararacter array, used by both\r\nchars62_r30r :: Addr#\r\nchars62_r30r\r\n = \"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ\"#\r\n\r\nlvl_r30s :: Char\r\nlvl_r30s\r\n = case indexCharOffAddr# chars62_r30r -9223372036854775808# of v_B2\r\n { __DEFAULT ->\r\n GHC.Types.C# v_B2\r\n }\r\n}}}\r\n\r\nwhich is only used in the Core for `f`, not `g`! We're trying to access index `minBound :: Int` of that array of chars. While this is only used when we pass `minBound` to our function, it is still wrong I think. Moreover, as [https://github.com/snowleopard/hadrian/issues/861 hadrian issue 861] showed, this can lead to... linker errors! Which got fixed by changing the implementation of `iToBase62` in Unique.hs from `f` to `g` :-)\r\n\r\nNote that when I build the same commit with the make build system, then GHC generates Core close to `g`'s above for _both functions_.\r\n\r\nI tried describing some of the transformations that occur in [https://github.com/snowleopard/hadrian/issues/641#issuecomment-415881512 this comment] on hadrian's issue tracker. The gist of it is that the lack of strictness in `q` leads GHC to not spotting it early and when we inline `quotRem`/`quotRemInt` and start floating things in/out and distributing `case ... of` branches around, we end up with a dedicated branch in the inner loop for `minBound` which actually makes use of the result of `indexAddrOffAddr#`, as you can see here:\r\n\r\n{{{#!hs\r\n -9223372036854775808# ->\r\n -- lvl_r30s is our bad value\r\n case lvl_r30s of { C# v1_B2 -> (# GHC.Types.C# v1_B2, w_s2WR #) }\r\n}}}\r\n\r\nwhereas this is what this branch looks like for `g`:\r\n\r\n{{{#!hs\r\n -9223372036854775808# ->\r\n case GHC.Real.overflowError of wild4_00 { }\r\n}}}\r\n\r\nThe `overflowError` is still there and GHC therefore realised that there's no point in computing anything since we always raise an overflow error in that branch. This `overflowError` just disappears in `f`.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/5899RTS crash w/ strange closure type 603975781 on OS X 10.82021-11-12T10:31:33ZdylukesRTS crash w/ strange closure type 603975781 on OS X 10.8On OS X 10.8 (Mountain Lion, the first developer seed), GHC's RTS crashes with strange closure type 603975781, for almost any program compiled with GHC.
As examples, cpphs and cabal's Setup crash, but a simple `main = putStrLn "hello wo...On OS X 10.8 (Mountain Lion, the first developer seed), GHC's RTS crashes with strange closure type 603975781, for almost any program compiled with GHC.
As examples, cpphs and cabal's Setup crash, but a simple `main = putStrLn "hello world"' does not.
`runhaskell ...' works. It seems this only manifests in compiled programs.
An example of the output can be found here: https://gist.github.com/1918845
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC RTS crash w/ strange closure type 603975781 on OS X 10.8","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":["closure,","error,","internal","os","rts,","strange","x"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On OS X 10.8 (Mountain Lion, the first developer seed), GHC's RTS crashes with strange closure type 603975781, for almost any program compiled with GHC.\r\n\r\nAs examples, cpphs and cabal's Setup crash, but a simple `main = putStrLn \"hello world\"' does not.\r\n\r\n`runhaskell ...' works. It seems this only manifests in compiled programs. \r\n\r\nAn example of the output can be found here: https://gist.github.com/1918845","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/7651Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD)2021-11-12T06:50:21Zkazu-yamamotoBuiding GHC with parallel IO manager freezes on Mac (not on FreeBSD)Building GHC with parallel IO manager on Mac freezes when
compiling the dph libraries in the phase 2.
We **suspect this is due to a bug in the OS X implementation of kqueue**, for the reasons given below. In the meantime, we have added ...Building GHC with parallel IO manager on Mac freezes when
compiling the dph libraries in the phase 2.
We **suspect this is due to a bug in the OS X implementation of kqueue**, for the reasons given below. In the meantime, we have added an extra IO manager wakeup that appears to work around the problem; see `GHC/Event/Manager.hs`.
Details:
- This happens only if we specify "-j" to "make". Note that "make" closes stdin of sub-processes if "-j" is specified.
- Even if we specify "-j" to "make", the problem disappears with stdout/stderr redirection. That is, "make -jN \>& LOG &" works.
- The "-d" option of "make" does not make any effects.
- Programs compiled with built GHC (with our patches) work well. For test, I compiled a daemon HTTP server which closes stdin/stdout/stderr. It worked well.
An IO manager is polling a kqueue fd. Another Haskell thread on
another native thread registers an event through the same kqueue
fd. In many cases, this works on Mac. In a certain situation,
MacOS does not deliver an event to the IO manager. If the IO
manager gets up and polls the kqueue fd, the event is delivered.
This bug only appears when building GHC on Mac. I cannot find a
simple way to reproduce it. Even if we find a way to reproduce
it, I guess that we will probably reach a conclusion that this is
a bug of kqueue of Mac.
I have some evidences that kqueue of Mac is buggy:
- http://comments.gmane.org/gmane.comp.lib.ev/1871
- http://lists.apple.com/archives/darwin-dev/2011/Jun/msg00016.html8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11223Runtime linker performs eager loading of all object files2021-11-11T17:51:13ZTamar ChristinaRuntime linker performs eager loading of all object filesThe runtime linker seems to be re-exporting some of the symbols of `libmingwex` from the rts archive (using `SymI_HasProto`). Only a very small subset of symbols are re-exporting.
If a symbol is needed that isn't re-exported (e.g. `log1...The runtime linker seems to be re-exporting some of the symbols of `libmingwex` from the rts archive (using `SymI_HasProto`). Only a very small subset of symbols are re-exporting.
If a symbol is needed that isn't re-exported (e.g. `log1p`) then this code can't be run in GHCi because it will result in a duplicate symbols error.
### A workaround
The `rts` seems to be a special case again. The linker seems to ignore the `extra-libraries` from the `package.conf`, which explains why you can put anything you want in there and it'll still compile.
```
128 emptyPLS :: DynFlags -> PersistentLinkerState
129 emptyPLS _ = PersistentLinkerState {
130 closure_env = emptyNameEnv,
131 itbl_env = emptyNameEnv,
132 pkgs_loaded = init_pkgs,
133 bcos_loaded = [],
134 objs_loaded = [],
135 temp_sos = [] }
136
137 -- Packages that don't need loading, because the compiler
138 -- shares them with the interpreted program.
139 --
140 -- The linker's symbol table is populated with RTS symbols using an
141 -- explicit list. See rts/Linker.c for details.
142 where init_pkgs = [rtsUnitId]
```
I've tried 2 approaches which haven't worked completely:
1. I tried removing the symbols from the export list and adding `libmingwex` to the rts's `package.conf`and have it just link against it. But turns out the `rts`'s `package.conf` is ignored on all platforms. I didn't want to have to make an exception for Windows here and I don't know why the other platforms also ignore it so I abandoned this approach.
1. I tried marking the symbols we're re-exporting as weak symbols, so there wouldn't be a change to existing code and would allow you to link against `libmingwex`. But unfortunately because of when the other libraries specified by `-l` are linked in, some of the symbols have already been used and thus aren't weak anymore. So I still get duplicate link errors.
What I want to try now is leaving them as weak symbols, but loading `libmingwex.a` at `rts` initialization time. Much like how `kernel32` is loaded. This is hopefully early enough that the symbols haven't been used yet.
### Example
```hs
-- LogFloat.hs
module Main (main) where
import Data.Number.LogFloat (log1p)
main :: IO ()
main = print $ log1p 1.0
```
`runGhc LogFloat.hs` will fail:
```
Loading package logfloat-0.13.3.3 ...
linking ...
LogFloat.hs: ...\x86_64-windows-ghc-7.11.20151123\logfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn\HSlogfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn.o: unknown symbol `log1p'
LogFloat.hs: LogFloat.hs: unable to load package `logfloat-0.13.3.3'
```8.0.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/11208GHCi doesn't qualify types anymore2021-11-06T18:22:58ZHerbert Valerio Riedelhvr@gnu.orgGHCi doesn't qualify types anymore`M.hs` contains:
```hs
module M where
import qualified Prelude as P
f n = n P.+ 1
g h (P.Just x) = P.Just (h x)
g _ P.Nothing = P.Nothing
```
GHC 7.10.3 behaves as expected:
```
$ ghci-7.10.3 -ignore-dot-ghci M.hs
GHCi, version 7...`M.hs` contains:
```hs
module M where
import qualified Prelude as P
f n = n P.+ 1
g h (P.Just x) = P.Just (h x)
g _ P.Nothing = P.Nothing
```
GHC 7.10.3 behaves as expected:
```
$ ghci-7.10.3 -ignore-dot-ghci M.hs
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling M ( M.hs, interpreted )
Ok, modules loaded: M.
*M> :browse
f :: P.Num a => a -> a
g :: (t -> a) -> P.Maybe t -> P.Maybe a
*M> :t f
f :: P.Num a => a -> a
*M> :t g
g :: (t -> a) -> P.Maybe t -> P.Maybe a
```
However, GHC HEAD drops the module qualifiers
```
$ ghci-7.11.20151209 -ignore-dot-ghci M.hs
GHCi, version 7.11.20151209: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling M ( M.hs, interpreted )
Ok, modules loaded: M.
*M> :browse
f :: Num a => a -> a
g :: (t -> a) -> Maybe t -> Maybe a
*M> :t f
f :: Num a => a -> a
*M> :t g
g :: (t -> a) -> Maybe t -> Maybe a
*M> Nothing :: Maybe ()
<interactive>:4:12: error:
Not in scope: type constructor or class ‘Maybe’
Perhaps you meant ‘P.Maybe’ (imported from Prelude)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi doesn't qualify types anymore","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":["regression"],"differentials":[],"test_case":"","architecture":"","cc":["bgamari"],"type":"Bug","description":"`M.hs` contains:\r\n\r\n{{{#!hs\r\nmodule M where\r\n\r\nimport qualified Prelude as P\r\n\r\nf n = n P.+ 1\r\n\r\ng h (P.Just x) = P.Just (h x)\r\ng _ P.Nothing = P.Nothing\r\n}}}\r\n\r\nGHC 7.10.3 behaves as expected:\r\n\r\n{{{\r\n$ ghci-7.10.3 -ignore-dot-ghci M.hs \r\nGHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling M ( M.hs, interpreted )\r\nOk, modules loaded: M.\r\n*M> :browse\r\nf :: P.Num a => a -> a\r\ng :: (t -> a) -> P.Maybe t -> P.Maybe a\r\n*M> :t f\r\nf :: P.Num a => a -> a\r\n*M> :t g\r\ng :: (t -> a) -> P.Maybe t -> P.Maybe a\r\n}}}\r\n\r\nHowever, GHC HEAD drops the module qualifiers\r\n\r\n{{{\r\n$ ghci-7.11.20151209 -ignore-dot-ghci M.hs\r\nGHCi, version 7.11.20151209: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling M ( M.hs, interpreted )\r\nOk, modules loaded: M.\r\n*M> :browse\r\nf :: Num a => a -> a\r\ng :: (t -> a) -> Maybe t -> Maybe a\r\n*M> :t f\r\nf :: Num a => a -> a\r\n*M> :t g\r\ng :: (t -> a) -> Maybe t -> Maybe a\r\n*M> Nothing :: Maybe ()\r\n\r\n<interactive>:4:12: error:\r\n Not in scope: type constructor or class ‘Maybe’\r\n Perhaps you meant ‘P.Maybe’ (imported from Prelude)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/15245Data family promotion is possible2021-11-06T12:06:45ZVladislav ZavialovData family promotion is possibleThe User's Guide states that data families cannot be promoted, even with `-XTypeInType`:
> We promote data types and newtypes; type synonyms and type/data families are not promoted.
>
> The flag TypeInType (which implies DataKinds) rela...The User's Guide states that data families cannot be promoted, even with `-XTypeInType`:
> We promote data types and newtypes; type synonyms and type/data families are not promoted.
>
> The flag TypeInType (which implies DataKinds) relaxes some of these restrictions, allowing:
>
> Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types.
And yet the following code typechecks and runs:
```hs
{-# LANGUAGE TypeFamilies, TypeInType, TypeApplications #-}
import Type.Reflection
data family K
data instance K = MkK
main = print (typeRep @'MkK)
```
Is this a GHC bug or a documentation bug? I asked in IRC but I'm still confused:
```
<int-index> The user guide states that data families aren't promoted even when -XTypeInType is enabled. Where's the logic that ensures this? I checked with `data family K; data instance K = MkK` and I can use `'MkK` with no errors/warnings.
<int-index> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#overview "Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types."
<int-index> Is this info outdated?
<RyanGlScott> int-index: Is this in GHCi?
<RyanGlScott> It certainly fails in GHC
<RyanGlScott> But I think I understand why the former works
<int-index> RyanGlScott, yes, I'm checking this in GHCi
<RyanGlScott> int-index: So here's my understanding of how this works
<RyanGlScott> GHC kind-checks top-level declarations using a rather primitive SCC analysis
<RyanGlScott> In particular, it's primitive in the sense that data family instances give it a lot of trouble
<RyanGlScott> If you tried taking your code and putting it into a standalone .hs file and compiling that, then it would definitely complain about a promoted use of MkT
<RyanGlScott> As luck would have it, though, you were trying things out in GHCi
<RyanGlScott> Which essentially checks each line of input as its own strongly connected group of declarations
<RyanGlScott> So you can define MkT on one line and promote it in subsequent lines, since they're separate in the sense
<RyanGlScott> *that sense
<int-index> this sounds related to Trac #12088, and then I could work around it in GHC by using `$(return [])`, so data families are actually promoted anyway and this has nothing to do with GHC needing more powerful type theory
<RyanGlScott> Well, it does need more powerful type theory in the sense that that's a prerequisite for making the SCC analysis for kind-checking sophisticated enough to handle this
<RyanGlScott> But yes, it's quite simple to work around by using Template Haskell to explicitly split up groups.
<int-index> https://gist.github.com/int-index/c6cc1e20c4b9b5c99af40ee4e23ecb61 this works and no template haskell involved
<int-index> The reason I'm asking is that I'm touching this part of the User's Guide and I don't know what to write there.
<RyanGlScott> Huh, now that's interesting
<int-index> RyanGlScott, the only check I could find that controls what's promoted and what's not is 'isLegacyPromotableDataCon' - and enabling -XTypeInType disables this check.
<RyanGlScott> int-index: Right, that's baffling me
<RyanGlScott> Since that's supposed to be checked every time you promote a data constructor (I think)
<RyanGlScott> int-index: File a bug about that, I suppose
<RyanGlScott> Richard (who's sitting next to me right now) seems to think that that shouldn't be possible
<int-index> RyanGlScott, the thing is, I happily removed this check completely in D4748. Does this mean I have to restore a weaker version of it that only checks for data families? Why?
<int-index> Is it bad that -XDataKinds promotes data family constructors? Looks like I can just remove the "restrictions" part of the user guide and be done with it
<RyanGlScott> int-index: In theory, that shouldn't be possible
<int-index> OK, then what the check should be? No data families, any other restrictions?
<RyanGlScott> I might qualify that with "no data family instances defined in the same module"
<RyanGlScott> (Or to be precise, in the same SCC, but that's probably too technical for the users' guide)
<int-index> Well, this sounds hard to check. I was thinking along the lines of keeping the 'not (isFamInstTyCon (dataConTyCon dc))' part of the check...
<RyanGlScott> Oh, I thought you were only changing the users' guide :)
<int-index> Well, at this point I'm confused if I should change only the user guide or the check as well. If data families shouldn't be promoted ever, then I'll change GHC. If the limitation is about the current SCC group, I can just mention Trac #12088 as a known infelicity in the User's Guide
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | RyanGlScott, goldfire |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data family promotion is possible","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":["RyanGlScott","goldfire"],"type":"Bug","description":"The User's Guide states that data families cannot be promoted, even with `-XTypeInType`:\r\n\r\n> We promote data types and newtypes; type synonyms and type/data families are not promoted.\r\n>\r\n> The flag TypeInType (which implies DataKinds) relaxes some of these restrictions, allowing:\r\n>\r\n> Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types.\r\n\r\nAnd yet the following code typechecks and runs:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeFamilies, TypeInType, TypeApplications #-}\r\n\r\nimport Type.Reflection\r\n\r\ndata family K\r\ndata instance K = MkK\r\n\r\nmain = print (typeRep @'MkK)\r\n}}}\r\n\r\nIs this a GHC bug or a documentation bug? I asked in IRC but I'm still confused:\r\n\r\n{{{\r\n<int-index> The user guide states that data families aren't promoted even when -XTypeInType is enabled. Where's the logic that ensures this? I checked with `data family K; data instance K = MkK` and I can use `'MkK` with no errors/warnings.\r\n<int-index> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#overview \"Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types.\"\r\n<int-index> Is this info outdated?\r\n<RyanGlScott> int-index: Is this in GHCi?\r\n<RyanGlScott> It certainly fails in GHC\r\n<RyanGlScott> But I think I understand why the former works\r\n<int-index> RyanGlScott, yes, I'm checking this in GHCi\r\n<RyanGlScott> int-index: So here's my understanding of how this works\r\n<RyanGlScott> GHC kind-checks top-level declarations using a rather primitive SCC analysis\r\n<RyanGlScott> In particular, it's primitive in the sense that data family instances give it a lot of trouble\r\n<RyanGlScott> If you tried taking your code and putting it into a standalone .hs file and compiling that, then it would definitely complain about a promoted use of MkT\r\n<RyanGlScott> As luck would have it, though, you were trying things out in GHCi\r\n<RyanGlScott> Which essentially checks each line of input as its own strongly connected group of declarations\r\n<RyanGlScott> So you can define MkT on one line and promote it in subsequent lines, since they're separate in the sense\r\n<RyanGlScott> *that sense\r\n<int-index> this sounds related to Trac #12088, and then I could work around it in GHC by using `$(return [])`, so data families are actually promoted anyway and this has nothing to do with GHC needing more powerful type theory\r\n<RyanGlScott> Well, it does need more powerful type theory in the sense that that's a prerequisite for making the SCC analysis for kind-checking sophisticated enough to handle this\r\n<RyanGlScott> But yes, it's quite simple to work around by using Template Haskell to explicitly split up groups.\r\n<int-index> https://gist.github.com/int-index/c6cc1e20c4b9b5c99af40ee4e23ecb61 this works and no template haskell involved\r\n<int-index> The reason I'm asking is that I'm touching this part of the User's Guide and I don't know what to write there.\r\n<RyanGlScott> Huh, now that's interesting\r\n<int-index> RyanGlScott, the only check I could find that controls what's promoted and what's not is 'isLegacyPromotableDataCon' - and enabling -XTypeInType disables this check.\r\n<RyanGlScott> int-index: Right, that's baffling me\r\n<RyanGlScott> Since that's supposed to be checked every time you promote a data constructor (I think)\r\n<RyanGlScott> int-index: File a bug about that, I suppose\r\n<RyanGlScott> Richard (who's sitting next to me right now) seems to think that that shouldn't be possible\r\n<int-index> RyanGlScott, the thing is, I happily removed this check completely in D4748. Does this mean I have to restore a weaker version of it that only checks for data families? Why?\r\n<int-index> Is it bad that -XDataKinds promotes data family constructors? Looks like I can just remove the \"restrictions\" part of the user guide and be done with it\r\n<RyanGlScott> int-index: In theory, that shouldn't be possible\r\n<int-index> OK, then what the check should be? No data families, any other restrictions?\r\n<RyanGlScott> I might qualify that with \"no data family instances defined in the same module\"\r\n<RyanGlScott> (Or to be precise, in the same SCC, but that's probably too technical for the users' guide)\r\n<int-index> Well, this sounds hard to check. I was thinking along the lines of keeping the 'not (isFamInstTyCon (dataConTyCon dc))' part of the check...\r\n<RyanGlScott> Oh, I thought you were only changing the users' guide :)\r\n<int-index> Well, at this point I'm confused if I should change only the user guide or the check as well. If data families shouldn't be promoted ever, then I'll change GHC. If the limitation is about the current SCC group, I can just mention Trac #12088 as a known infelicity in the User's Guide\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/16051Cross compilation broken under Hadrian2021-11-05T19:45:02ZBen GamariCross compilation broken under HadrianHadrian falls over essentially immediately when cross-compiling:
```
$ ./boot
$ ./configure --target=aarch64-linux-gnu
$ hadrian/build.cabal.sh -j32
Up to date
Up to date
| Copy file: settings => _build/stage1/lib/settings
| Copy file: ...Hadrian falls over essentially immediately when cross-compiling:
```
$ ./boot
$ ./configure --target=aarch64-linux-gnu
$ hadrian/build.cabal.sh -j32
Up to date
Up to date
| Copy file: settings => _build/stage1/lib/settings
| Copy file: settings => _build/stage0/lib/settings
| Copy file: utils/hsc2hs/template-hsc.h => _build/stage0/lib/template-hsc.h
| Copy file: llvm-targets => _build/stage0/lib/llvm-targets
| Copy file: driver/ghc-usage.txt => _build/stage0/lib/ghc-usage.txt
| Copy file: llvm-passes => _build/stage0/lib/llvm-passes
| Copy file: driver/ghci-usage.txt => _build/stage0/lib/ghci-usage.txt
shakeArgsWith 0.000s 0%
Function shake 0.084s 20% ======
Database read 0.000s 0%
With database 0.000s 0%
Running rules 0.329s 79% =========================
Total 0.415s 100%
Error when running Shake build system:
at src/Rules.hs:(35,19)-(48,17):
at src/Rules.hs:48:5-17:
* Depends on: _build/stage2/bin/aarch64-linux-gnu-ghctags
at src/Hadrian/Utilities.hs:292:5-18:
* Depends on: _build/stage0/bin/aarch64-linux-gnu-ghctags
* Raised the exception:
Unknown program "_build/stage0/bin/aarch64-linux-gnu-ghctags"
CallStack (from HasCallStack):
error, called at src/Rules/Program.hs:26:29 in main:Rules.Program
```Make removalAlp MestanogullariAlp Mestanogullari