GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:16:24Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/14585Consider doing a CPS→SSA conversion in the backend2019-07-07T18:16:24ZdobenourConsider doing a CPS→SSA conversion in the backendGHC currently uses CPS when generating code. This is difficult to map to LLVM, and even in the NCG may result in suboptimal use of the CPU, since CPUs are optimized for C-like languages.
It might be worthwhile to convert from CPS to SSA...GHC currently uses CPS when generating code. This is difficult to map to LLVM, and even in the NCG may result in suboptimal use of the CPU, since CPUs are optimized for C-like languages.
It might be worthwhile to convert from CPS to SSA form in the backend and then optimize *that*. This would require a bunch of changes to the RTS, and add an entire new IR, but could enable optimizations that would otherwise be impossible.
To avoid a big compile-time regression, the SSA IR should be represented as a flat array, rather than a sea of linked nodes.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Consider doing a CPS→SSA conversion in the backend","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"GHC currently uses CPS when generating code. This is difficult to map to LLVM, and even in the NCG may result in suboptimal use of the CPU, since CPUs are optimized for C-like languages.\r\n\r\nIt might be worthwhile to convert from CPS to SSA form in the backend and then optimize ''that''. This would require a bunch of changes to the RTS, and add an entire new IR, but could enable optimizations that would otherwise be impossible.\r\n\r\nTo avoid a big compile-time regression, the SSA IR should be represented as a flat array, rather than a sea of linked nodes.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14583Don’t use `String` when generating code2019-07-07T18:16:25ZdobenourDon’t use `String` when generating codeGHC uses `String` when generating code, which is very slow. It would be much better to switch to `Data.ByteString.Builder`, or better yet output executables directly rather than going through an assembler.
This applies to both the nativ...GHC uses `String` when generating code, which is very slow. It would be much better to switch to `Data.ByteString.Builder`, or better yet output executables directly rather than going through an assembler.
This applies to both the native and LLVM code generators.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Don’t use `String` when generating code","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"GHC uses `String` when generating code, which is very slow. It would be much better to switch to `Data.ByteString.Builder`, or better yet output executables directly rather than going through an assembler.\r\n\r\nThis applies to both the native and LLVM code generators.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14582Review and improve the Typeable API2019-07-07T18:16:25ZSimon Peyton JonesReview and improve the Typeable APIThis ticket is to track improvements in the `Typeable` API
There are a number of points I'm uncomfortable about
- `Data.Typable` is presumably meant to be the public API, and is
fairly small. But `Data.Typeable.Internal` has a much ...This ticket is to track improvements in the `Typeable` API
There are a number of points I'm uncomfortable about
- `Data.Typable` is presumably meant to be the public API, and is
fairly small. But `Data.Typeable.Internal` has a much larger
API, which includes pattern synonyms and suchlike that appear
to be for the benefit of clients, not just internal use.
- The `Typeable` API has `type TypeRep = I.SomeTypeRep` which is
different to the type-indexed `data TypeRep a` defined in
`Data.Typeable.Internals`. This is exteremly confusing. Perhaps
this is intended to be temporary, while we are moving over to the new type-indexed
representation. But then what's the transition plan?
- I cordially dislike this stuff about `IsApplication` in
`Internals` ([this commit](https://git.haskell.org/ghc.git/commitdiff/1acb922bb1186662919c1dbc0af596584e5db3ac)). It's hard for me to understand what's going on. I
believe that the two pattern synonyms `App` and `Con` are supposed
to be exhaustive -- if so, let's just write a COMPLETE pragma.
- The code has many uses of `unsafeCoerce`, whereas the drive of
our "Typed reflection in Haskell" paper was to reduced the size
of the trusted code base. I'd like to see a comment on each of
those uses of `unsafeCoerce` to explain.
- Do we really need `Con'` as well as `Con`?
- The API could do with some careful documentation, in Haddock,
but perhaps also an accomanying wiki page. It's tricky stuff.
Here's the [Typeablewikipage](typeable)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"Review and improve the Typeable API","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["Typeable"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This ticket is to track improvements in the `Typeable` API\r\n\r\nThere are a number of points I'm uncomfortable about\r\n\r\n* `Data.Typable` is presumably meant to be the public API, and is\r\n fairly small. But `Data.Typeable.Internal` has a much larger\r\n API, which includes pattern synonyms and suchlike that appear\r\n to be for the benefit of clients, not just internal use.\r\n\r\n* The `Typeable` API has `type TypeRep = I.SomeTypeRep` which is\r\n different to the type-indexed `data TypeRep a` defined in\r\n `Data.Typeable.Internals`. This is exteremly confusing. Perhaps\r\n this is intended to be temporary, while we are moving over to the new type-indexed\r\n representation. But then what's the transition plan?\r\n\r\n* I cordially dislike this stuff about `IsApplication` in\r\n `Internals` ([https://git.haskell.org/ghc.git/commitdiff/1acb922bb1186662919c1dbc0af596584e5db3ac this commit]). It's hard for me to understand what's going on. I\r\n believe that the two pattern synonyms `App` and `Con` are supposed\r\n to be exhaustive -- if so, let's just write a COMPLETE pragma.\r\n\r\n* The code has many uses of `unsafeCoerce`, whereas the drive of\r\n our \"Typed reflection in Haskell\" paper was to reduced the size\r\n of the trusted code base. I'd like to see a comment on each of\r\n those uses of `unsafeCoerce` to explain.\r\n\r\n* Do we really need `Con'` as well as `Con`?\r\n\r\n* The API could do with some careful documentation, in Haddock,\r\n but perhaps also an accomanying wiki page. It's tricky stuff.\r\n\r\nHere's the [wiki:Typeable Typeable wiki page]","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14577Internal error when linker is initialized with -fexternal-interpreter set whe...2019-07-07T18:16:27ZlazacInternal error when linker is initialized with -fexternal-interpreter set when compiling TH code with profilingWhen using the GHC API with this minimal example, using the -fexternal-interpreter option, compiled with profiling enabled:
```hs
import GHC
import Control.Monad.IO.Class
import GHC.Paths ( libdir )
import DynFlags
import Linker
main =...When using the GHC API with this minimal example, using the -fexternal-interpreter option, compiled with profiling enabled:
```hs
import GHC
import Control.Monad.IO.Class
import GHC.Paths ( libdir )
import DynFlags
import Linker
main = runGhc (Just libdir) $ do
env <- getSession
dflags <- getSessionDynFlags
liftIO $ initDynLinker env
setSessionDynFlags (setGeneralFlag' Opt_ExternalInterpreter dflags)
target <- guessTarget "A.hs" Nothing
setTargets [target]
load LoadAllTargets
```
Invoking the main executable:
```
testprof
```
While A.hs contains a TH splice:
```hs
{-# LANGUAGE TemplateHaskell #-}
module A where
$(return [])
```
The compiler crashes:
```
Access violation in generated code when writing 0000000000000024
```
Probably I'm misusing the API in this example, but the way it crashes is suspicious.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Internal error when linker is initialized with -fexternal-interpreter set when compiling TH code with profiling","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When using the GHC API with this minimal example, using the -fexternal-interpreter option, compiled with profiling enabled:\r\n\r\n{{{#!hs\r\nimport GHC\r\nimport Control.Monad.IO.Class\r\nimport GHC.Paths ( libdir )\r\nimport DynFlags\r\nimport Linker\r\n\r\nmain = runGhc (Just libdir) $ do\r\n env <- getSession\r\n dflags <- getSessionDynFlags\r\n liftIO $ initDynLinker env\r\n setSessionDynFlags (setGeneralFlag' Opt_ExternalInterpreter dflags) \r\n target <- guessTarget \"A.hs\" Nothing\r\n setTargets [target]\r\n load LoadAllTargets\r\n}}}\r\n\r\nInvoking the main executable:\r\n{{{\r\ntestprof\r\n}}}\r\n\r\nWhile A.hs contains a TH splice:\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule A where\r\n\r\n$(return [])\r\n}}}\r\n\r\nThe compiler crashes:\r\n{{{\r\nAccess violation in generated code when writing 0000000000000024\r\n}}}\r\n\r\nProbably I'm misusing the API in this example, but the way it crashes is suspicious.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14576Internal error when compiling TH code with profiling on Windows2019-07-07T18:16:27ZlazacInternal error when compiling TH code with profiling on WindowsWhen using the GHC API with this minimal example, compiled with profiling enabled:
```hs
module Main where
import GHC
import GHC.Paths ( libdir )
main = runGhc (Just libdir) $ do
env <- getSession
dflags <- getSessionD...When using the GHC API with this minimal example, compiled with profiling enabled:
```hs
module Main where
import GHC
import GHC.Paths ( libdir )
main = runGhc (Just libdir) $ do
env <- getSession
dflags <- getSessionDynFlags
setSessionDynFlags dflags
target <- guessTarget "A.hs" Nothing
setTargets [target]
load LoadAllTargets
```
Invoking the main executable:
```
testprof
```
While A.hs contains a TH splice:
```hs
{-# LANGUAGE TemplateHaskell #-}
module A where
$(return [])
```
The compiler crashes:
```
testprof.exe: internal error: IMAGE_REL_AMD64_ADDR32[NB]: High bits are set in 10e6109d0 for .text
(GHC version 8.2.1 for x86_64_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
The walkaround is to use -fexternal-interpreter, in that case, the crash does not happen.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Internal error when compiling TH code with profiling on Windows","status":"New","operating_system":"Unknown/Multiple","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When using the GHC API with this minimal example, compiled with profiling enabled:\r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\nimport GHC\r\nimport GHC.Paths ( libdir )\r\n\r\nmain = runGhc (Just libdir) $ do\r\n env <- getSession\r\n dflags <- getSessionDynFlags\r\n setSessionDynFlags dflags\r\n target <- guessTarget \"A.hs\" Nothing\r\n setTargets [target]\r\n load LoadAllTargets\r\n}}}\r\n\r\nInvoking the main executable:\r\n{{{\r\ntestprof\r\n}}}\r\n\r\nWhile A.hs contains a TH splice:\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule A where\r\n\r\n$(return [])\r\n}}}\r\n\r\nThe compiler crashes:\r\n{{{\r\ntestprof.exe: internal error: IMAGE_REL_AMD64_ADDR32[NB]: High bits are set in 10e6109d0 for .text\r\n (GHC version 8.2.1 for x86_64_unknown_mingw32)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nThis application has requested the Runtime to terminate it in an unusual way.\r\nPlease contact the application's support team for more information.\r\n}}}\r\n\r\nThe walkaround is to use -fexternal-interpreter, in that case, the crash does not happen.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14572Document for writing GHC-based compiler2019-07-07T18:16:28ZzaoqiDocument for writing GHC-based compiler<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1 |
| Type | FeatureRequest |
| TypeOfFailure ...<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.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":"Document for writing GHC-based compiler","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14570Untouchable error arises from type equality, but not equivalent program with ...2019-07-07T18:16:28ZAlexis KingUntouchable error arises from type equality, but not equivalent program with fundepsGiven some type definitions:
```hs
data A
data B (f :: * -> *)
data X (k :: *)
```
…and this typeclass:
```hs
class C k a | k -> a
```
…these (highly contrived for the purposes of a minimal example) function definitions typecheck:
`...Given some type definitions:
```hs
data A
data B (f :: * -> *)
data X (k :: *)
```
…and this typeclass:
```hs
class C k a | k -> a
```
…these (highly contrived for the purposes of a minimal example) function definitions typecheck:
```hs
f :: forall f. (forall k. (C k (B f)) => f k) -> A
f _ = undefined
g :: (forall k. (C k (B X)) => X k) -> A
g = f
```
However, if we use a type family instead of a class with a functional dependency:
```hs
type family F (k :: *)
```
…then the equivalent function definitions fail to typecheck:
```hs
f :: forall f. (forall k. (F k ~ B f) => f k) -> A
f _ = undefined
g :: (forall k. (F k ~ B X) => X k) -> A
g = f
```
```
• Couldn't match type ‘f0’ with ‘X’
‘f0’ is untouchable
inside the constraints: F k ~ B f0
bound by a type expected by the context:
F k ~ B f0 => f0 k
Expected type: f0 k
Actual type: X k
• In the expression: f
In an equation for ‘g’: g = f
```
I read Section 5.2 of the OutsideIn(X) paper, which describes touchable and untouchable type variables, and I *sort of* understand what’s going on here. If I add an extra argument to `f` that pushes the choice of `f` outside the inner `forall`, then the program typechecks:
```hs
f :: forall f a. f a -> (forall k. (F k ~ B f) => f k) -> A
f _ _ = undefined
g :: forall a. X a -> (forall k. (F k ~ B X) => X k) -> A
g = f
```
I don’t know if this is actually a bug—it seems entirely reasonable to me that I don’t fully understand what is going on here—but I’m stumped as to *why* GHC rejects this program but accepts the one involving functional dependencies. I would expect it to either accept or reject both programs, given they *seem* equivalent.
Is this just an unfortunate infelicity of the differences between how functional dependencies and type equalities are internally solved? Or is there a deeper difference between these two programs?
,,(Note: This ticket is adapted from [this Stack Overflow question](https://stackoverflow.com/q/47734825/465378).),,
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.2 |
| 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":"Untouchable error arises from type equality, but not equivalent program with fundeps","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Given some type definitions:\r\n\r\n{{{#!hs\r\ndata A\r\ndata B (f :: * -> *)\r\ndata X (k :: *)\r\n}}}\r\n\r\n…and this typeclass:\r\n\r\n{{{#!hs\r\nclass C k a | k -> a\r\n}}}\r\n\r\n…these (highly contrived for the purposes of a minimal example) function definitions typecheck:\r\n\r\n{{{#!hs\r\nf :: forall f. (forall k. (C k (B f)) => f k) -> A\r\nf _ = undefined\r\n\r\ng :: (forall k. (C k (B X)) => X k) -> A\r\ng = f\r\n}}}\r\n\r\nHowever, if we use a type family instead of a class with a functional dependency:\r\n\r\n{{{#!hs\r\ntype family F (k :: *)\r\n}}}\r\n\r\n…then the equivalent function definitions fail to typecheck:\r\n\r\n{{{#!hs\r\nf :: forall f. (forall k. (F k ~ B f) => f k) -> A\r\nf _ = undefined\r\n\r\ng :: (forall k. (F k ~ B X) => X k) -> A\r\ng = f\r\n}}}\r\n\r\n{{{\r\n• Couldn't match type ‘f0’ with ‘X’\r\n ‘f0’ is untouchable\r\n inside the constraints: F k ~ B f0\r\n bound by a type expected by the context:\r\n F k ~ B f0 => f0 k\r\n Expected type: f0 k\r\n Actual type: X k\r\n• In the expression: f\r\n In an equation for ‘g’: g = f\r\n}}}\r\n\r\nI read Section 5.2 of the OutsideIn(X) paper, which describes touchable and untouchable type variables, and I ''sort of'' understand what’s going on here. If I add an extra argument to `f` that pushes the choice of `f` outside the inner `forall`, then the program typechecks:\r\n\r\n{{{#!hs\r\nf :: forall f a. f a -> (forall k. (F k ~ B f) => f k) -> A\r\nf _ _ = undefined\r\n\r\ng :: forall a. X a -> (forall k. (F k ~ B X) => X k) -> A\r\ng = f\r\n}}}\r\n\r\nI don’t know if this is actually a bug—it seems entirely reasonable to me that I don’t fully understand what is going on here—but I’m stumped as to ''why'' GHC rejects this program but accepts the one involving functional dependencies. I would expect it to either accept or reject both programs, given they ''seem'' equivalent.\r\n\r\nIs this just an unfortunate infelicity of the differences between how functional dependencies and type equalities are internally solved? Or is there a deeper difference between these two programs?\r\n\r\n,,(Note: This ticket is adapted from [https://stackoverflow.com/q/47734825/465378 this Stack Overflow question].),,","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14565Performance degrades from -O1 to -O22021-03-31T12:47:26ZdbeachamPerformance degrades from -O1 to -O2GHC seems to get stuck at SpecConstr stage when compiling.
I've managed to get the example down to what appears to be minimal but making a number of minor changes makes the compilation go through quickly:
- changing `toIdx` to `const 0...GHC seems to get stuck at SpecConstr stage when compiling.
I've managed to get the example down to what appears to be minimal but making a number of minor changes makes the compilation go through quickly:
- changing `toIdx` to `const 0`
- removing one of the `V.forM_` layers.
- using "-fno-spec-constr" (unsuprisingly).
I can't reproduce it on 8.0.2.
In larger examples I was able to get memory and cpu to sky rocket quite quickly but I appear to have lost some of that behaviour when paring down the example.Simon JakobiSimon Jakobihttps://gitlab.haskell.org/ghc/ghc/-/issues/14562IntRep vs WordRep2019-07-07T18:16:30ZAndrew MartinIntRep vs WordRepWhy do `Int#` and `Word#` have different runtime representations? By this I mean that:
```hs
Int# :: TYPE 'IntRep
Word# :: TYPE 'WordRep
```
To my understanding, they are always the same size and always live in the same set of register...Why do `Int#` and `Word#` have different runtime representations? By this I mean that:
```hs
Int# :: TYPE 'IntRep
Word# :: TYPE 'WordRep
```
To my understanding, they are always the same size and always live in the same set of registers. The docs for unsafeCoerce\# state that it can be used for:
> Casting an unboxed type to another unboxed type of the same size (but not coercions between floating-point and integral types)
The implies that a cast between `Int#` and `Word#` is acceptable. But if you're able to unsafeCoerce\# between two types, shouldn't they be defined as having the same representation?
What I'm suggesting is that it may be better to collapse `IntRep` and `WordRep` into a single representation (probably named `WordRep`). We would then get slightly more reusable code in some cases:
```hs
data WordList (x :: TYPE 'WordRep)
= WordListCons x (WordList x)
| WordListNil
ints :: WordList Int#
ints = WordListCons 5# (WordListCons 8# WordListNil)
words :: WordList Word#
words = WordListCons 4## (WordListCons 12## WordListNil)
mapWordList :: forall (x :: TYPE 'WordRep). (x -> x) -> WordList x -> WordList x
mapWordList _ WordListNil = WordListNil
mapWordList f (WordListCons x xs) = WordListCons (f x) xs
biggerInts :: WordList Int#
biggerInts = mapWordList (\x -> x +# 3) ints
biggerWords :: WordList Int#
biggerWords = mapWordList (\x -> plusWord# x 3) ints
```
For additional context, I'd add that, excluding `SumRep` and `TupleRep` (because you can produce different nestings with equivalent representations), coercions between types of different representations are always unsound.https://gitlab.haskell.org/ghc/ghc/-/issues/14559When overlapping instances lead to a compile error, show import chains for th...2019-07-07T18:16:31ZArtyom.KazakWhen overlapping instances lead to a compile error, show import chains for the instancesHere's an example from work:
```
• Overlapping instances for ToJSON BackupPhrase
arising from a use of 'aesonRoundtripProp'
Matching instances:
instance ToJSON BackupPhrase
-- Defined in 'Cardano.Wall...Here's an example from work:
```
• Overlapping instances for ToJSON BackupPhrase
arising from a use of 'aesonRoundtripProp'
Matching instances:
instance ToJSON BackupPhrase
-- Defined in 'Cardano.Wallet.Orphans.Aeson'
instance ToJSON BackupPhrase
-- Defined in 'Pos.Wallet.Aeson.ClientTypes'
```
Currently resolving such issues requires looking carefully at all imports and trying to guess which ones bring the instance into scope. It'd be quite helpful if the error was explicit about the import chain:
```
• Overlapping instances for ToJSON BackupPhrase
arising from a use of 'aesonRoundtripProp'
Matching instances:
instance ToJSON BackupPhrase
-- Defined in 'Cardano.Wallet.Orphans.Aeson',
-- imported by 'Cardano.Wallet.Orphans'
instance ToJSON BackupPhrase
-- Defined in 'Pos.Wallet.Aeson.ClientTypes',
-- imported by 'Pos.Wallet.Web.Mode',
-- and then by 'Cardano.Wallet.API.V1.Migration'
```
Thoughts?
I'm worried about two things here:
1. Might these chains get too long?
1. Is it sufficiently obvious that “imported by `A` and then by `B`” means that you have imported `B` and `B` imported `A`, and not vice-versa?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.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":"When overlapping instances lead to a compile error, show import chains for the instances","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Here's an example from work:\r\n\r\n{{{\r\n • Overlapping instances for ToJSON BackupPhrase\r\n arising from a use of 'aesonRoundtripProp'\r\n Matching instances:\r\n instance ToJSON BackupPhrase\r\n -- Defined in 'Cardano.Wallet.Orphans.Aeson'\r\n instance ToJSON BackupPhrase\r\n -- Defined in 'Pos.Wallet.Aeson.ClientTypes'\r\n}}}\r\n\r\nCurrently resolving such issues requires looking carefully at all imports and trying to guess which ones bring the instance into scope. It'd be quite helpful if the error was explicit about the import chain:\r\n\r\n{{{\r\n • Overlapping instances for ToJSON BackupPhrase\r\n arising from a use of 'aesonRoundtripProp'\r\n Matching instances:\r\n instance ToJSON BackupPhrase\r\n -- Defined in 'Cardano.Wallet.Orphans.Aeson',\r\n -- imported by 'Cardano.Wallet.Orphans'\r\n instance ToJSON BackupPhrase\r\n -- Defined in 'Pos.Wallet.Aeson.ClientTypes',\r\n -- imported by 'Pos.Wallet.Web.Mode',\r\n -- and then by 'Cardano.Wallet.API.V1.Migration'\r\n}}}\r\n\r\nThoughts?\r\n\r\nI'm worried about two things here:\r\n\r\n 1. Might these chains get too long?\r\n\r\n 2. Is it sufficiently obvious that “imported by `A` and then by `B`” means that you have imported `B` and `B` imported `A`, and not vice-versa?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14558Unable to parse integer-gmp's Cabal file2019-07-07T18:16:31ZtaylorfausakUnable to parse integer-gmp's Cabal fileinteger-gmp version 1.0.1.0 has this line in [its Cabal file](https://hackage.haskell.org/package/integer-gmp-1.0.1.0/revision/0.cabal): ` build-depends: ghc-prim ^>= 0.5.1.0 `
That uses the new caret constraint syntax. That syntax was ...integer-gmp version 1.0.1.0 has this line in [its Cabal file](https://hackage.haskell.org/package/integer-gmp-1.0.1.0/revision/0.cabal): ` build-depends: ghc-prim ^>= 0.5.1.0 `
That uses the new caret constraint syntax. That syntax was introduced by Cabal 2 a few months ago in July/August. Attempting to build integer-gmp with a slightly older version of Cabal, like 1.24.2.0, or with the latest released version of Stack (1.5.1) fails with this error:
` Unable to parse cabal file for integer-gmp-1.0.1.0: NoParse "build-depends" 58 `
This was reported on Stack's issue tracker and on Reddit:
- https://github.com/commercialhaskell/stack/issues/3624
- https://www.reddit.com/r/haskell/comments/7hs20y/how_to_fix_stack_unable_to_parse_cabal_file/
I was not able to find an issue tracker for integer-gmp. Someone suggested that I open an issue here instead.
I can see how this isn't a bug per se because integer-gmp's Cabal file specifies ` cabal-version: 2.0`. Nevertheless, it's frustrating that a core library is using a bleeding edge feature for basically no reason. It would be nice if integer-gmp used the more typical ` cabal-version: >= 1.10` and specified its dependency as ` build-depends: ghc-prim >= 0.5.1 && <0.6`, without the caret operator.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | CompileTimeCrash |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unable to parse integer-gmp's Cabal file","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"integer-gmp version 1.0.1.0 has this line in [https://hackage.haskell.org/package/integer-gmp-1.0.1.0/revision/0.cabal its Cabal file]: {{{ build-depends: ghc-prim ^>= 0.5.1.0 }}}\r\n\r\nThat uses the new caret constraint syntax. That syntax was introduced by Cabal 2 a few months ago in July/August. Attempting to build integer-gmp with a slightly older version of Cabal, like 1.24.2.0, or with the latest released version of Stack (1.5.1) fails with this error:\r\n\r\n{{{ Unable to parse cabal file for integer-gmp-1.0.1.0: NoParse \"build-depends\" 58 }}}\r\n\r\nThis was reported on Stack's issue tracker and on Reddit:\r\n\r\n- https://github.com/commercialhaskell/stack/issues/3624\r\n- https://www.reddit.com/r/haskell/comments/7hs20y/how_to_fix_stack_unable_to_parse_cabal_file/\r\n\r\nI was not able to find an issue tracker for integer-gmp. Someone suggested that I open an issue here instead. \r\n\r\nI can see how this isn't a bug per se because integer-gmp's Cabal file specifies {{{ cabal-version: 2.0}}}. Nevertheless, it's frustrating that a core library is using a bleeding edge feature for basically no reason. It would be nice if integer-gmp used the more typical {{{ cabal-version: >= 1.10}}} and specified its dependency as {{{ build-depends: ghc-prim >= 0.5.1 && <0.6}}}, without the caret operator. ","type_of_failure":"CompileTimeCrash","blocking":[]} -->Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/14553Implement native CPP2020-02-25T23:19:13ZDavid FeuerImplement native CPPProposal/NativeCpp explains why we might want to embed a C-like preprocessor (e.g., hpp) into GHC. This ticket tracks that proposal.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| --------------...Proposal/NativeCpp explains why we might want to embed a C-like preprocessor (e.g., hpp) into GHC. This ticket tracks that proposal.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.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":"Implement native CPP","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Proposal/NativeCpp explains why we might want to embed a C-like preprocessor (e.g., hpp) into GHC. This ticket tracks that proposal.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14550Report the provenance of TyThings2019-07-07T18:16:33ZEdward Z. YangReport the provenance of TyThingsOne thing we are slightly nervous about regarding our resolution to #14396 is whether or not there will be a difficult to understand bug stemming from the fact that we may silently pick up an hs-boot TyThing, depending on when you do a l...One thing we are slightly nervous about regarding our resolution to #14396 is whether or not there will be a difficult to understand bug stemming from the fact that we may silently pick up an hs-boot TyThing, depending on when you do a lookup. You may be able to find the information by printing the TyThing with pprTyThing, but nothing is going to tell you, in the face, "Hey! This came from a boot file!"
So, simonpj suggested that we extend the TyThing pretty-printer to say where a TyThing came from. This is a good question. The big question: where will we put the provenance? There are two possibilities:
1. Add a field in each constructor TyThing recording the provenance (this feels like a disruptive to an otherwise very simple union)
1. Add a field to each of the constructors Id, ConLike, TyCon, CoAxiom (this involves a lot more typing, but these constructors already have lots of fields so it's not as disruptive)
The provenance will, for now, look something like:
```
newtype TyThingSrc = TyThingSrc {
tyThingFromBoot :: Bool
}
```
and then `TcIface` will be extended to know if we're in boot and will fill things in accordingly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Report the provenance of TyThings","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"One thing we are slightly nervous about regarding our resolution to #14396 is whether or not there will be a difficult to understand bug stemming from the fact that we may silently pick up an hs-boot TyThing, depending on when you do a lookup. You may be able to find the information by printing the TyThing with pprTyThing, but nothing is going to tell you, in the face, \"Hey! This came from a boot file!\"\r\n\r\nSo, simonpj suggested that we extend the TyThing pretty-printer to say where a TyThing came from. This is a good question. The big question: where will we put the provenance? There are two possibilities:\r\n\r\n1. Add a field in each constructor TyThing recording the provenance (this feels like a disruptive to an otherwise very simple union)\r\n2. Add a field to each of the constructors Id, ConLike, TyCon, CoAxiom (this involves a lot more typing, but these constructors already have lots of fields so it's not as disruptive)\r\n\r\nThe provenance will, for now, look something like:\r\n\r\n{{{\r\nnewtype TyThingSrc = TyThingSrc {\r\n tyThingFromBoot :: Bool\r\n }\r\n}}}\r\n\r\nand then `TcIface` will be extended to know if we're in boot and will fill things in accordingly.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14543Broken links to docs all over the web2019-07-07T18:16:34ZSimon Hengelsol@typeful.netBroken links to docs all over the webExample: https://downloads.haskell.org/\~ghc/latest/docs/html/users_guide/type-families.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version ...Example: https://downloads.haskell.org/\~ghc/latest/docs/html/users_guide/type-families.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"Broken links all over the web","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Example: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/type-families.html","type_of_failure":"OtherFailure","blocking":[]} -->Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/14535ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple...2020-10-05T22:12:17ZiTotallyExistghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): stack depth overflowI created a neural network library within haskell. I was able to create, test, and train the net (using data from the mNist dataset). I could only test manually (try one input at a time and compare the two outputs), so i made a function ...I created a neural network library within haskell. I was able to create, test, and train the net (using data from the mNist dataset). I could only test manually (try one input at a time and compare the two outputs), so i made a function which allowed me to test many test inputs on the net at once.
Recreating bug:
first, load main.hs in ghci (duh)
then, run the entirety of trainedNetwork.txt as a command to initialise the network (i.e. copy paste the file into the ghci command line)
then run the entirety of test.txt as a command. Here you will get the error.
To test with different input values for the function "test" (the function whose being run caused the crash), you can open the jupyter notebook and run the function mnistTest with higher or lower values (higher using more test cases, lower using less) and run the output of that function as a command in haskell. (i know from testing that 41 inputs does not cause a crash, but 42 does (seriously, this is not a joke)) .
What i know is not the problem/probably causes:
I know that y was initiliased correctly.
The function being run here is :
```hs
--takes in a network and an array of test inputs and their corresponding outputs and returns the accuracy of the network
--only works for classification networks
testClassification :: [Layer] -> [[Double]] -> [[Double]] -> Double
testClassification net inputs outputs = testClassificationHelper net inputs outputs 0 0
testClassificationHelper :: [Layer] -> [[Double]] -> [[Double]] -> Double -> Double -> Double
testClassificationHelper _ [] _ correct incorrect = (correct/(correct+incorrect))
testClassificationHelper net (input:inputs) (output:outputs) correct incorrect | netMax == outMax = next (correct+1) incorrect
| otherwise = next correct (incorrect+1)
where
next = testClassificationHelper net inputs outputs
netMax = greatestIndex (getOutput net input)
outMax = greatestIndex output
```
I know that getOutput and greatestIndex work\\\\
I know that it works with a small amount of inputs (test3.txt is essentially the same command except instead of using the first 100 test examples of the mnist data set, it uses the first 3)\\\\
I know that it works when using the first 30 data points, but not with the first 50.\\\\
I know that doing it for the first 30 inputs only takes 2 seconds and 270 MB, while training the network took 40 minutes and 820GB, take from that what you will\\\\
Note: trainedNetwork.txt is too large to upload, so it is available at https://drive.google.com/open?id=1HfCNknZ9AfJauQoNwzhlEwsQfcHTya0thttps://gitlab.haskell.org/ghc/ghc/-/issues/14533Make GHC more robust against PC crashes by using atomic writes2021-03-02T16:58:07ZNiklas Hambüchenmail@nh2.meMake GHC more robust against PC crashes by using atomic writesYesterday my Windows machine crashed when ghc was building, left me with a lot of corrupted .hi files (and probably .o files as well).
That made me think if we should change ghc to write its output with atomic moves.
Discussion on `#gh...Yesterday my Windows machine crashed when ghc was building, left me with a lot of corrupted .hi files (and probably .o files as well).
That made me think if we should change ghc to write its output with atomic moves.
Discussion on `#ghc`:
```
bgamari:
nh2: well, perhaps
I'm not sure it's terribly common for compilers to take such precautions though
and if we were to do it for interface files then presumably we would also want to do it for object files
siarheit_:
that would be very nice
geekosaur:
compilers in general are happy to write out incomplete/garbage object files
bgamari:
it seems that way
nh2:
bgamari: right, if we wanted to do it we should do it for all files ghc writes.
Possible that other compilers can also write garbage, but maybe ghc can do better -- one less thing the developer has to think about
Phyx-:
most compilers also don't do the aggressive recompilation avoidance things we do either..
corrupt hi files wouldn't be an issue if the next time it would override them :)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make GHC more robust against PC crashes by using atomic writes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2"],"type":"Bug","description":"Yesterday my Windows machine crashed when ghc was building, left me with a lot of corrupted .hi files (and probably .o files as well).\r\n\r\nThat made me think if we should change ghc to write its output with atomic moves.\r\n\r\nDiscussion on `#ghc`:\r\n\r\n{{{\r\nbgamari:\r\nnh2: well, perhaps\r\nI'm not sure it's terribly common for compilers to take such precautions though\r\nand if we were to do it for interface files then presumably we would also want to do it for object files\r\n\r\nsiarheit_:\r\nthat would be very nice\r\n\r\ngeekosaur:\r\ncompilers in general are happy to write out incomplete/garbage object files\r\n\r\nbgamari:\r\nit seems that way\r\n\r\nnh2:\r\nbgamari: right, if we wanted to do it we should do it for all files ghc writes.\r\nPossible that other compilers can also write garbage, but maybe ghc can do better -- one less thing the developer has to think about\r\n\r\nPhyx-:\r\nmost compilers also don't do the aggressive recompilation avoidance things we do either..\r\ncorrupt hi files wouldn't be an issue if the next time it would override them :)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14527Warn on recursive bindings2020-05-23T17:01:16ZChris DoneWarn on recursive bindingsWhen you accidentally write something like `let x = .. x ...` it can take hours to realize where you made your mistake. This hits me once in a while, and my colleagues often.
I'd propose e.g. `-Wrecursive-bindings` that says:
```
warni...When you accidentally write something like `let x = .. x ...` it can take hours to realize where you made your mistake. This hits me once in a while, and my colleagues often.
I'd propose e.g. `-Wrecursive-bindings` that says:
```
warning: [-Wrecursive-bindings]
Recursive binding for `x` in
let x = length x
```
This applies to `let`, `where` and top-level pattern bindings.
I believe that in practice, I only actually use real recursive bindings once in a while. So I might be bold enough to encourage enabling it in `-Wall` for a future major GHC release.
With the compromise that if you have the warning enabled but in one specific place, you want a recursive binding, you can use the `~` tilde to say "I really mean it", e.g.
`let ~ones = 1 : ones`
That seems like a nice balance to say "I know what I'm doing in this case". So the warning could be more helpful, like:
```
warning: [-Wrecursive-bindings]
Recursive binding for `ones` in
let ones = length ones
If intentional, use the tilde marker on the name like this:
let ~ones = length ones
```
In Intero if I were to implement a prototype of this check, I'd probably do this, after renaming:
1. Use SYB to collect all variable bindings from the pattern.
1. Use SYB to listify all mentions of any of these variables in the RHS and any guards or where clauses.
If the list is non-empty, then trigger the error. A transformation function `[Name] -> Pat -> Pat` would provide the AST with the offending name(s) tilded as `~x` for use in the error message.
If there's general agreement, I could implement this change.
- \*EDIT\*\*: mutually recursive bindings apply here too. So `let x = y; y = x` by a regular occurs check.https://gitlab.haskell.org/ghc/ghc/-/issues/14523Confusing link error when specifying the same object repeatedly2020-06-16T07:51:49ZNeil MitchellConfusing link error when specifying the same object repeatedlyGiven `foo.hs` containing `main = print 1` and `foo.c` containing `void foo(){} `, if you run:
```
$ ghc foo.o foo.hs
C:\Neil\temp\dupe-name>ghc foo.hs foo.o
[1 of 1] Compiling Main ( foo.hs, foo.o )
Linking foo.exe ...
foo....Given `foo.hs` containing `main = print 1` and `foo.c` containing `void foo(){} `, if you run:
```
$ ghc foo.o foo.hs
C:\Neil\temp\dupe-name>ghc foo.hs foo.o
[1 of 1] Compiling Main ( foo.hs, foo.o )
Linking foo.exe ...
foo.o:fake:(.data+0x0): multiple definition of `__stginit_Main'
foo.o:fake:(.data+0x0): first defined here
foo.o:fake:(.data+0x10): multiple definition of `Main_main_closure'
foo.o:fake:(.data+0x10): first defined here
foo.o:fake:(.text+0x18): multiple definition of `Main_main_info'
foo.o:fake:(.text+0x18): first defined here
foo.o:fake:(.data+0x30): multiple definition of `ZCMain_main_closure'
foo.o:fake:(.data+0x30): first defined here
foo.o:fake:(.text+0x88): multiple definition of `ZCMain_main_info'
foo.o:fake:(.text+0x88): first defined here
foo.o:fake:(.data+0x70): multiple definition of `Main_zdtrModule_closure'
foo.o:fake:(.data+0x70): first defined here
collect2.exe: error: ld returned 1 exit status
`gcc.exe' failed in phase `Linker'. (Exit code: 1)
```
It seems GHC compiles both `foo.hs` and `foo.c` to `foo.o`, and then links `foo.o` twice. Sometimes `foo.hs` writes last, sometimes `foo.c` so the error can change. I found the error quite confusing, until I realised what it was doing.
One solution might be before linking `.o` files GHC does `canonicalizePath` on all the object files, and if any are duplicates, it raises a cleaner error. That check would also catch `ghc foo.hs bar.o bar.o` as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.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":"Confusing link error when specifying the same object repeatedly","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Given {{{foo.hs}}} containing {{{main = print 1}}} and {{{foo.c}}} containing {{{void foo(){} }}}, if you run:\r\n\r\n{{{\r\n$ ghc foo.o foo.hs\r\nC:\\Neil\\temp\\dupe-name>ghc foo.hs foo.o\r\n[1 of 1] Compiling Main ( foo.hs, foo.o )\r\nLinking foo.exe ...\r\nfoo.o:fake:(.data+0x0): multiple definition of `__stginit_Main'\r\nfoo.o:fake:(.data+0x0): first defined here\r\nfoo.o:fake:(.data+0x10): multiple definition of `Main_main_closure'\r\nfoo.o:fake:(.data+0x10): first defined here\r\nfoo.o:fake:(.text+0x18): multiple definition of `Main_main_info'\r\nfoo.o:fake:(.text+0x18): first defined here\r\nfoo.o:fake:(.data+0x30): multiple definition of `ZCMain_main_closure'\r\nfoo.o:fake:(.data+0x30): first defined here\r\nfoo.o:fake:(.text+0x88): multiple definition of `ZCMain_main_info'\r\nfoo.o:fake:(.text+0x88): first defined here\r\nfoo.o:fake:(.data+0x70): multiple definition of `Main_zdtrModule_closure'\r\nfoo.o:fake:(.data+0x70): first defined here\r\ncollect2.exe: error: ld returned 1 exit status\r\n`gcc.exe' failed in phase `Linker'. (Exit code: 1)\r\n}}}\r\n\r\nIt seems GHC compiles both {{{foo.hs}}} and {{{foo.c}}} to {{{foo.o}}}, and then links {{{foo.o}}} twice. Sometimes {{{foo.hs}}} writes last, sometimes {{{foo.c}}} so the error can change. I found the error quite confusing, until I realised what it was doing.\r\n\r\nOne solution might be before linking {{{.o}}} files GHC does {{{canonicalizePath}}} on all the object files, and if any are duplicates, it raises a cleaner error. That check would also catch {{{ghc foo.hs bar.o bar.o}}} as well.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14522GHC recompilation checker doesn't take account of deprecated pragmas2019-07-07T18:16:40ZNeil MitchellGHC recompilation checker doesn't take account of deprecated pragmasGiven the sources:
```hs
-- A.hs --------------------
module A
-- {-# DEPRECATED "bad" #-}
where
a = 1
```
```hs
-- B.hs --------------------
module B where
import A
```
I get the interactions:
```
$ ghc B
[1 of 2] Compiling A ...Given the sources:
```hs
-- A.hs --------------------
module A
-- {-# DEPRECATED "bad" #-}
where
a = 1
```
```hs
-- B.hs --------------------
module B where
import A
```
I get the interactions:
```
$ ghc B
[1 of 2] Compiling A ( A.hs, A.o )
[2 of 2] Compiling B ( B.hs, B.o )
$ manually edit A.hs to uncomment the deprecated line
$ ghc B
[1 of 2] Compiling A ( A.hs, A.o )
$ touch B.hs
$ ghc B
[2 of 2] Compiling B ( B.hs, B.o )
B.hs:2:1: warning: [-Wdeprecations] Module `A' is deprecated: bad
|
2 | import A
| ^^^^^^^^
```
Observe that after editing the deprecated pragma in `A.hs` GHC didn't recompile `B.hs`, meaning that the warning only appeared after I touch'd `B.hs`. Turning on `-Werror` turns the problem from one of incorrectly missing warnings to one of incorrect compilation results.
I was also got the same results when adding a deprecated pragma to an individual function.
My guess is whatever `.hi` hash you take for recompilation checking should include deprecated pragmas.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC recompilation checker doesn't take account of deprecated pragmas","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"Given the sources:\r\n\r\n{{{#!hs\r\n-- A.hs --------------------\r\nmodule A\r\n-- {-# DEPRECATED \"bad\" #-}\r\n where\r\na = 1\r\n}}}\r\n\r\n{{{#!hs\r\n-- B.hs --------------------\r\nmodule B where\r\nimport A\r\n}}}\r\n\r\nI get the interactions:\r\n\r\n{{{\r\n$ ghc B\r\n[1 of 2] Compiling A ( A.hs, A.o )\r\n[2 of 2] Compiling B ( B.hs, B.o )\r\n\r\n$ manually edit A.hs to uncomment the deprecated line\r\n\r\n$ ghc B\r\n[1 of 2] Compiling A ( A.hs, A.o )\r\n\r\n$ touch B.hs\r\n\r\n$ ghc B\r\n[2 of 2] Compiling B ( B.hs, B.o )\r\n\r\nB.hs:2:1: warning: [-Wdeprecations] Module `A' is deprecated: bad\r\n |\r\n2 | import A\r\n | ^^^^^^^^\r\n}}}\r\n\r\nObserve that after editing the deprecated pragma in {{{A.hs}}} GHC didn't recompile {{{B.hs}}}, meaning that the warning only appeared after I touch'd {{{B.hs}}}. Turning on {{{-Werror}}} turns the problem from one of incorrectly missing warnings to one of incorrect compilation results.\r\n\r\nI was also got the same results when adding a deprecated pragma to an individual function.\r\n\r\nMy guess is whatever {{{.hi}}} hash you take for recompilation checking should include deprecated pragmas.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14514Error messages: suggest annotating with higher-rank kind2019-07-07T18:16:43ZIcelandjackError messages: suggest annotating with higher-rank kindThe ticket below was posted because of confusion around higher-rank kinds. [ticket:14514\#comment:145571](https://gitlab.haskell.org//ghc/ghc/issues/14514#note_145571) suggests an error-message improvement, which I (goldfire) think is fe...The ticket below was posted because of confusion around higher-rank kinds. [ticket:14514\#comment:145571](https://gitlab.haskell.org//ghc/ghc/issues/14514#note_145571) suggests an error-message improvement, which I (goldfire) think is feasible.
------------------------------------
Following code from [Richard's 2016 Haskell Implementors' Workshop talk](https://github.com/goldfirere/triptych/blob/2e21a6be4419873c77a02c9a198379c76947b94c/extensibility/Extensible6.hs) (/ [Trees That Grow](https://arxiv.org/abs/1610.04799)) works just fine
```hs
{-# Language RankNTypes, KindSignatures, DataKinds, TypeFamilyDependencies, TypeInType #-}
import Data.Kind
data TagTag = ETagTag | PTagTag
data ETag = VarTag
data PTag = VarPTag
type family
Tag (ttag::TagTag) = (res :: Type) | res -> ttag where
Tag ETagTag = ETag
Tag PTagTag = PTag
type WithAnyTag = forall tag. Tag tag -> Type
-- data Exp (ext::WithAnyTag) where
-- Var :: ext VarTag -> Exp ext
data Exp (ext::WithAnyTag) = Var (ext VarTag)
```
but replace `data Exp` with its commented-out GADT brethren and it stops working
```
$ ghci -ignore-dot-ghci Weird.hs
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( Weird.hs, interpreted )
Weird.hs:17:28: error:
• Expected kind ‘WithAnyTag’, but ‘ext1’ has kind ‘ETag -> *’
• In the first argument of ‘Exp’, namely ‘ext’
In the type ‘Exp ext’
In the definition of data constructor ‘Var’
|
17 | Var :: ext VarTag -> Exp ext
| ^^^
Failed, 0 modules loaded.
Prelude>
```
The type synonym can be inlined, makes no difference.