GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:05:26Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/3094Some GHC.* module should export word size and heap object header size2019-07-07T19:05:26ZduncanSome GHC.* module should export word size and heap object header sizeSome code, like `bytestring`, uses magic constants to help it decide how much memory to allocate. This is not a correctness issue, just an optimisation one. It allows the `bytestring` package to allocate buffers that make optimal use of ...Some code, like `bytestring`, uses magic constants to help it decide how much memory to allocate. This is not a correctness issue, just an optimisation one. It allows the `bytestring` package to allocate buffers that make optimal use of ghc's pinned allocator strategy which has to use a whole number of 4k pages. The magic is in subtracting the heap object header size:
```
-- | Currently set to 32k, less the memory management overhead
defaultChunkSize :: Int
defaultChunkSize = 32 * k - chunkOverhead
where k = 1024
-- | Currently set to 4k, less the memory management overhead
smallChunkSize :: Int
smallChunkSize = 4 * k - chunkOverhead
where k = 1024
-- | The memory management overhead. Currently this is tuned for GHC only.
chunkOverhead :: Int
chunkOverhead = 2 * sizeOf (undefined :: Int)
```
This works for normal builds but for profiling builds it is a couple words off which wastes memory. It would also be be nice if it did not have to use magic constants but if it could import them from `GHC.Exts` or something.
We would want:
- Heap object header size, in words (currently 2 normally or 4 for profiling)
- Word size (4 or 8 bytes)
- Heap block size (currently 4k)
These should all be actual Haskell constants so that they inline perfectly into calculations with no runtime overhead. The heap object header size is obviously different between profiling and normal, however this works out ok because we have to recompile for profiling anyway.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Some GHC.* module should export word size and heap object header size","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Some code, like `bytestring`, uses magic constants to help it decide how much memory to allocate. This is not a correctness issue, just an optimisation one. It allows the `bytestring` package to allocate buffers that make optimal use of ghc's pinned allocator strategy which has to use a whole number of 4k pages. The magic is in subtracting the heap object header size:\r\n\r\n{{{\r\n-- | Currently set to 32k, less the memory management overhead\r\ndefaultChunkSize :: Int\r\ndefaultChunkSize = 32 * k - chunkOverhead\r\n where k = 1024\r\n\r\n-- | Currently set to 4k, less the memory management overhead\r\nsmallChunkSize :: Int\r\nsmallChunkSize = 4 * k - chunkOverhead\r\n where k = 1024\r\n\r\n-- | The memory management overhead. Currently this is tuned for GHC only.\r\nchunkOverhead :: Int\r\nchunkOverhead = 2 * sizeOf (undefined :: Int)\r\n}}}\r\n\r\nThis works for normal builds but for profiling builds it is a couple words off which wastes memory. It would also be be nice if it did not have to use magic constants but if it could import them from `GHC.Exts` or something.\r\n\r\nWe would want:\r\n\r\n * Heap object header size, in words (currently 2 normally or 4 for profiling)\r\n * Word size (4 or 8 bytes)\r\n * Heap block size (currently 4k)\r\n\r\nThese should all be actual Haskell constants so that they inline perfectly into calculations with no runtime overhead. The heap object header size is obviously different between profiling and normal, however this works out ok because we have to recompile for profiling anyway.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/5611Asynchronous exception discarded after safe FFI call2019-07-07T18:54:23ZjoeyadamsAsynchronous exception discarded after safe FFI call**Note:** This bug appears to be fixed already, as it does not appear with GHC 7.2.1 . I'm submitting a bug report anyway, to document its presence.
The bug is: when an asynchronous exception is thrown to a thread making a (safe) foreig...**Note:** This bug appears to be fixed already, as it does not appear with GHC 7.2.1 . I'm submitting a bug report anyway, to document its presence.
The bug is: when an asynchronous exception is thrown to a thread making a (safe) foreign call, the thread throwing the exception blocks like it should, but then the exception isn't actually delivered. For example:
```haskell
{-# LANGUAGE ForeignFunctionInterface #-}
import Control.Concurrent
import Foreign.C
import System.IO
foreign import ccall safe "unistd.h sleep"
sleep :: CUInt -> IO CUInt
main :: IO ()
main = do
hSetBuffering stdout LineBuffering
tid <- forkIO $ do
putStrLn "child: Sleeping"
_ <- sleep 1
-- The following lines should not happen after the killThread from the
-- parent thread completes. However, they do...
putStrLn "child: Done sleeping"
threadDelay 1000000
putStrLn "child: Done waiting"
threadDelay 100000
putStrLn $ "parent: Throwing exception to thread " ++ show tid
throwTo tid $ userError "Exception delivered successfully"
putStrLn "parent: Done throwing exception"
threadDelay 2000000
```
When the bug is present, the program prints:
```
child: Sleeping
parent: Throwing exception to thread ThreadId 4
child: Done sleeping
parent: Done throwing exception
child: Done waiting
```
"child: Done waiting" should not be printed after completion of the throwTo, and the exception message should appear. On GHC 7.2.1, the program prints:
```
child: Sleeping
parent: Throwing exception to thread ThreadId 4
parent: Done throwing exception
ffi-sleep: user error (Exception delivered successfully)
```
This bug has been reproduced in GHC 7.0.3, on both Linux and Windows. It has also been reproduced on GHC 7.0.4.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| 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":"Asynchronous exception discarded after safe FFI call","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["FFI,","exception"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"'''Note:''' This bug appears to be fixed already, as it does not appear with GHC 7.2.1 . I'm submitting a bug report anyway, to document its presence.\r\n\r\nThe bug is: when an asynchronous exception is thrown to a thread making a (safe) foreign call, the thread throwing the exception blocks like it should, but then the exception isn't actually delivered. For example:\r\n\r\n{{{\r\n\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\n\r\nimport Control.Concurrent\r\nimport Foreign.C\r\nimport System.IO\r\n\r\nforeign import ccall safe \"unistd.h sleep\"\r\n sleep :: CUInt -> IO CUInt\r\n\r\nmain :: IO ()\r\nmain = do\r\n hSetBuffering stdout LineBuffering\r\n\r\n tid <- forkIO $ do\r\n putStrLn \"child: Sleeping\"\r\n _ <- sleep 1\r\n\r\n -- The following lines should not happen after the killThread from the\r\n -- parent thread completes. However, they do...\r\n putStrLn \"child: Done sleeping\"\r\n threadDelay 1000000\r\n putStrLn \"child: Done waiting\"\r\n\r\n threadDelay 100000\r\n putStrLn $ \"parent: Throwing exception to thread \" ++ show tid\r\n throwTo tid $ userError \"Exception delivered successfully\"\r\n putStrLn \"parent: Done throwing exception\"\r\n\r\n threadDelay 2000000\r\n}}}\r\n\r\nWhen the bug is present, the program prints:\r\n\r\n{{{\r\nchild: Sleeping\r\nparent: Throwing exception to thread ThreadId 4\r\nchild: Done sleeping\r\nparent: Done throwing exception\r\nchild: Done waiting\r\n}}}\r\n\r\n\"child: Done waiting\" should not be printed after completion of the throwTo, and the exception message should appear. On GHC 7.2.1, the program prints:\r\n\r\n{{{\r\nchild: Sleeping\r\nparent: Throwing exception to thread ThreadId 4\r\nparent: Done throwing exception\r\nffi-sleep: user error (Exception delivered successfully)\r\n}}}\r\n\r\nThis bug has been reproduced in GHC 7.0.3, on both Linux and Windows. It has also been reproduced on GHC 7.0.4.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7273Binary size increase in nofib/grep between 7.6.1 and HEAD2019-07-07T18:50:34ZSimon MarlowBinary size increase in nofib/grep between 7.6.1 and HEADWhile browsing the nofib results comparing 7.6.1 and HEAD today, I noticed that binary sizes for `grep` are significantly larger in HEAD:
```
grep
Main 34706 +31.3%
Parsers 5791...While browsing the nofib results comparing 7.6.1 and HEAD today, I noticed that binary sizes for `grep` are significantly larger in HEAD:
```
grep
Main 34706 +31.3%
Parsers 5791 +3.2%
StringMatch 28227 +36.9%
```
The increase seems to be happening in the simplifier, going by the code-size stats generated by `-v`. This probably warrants investigation before 7.8.1.
Binary sizes are slightly larger across the board (1-2%), which is at least partly due to the new code generator, however performance is slightly better (2-3%), if these numbers are to be believed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Binary size increase in nofib/grep between 7.6.1 and HEAD","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While browsing the nofib results comparing 7.6.1 and HEAD today, I noticed that binary sizes for `grep` are significantly larger in HEAD:\r\n\r\n{{{\r\ngrep\r\n Main 34706 +31.3%\r\n Parsers 5791 +3.2%\r\n StringMatch 28227 +36.9%\r\n}}}\r\n\r\nThe increase seems to be happening in the simplifier, going by the code-size stats generated by `-v`. This probably warrants investigation before 7.8.1.\r\n\r\nBinary sizes are slightly larger across the board (1-2%), which is at least partly due to the new code generator, however performance is slightly better (2-3%), if these numbers are to be believed.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/8281The impossible happened: primRepToFFIType2023-01-20T21:12:40ZtibbeThe impossible happened: primRepToFFITypeI ran into this error while trying to use GHCi on the hashable package:
```
$ cabal repl
Preprocessing library hashable-1.2.0.10...
GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... d...I ran into this error while trying to use GHCi on the hashable package:
```
$ cabal repl
Preprocessing library hashable-1.2.0.10...
GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package text-0.11.3.1 ... linking ... done.
Loading object (static) dist/build/cbits/fnv.o ... done
Loading object (static) dist/build/cbits/getRandomBytes.o ... done
final link ... done
[1 of 4] Compiling Data.Hashable.RandomSource ( Data/Hashable/RandomSource.hs, interpreted ) [flags changed]
[2 of 4] Compiling Data.Hashable.Class ( Data/Hashable/Class.hs, interpreted ) [flags changed]
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.2 for x86_64-apple-darwin):
primRepToFFIType
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"The impossible happened: primRepToFFIType","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I ran into this error while trying to use GHCi on the hashable package:\r\n\r\n{{{\r\n$ cabal repl\r\nPreprocessing library hashable-1.2.0.10...\r\nGHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package array-0.4.0.1 ... linking ... done.\r\nLoading package deepseq-1.3.0.1 ... linking ... done.\r\nLoading package bytestring-0.10.0.2 ... linking ... done.\r\nLoading package text-0.11.3.1 ... linking ... done.\r\nLoading object (static) dist/build/cbits/fnv.o ... done\r\nLoading object (static) dist/build/cbits/getRandomBytes.o ... done\r\nfinal link ... done\r\n[1 of 4] Compiling Data.Hashable.RandomSource ( Data/Hashable/RandomSource.hs, interpreted ) [flags changed]\r\n[2 of 4] Compiling Data.Hashable.Class ( Data/Hashable/Class.hs, interpreted ) [flags changed]\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.6.2 for x86_64-apple-darwin):\r\n\tprimRepToFFIType\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/10068Make the runtime reflection API for names, modules, locations more systematic2019-07-07T18:37:41ZSimon Peyton JonesMake the runtime reflection API for names, modules, locations more systematicCurrently in `base` we have
- `GHC.SrcLoc`: the data type `SrcLoc` contains `srcLocPackage` and `srcLocModule`
- `Data.Typeable.Internals`: the data type `TyCon` contains `tyConPackage`, `tyConModule` and `tyConName`.
- `GHC.Generics`: ...Currently in `base` we have
- `GHC.SrcLoc`: the data type `SrcLoc` contains `srcLocPackage` and `srcLocModule`
- `Data.Typeable.Internals`: the data type `TyCon` contains `tyConPackage`, `tyConModule` and `tyConName`.
- `GHC.Generics`: the data type `Datatype` contains `dataTypePackage`, `dataTypeModule` and `dataTypeName`
- `Data.Data`: the data type `DataType` (yes the capitalisation differs!) contains a field `tycon :: String`, and there are functions `tyconModule :: String -> String`, and `tyconUQname :: String -> String`, for parsing that string and extracting the module name and tycon name.
- `GHC.StaticPtr`: the data type `StaticPtrInfo` contains `spInfoPackageKey`, `spInfoModuleName`, `spInfoName` (all `String`s). Oh, and `spInfoSrcLoc :: (Int,Int)` too!
- `GHC.Stack.ccSrcSpan :: Ptr CostCentre -> IO CString` stores a source location in a C structure, and returns it as a `CString`.
This is madness! Six different representations for the same information in one package!
Let's fix this by defining some shared data types, for
- `Module` = `ModuleName` + package
- `Entity` = `Module` + unqualified name
There would be a tiresome changeover period; but `Typeable` and `StaticPtr` are in flux anyway.
Would anyone be willing to lead on this?8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/10141CUSK mysteries2019-07-07T18:37:21ZRichard Eisenbergrae@richarde.devCUSK mysteriesTake the following definition:
```hs
type family G (a :: k) where
G Int = Bool
G Bool = Int
G a = a
```
It compiles in 7.8.3, but not in 7.10.1 RC2. This makes me sad. I will fix.
(Found by Jan Stolarek.)Take the following definition:
```hs
type family G (a :: k) where
G Int = Bool
G Bool = Int
G a = a
```
It compiles in 7.8.3, but not in 7.10.1 RC2. This makes me sad. I will fix.
(Found by Jan Stolarek.)8.6.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/10189explicit promotions of prefix data constructors can't be parsed naturally2023-06-16T21:25:26Zshiatsumatexplicit promotions of prefix data constructors can't be parsed naturallyWhen used as an infix operator, a data constructor is explicitly promoted simply with `'` prefixed, but when used as a prefix operator enclosed between `(` and `)`, it is explicitly promoted only with `'` put before `(`, not before the c...When used as an infix operator, a data constructor is explicitly promoted simply with `'` prefixed, but when used as a prefix operator enclosed between `(` and `)`, it is explicitly promoted only with `'` put before `(`, not before the constructor.
On the other hand, messages of GHC and GHCi indicate that a data constructor operator in a prefix form is promoted by putting `'` before the constructor! (as in `forall (k :: BOX) (k :: BOX). (':*)` below.)
I believe that this is a matter of parsing. The parser should admit `(':*)` as well as `'(:*)` for the naturalness of the syntax.
In a GHCi:
```hs
> :set -XDataKinds -XTypeOperators
> data a :* b = a :* b
> :kind! Int :* Int
Int :* Int :: *
= Int :* Int
> :kind! Int ':* Int
Int ':* Int :: * :* *
= Int ':* Int
> :kind! (:*)
(:*) :: * -> * -> *
= (:*)
> :kind! '(:*)
'(:*) :: k -> k1 -> k :* k1
= forall (k :: BOX) (k :: BOX). (':*)
> :kind! (':*)
<interactive>:1:3: parse error on input ‘:*’
```8.6.1shiatsumatshiatsumathttps://gitlab.haskell.org/ghc/ghc/-/issues/10346Cross-module SpecConstr2022-05-12T20:34:01ZSimon Peyton JonesCross-module SpecConstrType-class specialisation now happens flawlessly across modules. That is, if I define
```
module DefineF where
f :: Num a => a -> a
{-# INLINEABLE f #-}
f x = ...f x'....
```
then modules that import `DefineF` and call `f` at ...Type-class specialisation now happens flawlessly across modules. That is, if I define
```
module DefineF where
f :: Num a => a -> a
{-# INLINEABLE f #-}
f x = ...f x'....
```
then modules that import `DefineF` and call `f` at some particular type (say `Int`) will generate a specialised copy of `f`'s code.
But this does not happen for `SpecConstr`; we only specialise a function for calls made in the same module. For example:
```
module M where
{-# INLINABLE foo #-}
foo True y = y
foo False (a,b) = foo True (a+b,b)
module X where
import M
bar = ...(foo (x,y))...
```
Here `foo` is called with an explicit `(x,y)` argument in module `X`, and we'd like to !SpecConstr it, as it would be if the call was in module `M`.
All the infrastructure is in place to allow cross-module `SpecConstr`; it just hasn't been done yet. This ticket is to record the idea.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/10506SourceNotes are not applied to all identifiers2019-07-07T18:35:38ZEric SeidelSourceNotes are not applied to all identifiersCompiling
```
module Foo where
foo x = x + 1
bar y = foo y
```
with `-g` produces
```
$ ghc -g -ddump-ticked test.hs
[1 of 1] Compiling Foo ( test.hs, test.o )
AbsBinds [a_avC] [$dNum_avD]
{Exports: [foo <= foo_amB
...Compiling
```
module Foo where
foo x = x + 1
bar y = foo y
```
with `-g` produces
```
$ ghc -g -ddump-ticked test.hs
[1 of 1] Compiling Foo ( test.hs, test.o )
AbsBinds [a_avC] [$dNum_avD]
{Exports: [foo <= foo_amB
<>]
Exported types: foo :: forall a_avC. Num a_avC => a_avC -> a_avC
[LclId, Str=DmdType]
Binds: -- ticks = [src<test.hs:3:1-13>]
foo_amB x_alA
= src<test.hs:3:9-13> (+)
src<test.hs:3:9> x_alA src<test.hs:3:13> 1}
AbsBinds [a_avV] [$dNum_avW]
{Exports: [bar <= bar_avN
<>]
Exported types: bar :: forall a_avV. Num a_avV => a_avV -> a_avV
[LclId, Str=DmdType]
Binds: -- ticks = [src<test.hs:5:1-13>]
bar_avN y_amz = src<test.hs:5:9-13> foo (src<test.hs:5:13> y_amz)}
```
Note that neither the occurrence of `(+)` in `foo`, nor the occurrence of `foo` in `bar` have their own Ticks. Instead they are only covered by the Tick for the entire application `x + 1` (resp. `foo y`).
I'm trying to use the new SourceNote infrastructure to map CoreExprs back to their original source location, but unfortunately I need these locations for each identifier in the source.
Would it be reasonable to add a SourceNote to each occurrence of an identifier?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"SourceNotes are not applied to all identifiers","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.10.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling\r\n\r\n{{{\r\nmodule Foo where\r\n\r\nfoo x = x + 1\r\n\r\nbar y = foo y\r\n}}}\r\n\r\nwith `-g` produces\r\n\r\n{{{\r\n$ ghc -g -ddump-ticked test.hs\r\n[1 of 1] Compiling Foo ( test.hs, test.o )\r\nAbsBinds [a_avC] [$dNum_avD]\r\n {Exports: [foo <= foo_amB\r\n <>]\r\n Exported types: foo :: forall a_avC. Num a_avC => a_avC -> a_avC\r\n [LclId, Str=DmdType]\r\n Binds: -- ticks = [src<test.hs:3:1-13>]\r\n foo_amB x_alA\r\n = src<test.hs:3:9-13> (+)\r\n src<test.hs:3:9> x_alA src<test.hs:3:13> 1}\r\nAbsBinds [a_avV] [$dNum_avW]\r\n {Exports: [bar <= bar_avN\r\n <>]\r\n Exported types: bar :: forall a_avV. Num a_avV => a_avV -> a_avV\r\n [LclId, Str=DmdType]\r\n Binds: -- ticks = [src<test.hs:5:1-13>]\r\n bar_avN y_amz = src<test.hs:5:9-13> foo (src<test.hs:5:13> y_amz)}\r\n}}}\r\n\r\nNote that neither the occurrence of `(+)` in `foo`, nor the occurrence of `foo` in `bar` have their own Ticks. Instead they are only covered by the Tick for the entire application `x + 1` (resp. `foo y`).\r\n\r\nI'm trying to use the new SourceNote infrastructure to map CoreExprs back to their original source location, but unfortunately I need these locations for each identifier in the source.\r\n\r\nWould it be reasonable to add a SourceNote to each occurrence of an identifier?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/10640Document prim-ops2020-10-29T18:21:00ZBen GamariDocument prim-opsCurrently documentation is quite scarce for many primops (particularly the BCO operations).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version ...Currently documentation is quite scarce for many primops (particularly the BCO operations).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Document prim-ops","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently documentation is quite scarce for many primops (particularly the BCO operations).","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/10915Statistical profiling support in the RTS2023-11-25T22:03:34ZBen GamariStatistical profiling support in the RTSNow since GHC can produce useful debugging information (e.g. DWARF annotations and source notes) in compiled objects, it would great if we could leverage this for more efficient profiling.
While ideally we would be able to rely on exter...Now since GHC can produce useful debugging information (e.g. DWARF annotations and source notes) in compiled objects, it would great if we could leverage this for more efficient profiling.
While ideally we would be able to rely on external tools like `perf` for this task, this would require that the STG stack be walkable like a standard C stack.
A more feasible alternative is to incorporate a simple statistical profiler into the RTS.
Profiling is defined loosely here as the collection of information describing the current state of evaluation in response to certain triggers. In practice this will be the collection of the current symbol being evaluated triggered on a few events of interest,
- Memory allocation
- Periodic timers for time-based profiling
- Blackhole blocking for locating performance problems due to sharing in parallel programs8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/10933REMOVED pragma2022-03-22T18:32:58ZRichard Eisenbergrae@richarde.devREMOVED pragmaSay I have a function that's been deprecated for some time. Then I remove it. Some clients will still use the now-missing function. It would be nice to give a helpful error message, instead of a "symbol not found" error.
I thus propose ...Say I have a function that's been deprecated for some time. Then I remove it. Some clients will still use the now-missing function. It would be nice to give a helpful error message, instead of a "symbol not found" error.
I thus propose a `REMOVED` pragma. The syntax is identical to `DEPRECATED`, except for the name of the pragma. Whenever a `REMOVED` function is mentioned, the error message includes the string from the pragma. (This includes trying to define a `REMOVED` class method in an instance.)
See https://gitlab.haskell.org/ghc/ghc/-/wikis/design/deprecation-mechanisms for more info and related efforts.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| 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":"REMOVED pragma","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Say I have a function that's been deprecated for some time. Then I remove it. Some clients will still use the now-missing function. It would be nice to give a helpful error message, instead of a \"symbol not found\" error.\r\n\r\nI thus propose a `REMOVED` pragma. The syntax is identical to `DEPRECATED`, except for the name of the pragma. Whenever a `REMOVED` function is mentioned, the error message includes the string from the pragma. (This includes trying to define a `REMOVED` class method in an instance.)\r\n\r\nSee Design/DeprecationMechanisms for more info and related efforts.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/11238Redesign the dynamic linking on ELF systems2019-12-02T17:21:22ZPeter Trommlerptrommler@acm.orgRedesign the dynamic linking on ELF systemsThis ticket is to follow up on my comment on #11042.
Let's give dynamic linking on ELF systems a second chance.
I propose the following steps:
1. Collect required features
1. Write up and discuss and agree on a specification
1. Creat...This ticket is to follow up on my comment on #11042.
Let's give dynamic linking on ELF systems a second chance.
I propose the following steps:
1. Collect required features
1. Write up and discuss and agree on a specification
1. Create regression tests for all features
1. Design and implement a new dynamic linker for GHCi
1. (optional) Make it work on Mac OS X too
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.10.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Redesign the dynamic linking on ELF systems","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"trommler"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"This ticket is to follow up on my comment on #11042.\r\n\r\nLet's give dynamic linking on ELF systems a second chance. \r\n\r\nI propose the following steps:\r\n1. Collect required features\r\n1. Write up and discuss and agree on a specification \r\n1. Create regression tests for all features\r\n1. Design and implement a new dynamic linker for GHCi\r\n1. (optional) Make it work on Mac OS X too","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/11495TH_spliceE5_prof is failing with release candidate 8.0.12020-09-18T20:58:53ZThomas MiedemaTH_spliceE5_prof is failing with release candidate 8.0.1`TH_spliceE5_prof` looks like this:
```
TH_spliceE5_prof::
$(RM) TH_spliceE5_prof*.o TH_spliceE5_prof*.hi TH_spliceE5_prof*.dyn_o TH_spliceE5_prof*.dyn_hi TH_spliceE5_prof
'$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) $(ghcThWayFlags) --mak...`TH_spliceE5_prof` looks like this:
```
TH_spliceE5_prof::
$(RM) TH_spliceE5_prof*.o TH_spliceE5_prof*.hi TH_spliceE5_prof*.dyn_o TH_spliceE5_prof*.dyn_hi TH_spliceE5_prof
'$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) $(ghcThWayFlags) --make -v0 TH_spliceE5_prof.hs -c
'$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) --make -v0 TH_spliceE5_prof.hs -prof -auto-all -osuf .p.o -o $@
./$@
```
In 4905b83a2d448c65ccced385343d4e8124548a3b, Simon added that `$(ghcThWayFlags)` to the first compilation command. With a release compiler, `ghcThWayFlags` defaults to `-dynamic`. But compiling with `-dynamic` doesn't produce `.dyn_o` files (you need `-dynamic-too` for that, which is enabled by `-XTemplateHaskell`, but \*\*not\*\* when compiling with `-dynamic`), so the second compilation results in:
```
TH_spliceE5_prof.hs:8:17: fatal:
cannot find object file ‘./TH_spliceE5_prof_Lib.dyn_o’
while linking an interpreted expression
make[1]: *** [TH_spliceE5_prof] Error 1
*** unexpected failure for TH_spliceE5_prof(normal)
```
Not passing `-dynamic` fixes the test. But in the function `failNonStd` in `compiler/ghci/Linker.hs` Simon suggests that passing `-dynamic` is necessary:
```
Cannot load -prof objects when GHC is built with -dynamic
To fix this, either:
(1) Use -fexternal-interprter, or
(2) Build the program twice: once with -dynamic, and then
with -prof using -osuf to set a different object file suffix.
```
Some ideas for a solution:
- change that message to not mention `-dynamic`
- always turn on `-dynamic-too` when `-XTemplateHaskell` is on, also when using `-dynamic`
- find the place where `.dyn_o` is expected, and teach it that `.o` might also be ok.
- make `-fexternal-interpreter` the default. Delete the test and a whole bunch of other stuff.
It's all such a mess.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/11765Allow documentary type signatures2019-07-07T18:28:39ZDavid FeuerAllow documentary type signaturesIn some cases (e.g., `lens`) it's useful to document a binding with a more specific type signature than the true one, to show a useful special case. Unfortunately, this documentation can potentially be wrong or go out of date. I'd like t...In some cases (e.g., `lens`) it's useful to document a binding with a more specific type signature than the true one, to show a useful special case. Unfortunately, this documentation can potentially be wrong or go out of date. I'd like to propose a pragma for this:
```hs
{-# Documentary #-} f :: T -> U
```
would ask the type checker to verify that `f :: T -> U`. Specifically, it would have the effect of creating and type checking, but then discarding, a hidden binding
```hs
f_doc :: T -> U
f_doc t = f t
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.10.3 |
| Type | FeatureRequest |
| 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":"Allow documentary type signatures","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"In some cases (e.g., `lens`) it's useful to document a binding with a more specific type signature than the true one, to show a useful special case. Unfortunately, this documentation can potentially be wrong or go out of date. I'd like to propose a pragma for this:\r\n\r\n{{{#!hs\r\n{-# Documentary #-} f :: T -> U\r\n}}}\r\n\r\nwould ask the type checker to verify that `f :: T -> U`. Specifically, it would have the effect of creating and type checking, but then discarding, a hidden binding\r\n\r\n{{{#!hs\r\nf_doc :: T -> U\r\nf_doc t = f t\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/11773linux/powepc : ghc-stage1 segfaults when building unregisterised2019-07-07T18:28:36Zerikdlinux/powepc : ghc-stage1 segfaults when building unregisterisedBuilding unregisterised to test code paths that don't get tested in the registerised compile mode.
The segfault:
```
"inplace/bin/ghc-stage1" -static -O -H64m -Wall -Iincludes -Iincludes/dist \
-Iincludes/dist-derivedconstants/heade...Building unregisterised to test code paths that don't get tested in the registerised compile mode.
The segfault:
```
"inplace/bin/ghc-stage1" -static -O -H64m -Wall -Iincludes -Iincludes/dist \
-Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header \
-Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP \
-dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen \
-Irts/dist/build -Irts/dist/build/autogen -O2 -Wnoncanonical-monad-instances \
-c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o
```
seems to occur on powerpc, but not on x86_64 or armhf.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.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":"linux/powepc : ghc-stage1 segfaults when building unregisterised","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"erikd"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Building unregisterised to test code paths that don't get tested in the registerised compile mode. \r\n\r\nThe segfault:\r\n\r\n{{{\r\n\"inplace/bin/ghc-stage1\" -static -O -H64m -Wall -Iincludes -Iincludes/dist \\\r\n -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header \\\r\n -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP \\\r\n -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen \\\r\n -Irts/dist/build -Irts/dist/build/autogen -O2 -Wnoncanonical-monad-instances \\\r\n -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o\r\n}}}\r\n\r\nseems to occur on powerpc, but not on x86_64 or armhf.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1erikderikdhttps://gitlab.haskell.org/ghc/ghc/-/issues/12038Shutdown interacts badly with requestSync()2019-07-07T18:27:53ZSimon MarlowShutdown interacts badly with requestSync()I've been investigating #10860, and the problem goes pretty deep,
so I'm going to record what I know here and come back to fix it
properly later.
We have this mechanism `requestSync()` for operations that need
to seize control of the wh...I've been investigating #10860, and the problem goes pretty deep,
so I'm going to record what I know here and come back to fix it
properly later.
We have this mechanism `requestSync()` for operations that need
to seize control of the whole runtime to do something. It is used by
- `scheduleDoGC()`
- `setNumCapabilities()`
- `forkProcess()`
`requestSync()` ensures that only one of these operations wins,
the others will `yieldCapability()` to the winner, before
continuing with their own sync.
The problem is that this interacts badly with shutdown. Shutdown
might start at any time (initiated by `exitScheduler()`). If it
starts during a sync, then a deadlock is likely: some
capabilities will be already shut down, and cannot be acquired by
`acquireAllCapabilities()`. This happens in #10860.
Really, shutdown should play the `requestSync()` game too, but
that requires a lot of thought.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/12218Implement -fexternal-interpreter via static linking2023-06-13T08:00:25ZSimon MarlowImplement -fexternal-interpreter via static linkingAn interesting idea from \@hvr. When using `-fexternal-interpreter`, we can statically link the required packages and object files into a new `iserv` binary, and use that as our external interpreter.
This would mean we could support TH ...An interesting idea from \@hvr. When using `-fexternal-interpreter`, we can statically link the required packages and object files into a new `iserv` binary, and use that as our external interpreter.
This would mean we could support TH and even limited GHCi without needing a dynamic linker of any kind, which is extremely cool. Apparently this would be useful for AIX where doing dynamic linking is hard.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/1243720% regression in max_bytes_used for T19692020-01-23T16:18:02ZSimon Marlow20% regression in max_bytes_used for T1969This is 20% worse:
```
=====> T1969(normal) 1 of 1 [0, 0, 0]
cd "./T1969.run" && "/data/users/smarlow/ghc/inplace/test spaces/ghc-stage2" -c T1969.hs -dno-debug-output -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fs...This is 20% worse:
```
=====> T1969(normal) 1 of 1 [0, 0, 0]
cd "./T1969.run" && "/data/users/smarlow/ghc/inplace/test spaces/ghc-stage2" -c T1969.hs -dno-debug-output -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups +RTS -G1 -RTS +RTS -V0 -tT1969.comp.stats --machine-readable -RTS
max_bytes_used value is too high:
Expected T1969(normal) max_bytes_used: 15017528 +/-15%
Lower bound T1969(normal) max_bytes_used: 12764898
Upper bound T1969(normal) max_bytes_used: 17270158
Actual T1969(normal) max_bytes_used: 18071064
Deviation T1969(normal) max_bytes_used: 20.3 %
*** unexpected stat test failure for T1969(normal)
```
One of these patches is the culprit, but I can't tell from the build logs because the build was broken between these two points:
```
commit 6a4dc891fa7a8024d8f9f03b98ad675ff5fcbd91
Author: Ömer Sinan Ağacan <omeragacan@gmail.com>
Bump Haddock submodule
commit 8d4760fb7b20682cb5e470b24801301cfbbdce3b
Author: Simon Peyton Jones <simonpj@microsoft.com>
Comments re ApThunks + small refactor in mkRhsClosure
commit 9c54185b26922d88e516942aad946f05f707d7ce
Author: Simon Peyton Jones <simonpj@microsoft.com>
Comments + tiny refactor of isNullarySrcDataCon
commit a09c0e3e68c96882a1fb392c9dbeea84056bf32f
Author: Simon Peyton Jones <simonpj@microsoft.com>
Comments only
commit 714bebff44076061d0a719c4eda2cfd213b7ac3d
Author: Ömer Sinan Ağacan <omeragacan@gmail.com>
Implement unboxed sum primitive type
```
The patch immediately preceding this sequence does not have the failure: https://phabricator.haskell.org/rGHC83e4f49577665278fe08fbaafe2239553f3c448e (follow the link to the build)
and the final patch in this sequence \*does\* have the failure: https://phabricator.haskell.org/rGHC6a4dc891fa7a8024d8f9f03b98ad675ff5fcbd91 (along with an improvement in T9675)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"20% regression in max_bytes_used for T1969","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"osa1"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonpj"],"type":"Bug","description":"This is 20% worse:\r\n\r\n{{{\r\n=====> T1969(normal) 1 of 1 [0, 0, 0]\r\ncd \"./T1969.run\" && \"/data/users/smarlow/ghc/inplace/test spaces/ghc-stage2\" -c T1969.hs -dno-debug-output -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups +RTS -G1 -RTS +RTS -V0 -tT1969.comp.stats --machine-readable -RTS\r\nmax_bytes_used value is too high:\r\n Expected T1969(normal) max_bytes_used: 15017528 +/-15%\r\n Lower bound T1969(normal) max_bytes_used: 12764898 \r\n Upper bound T1969(normal) max_bytes_used: 17270158 \r\n Actual T1969(normal) max_bytes_used: 18071064 \r\n Deviation T1969(normal) max_bytes_used: 20.3 %\r\n*** unexpected stat test failure for T1969(normal)\r\n}}}\r\n\r\nOne of these patches is the culprit, but I can't tell from the build logs because the build was broken between these two points:\r\n\r\n{{{\r\ncommit 6a4dc891fa7a8024d8f9f03b98ad675ff5fcbd91\r\nAuthor: Ömer Sinan Ağacan <omeragacan@gmail.com>\r\n\r\n Bump Haddock submodule\r\n\r\ncommit 8d4760fb7b20682cb5e470b24801301cfbbdce3b\r\nAuthor: Simon Peyton Jones <simonpj@microsoft.com>\r\n\r\n Comments re ApThunks + small refactor in mkRhsClosure\r\n\r\ncommit 9c54185b26922d88e516942aad946f05f707d7ce\r\nAuthor: Simon Peyton Jones <simonpj@microsoft.com>\r\n\r\n Comments + tiny refactor of isNullarySrcDataCon\r\n\r\ncommit a09c0e3e68c96882a1fb392c9dbeea84056bf32f\r\nAuthor: Simon Peyton Jones <simonpj@microsoft.com>\r\n\r\n Comments only\r\n\r\ncommit 714bebff44076061d0a719c4eda2cfd213b7ac3d\r\nAuthor: Ömer Sinan Ağacan <omeragacan@gmail.com>\r\n\r\n Implement unboxed sum primitive type\r\n}}}\r\n\r\nThe patch immediately preceding this sequence does not have the failure: https://phabricator.haskell.org/rGHC83e4f49577665278fe08fbaafe2239553f3c448e (follow the link to the build)\r\n\r\nand the final patch in this sequence *does* have the failure: https://phabricator.haskell.org/rGHC6a4dc891fa7a8024d8f9f03b98ad675ff5fcbd91 (along with an improvement in T9675)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/12498Support unconventionally named import libraries2019-07-07T18:26:21ZTamar ChristinaSupport unconventionally named import librariesGHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use.
Instead we should look at the presence of ...GHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use.
Instead we should look at the presence of certain patterns. e.g. .o files contain only `.idata` sections etc.
This would allow us to be able to support import libraries such as `gcc_s` and no longer need to hardcode the GCC library full name in cabal file.
This should add more compatibility with packages on hackage.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support unconventionally named import libraries","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use.\r\n\r\nInstead we should look at the presence of certain patterns. e.g. .o files contain only `.idata` sections etc.\r\n\r\nThis would allow us to be able to support import libraries such as `gcc_s` and no longer need to hardcode the GCC library full name in cabal file. \r\n\r\nThis should add more compatibility with packages on hackage.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Tamar ChristinaTamar Christina