GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:33:25Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/10869Option to dump preprocessed source2019-07-07T18:33:25ZphischuOption to dump preprocessed sourceIt would be awesome if GHC had an option `-ddump-preprocessed` that dumps the source code for each module after preprocessing. I am not sure what the current definition of "preprocessing" is but I mean the output of at least the followin...It would be awesome if GHC had an option `-ddump-preprocessed` that dumps the source code for each module after preprocessing. I am not sure what the current definition of "preprocessing" is but I mean the output of at least the following tools: happy, alex, c2hs, hsc2hs and cpp. Additionally even if a module was not subject to any preprocessing it should be dumped anyway.
Use case: I want to parse module files from packages from hackage with `haskell-src-exts` but find it prohibitively difficult to get the preprocessing right. The idea is that after `cabal install` with ghc options `-ddump-preprocessed -ddump-to-file -dumpdir real_modules` you get a complete working set of haskell modules that can be parsed directly without any preprocessing in folder `real_modules`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Option to dump preprocessed source","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It would be awesome if GHC had an option `-ddump-preprocessed` that dumps the source code for each module after preprocessing. I am not sure what the current definition of \"preprocessing\" is but I mean the output of at least the following tools: happy, alex, c2hs, hsc2hs and cpp. Additionally even if a module was not subject to any preprocessing it should be dumped anyway.\r\n\r\nUse case: I want to parse module files from packages from hackage with `haskell-src-exts` but find it prohibitively difficult to get the preprocessing right. The idea is that after `cabal install` with ghc options `-ddump-preprocessed -ddump-to-file -dumpdir real_modules` you get a complete working set of haskell modules that can be parsed directly without any preprocessing in folder `real_modules`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/2600Bind type variables in RULES2019-07-07T19:07:44ZSimon Peyton JonesBind type variables in RULESRoman writes: here's an example I came across while working on the recycling paper
and which I subsequently forgot about. Suppose we have:
```
{-# LANGUAGE Rank2Types #-}
module T where
class T t where
to :: [a] -> t a
from :: ...Roman writes: here's an example I came across while working on the recycling paper
and which I subsequently forgot about. Suppose we have:
```
{-# LANGUAGE Rank2Types #-}
module T where
class T t where
to :: [a] -> t a
from :: t a -> [a]
tmap :: (a -> a) -> t a -> t a
{-# RULES
"myrule" forall f x.
from (tmap f (to x)) = map f (from (to x))
#-}
```
Alas, this fails with:
```
Ambiguous type variable `t' in the constraint:
`T t' arising from a use of `to' at T.hs:12:40-43
Probable fix: add a type signature that fixes these type variable(s)
```
Of course, I'd like the t on the rhs to be the same as on the lhs but
I don't see how to tell this to GHC. Is it actually possible? The only
solution I've found was to add a dummy argument to 'to':
```
to' :: t a -> [a] -> t a
to = to' undefined
{-# RULES
"myrule" forall f t x.
from (tmap f (to' t x)) = map f (from (to' t x))
#-}
```
That's ugly, of course. Am I missing something or is this just
impossible to do with the current system?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Bind type variables in RULES","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"Roman writes: here's an example I came across while working on the recycling paper\r\nand which I subsequently forgot about. Suppose we have:\r\n{{{\r\n{-# LANGUAGE Rank2Types #-}\r\nmodule T where\r\n\r\nclass T t where\r\n to :: [a] -> t a\r\n from :: t a -> [a]\r\n tmap :: (a -> a) -> t a -> t a\r\n\r\n{-# RULES\r\n\r\n\"myrule\" forall f x.\r\n from (tmap f (to x)) = map f (from (to x))\r\n #-}\r\n}}}\r\nAlas, this fails with:\r\n{{{\r\n Ambiguous type variable `t' in the constraint:\r\n `T t' arising from a use of `to' at T.hs:12:40-43\r\n Probable fix: add a type signature that fixes these type variable(s)\r\n}}}\r\nOf course, I'd like the t on the rhs to be the same as on the lhs but\r\nI don't see how to tell this to GHC. Is it actually possible? The only\r\nsolution I've found was to add a dummy argument to 'to':\r\n{{{\r\nto' :: t a -> [a] -> t a\r\n\r\nto = to' undefined\r\n\r\n{-# RULES\r\n\r\n\"myrule\" forall f t x.\r\n from (tmap f (to' t x)) = map f (from (to' t x))\r\n #-}\r\n}}}\r\nThat's ugly, of course. Am I missing something or is this just\r\nimpossible to do with the current system?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/16689Safe Haskell warnings don't recognize pragmas2019-07-07T18:00:05ZSamuel MaySafe Haskell warnings don't recognize pragmas# Summary
When compiled with `-Wsafe` or `-Wunsafe`, the warning will be printed whenever a module is inferred as either (untested, but that might be every module). This includes when an explicit safety annotation has been included in ...# Summary
When compiled with `-Wsafe` or `-Wunsafe`, the warning will be printed whenever a module is inferred as either (untested, but that might be every module). This includes when an explicit safety annotation has been included in the file, in which case the author can be presumed to know whether or not it's safe.
Glaringly, the warning message says "[the module] has been inferred as safe!" when it is actually *explicitly* safe, no inference necessary. While this is mostly just an annoyance, if `-Werror` is also passed, there is no way to actually make the compilation succeed.
# Steps to reproduce
Add either the `{-# LANGUAGE Safe #-}` or the `{-# LANGUAGE Unsafe #-}` pragma to any module according to its safety, and rebuild with `-Wsafe` or `-Wunsafe` passed to GHC.
# Expected behavior
Assuming the annotation is correct for the module, it should be compiled with no warnings (or at least no more than it does without the flag).
# Environment
* GHC version used: 8.6.48.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16394GHC internal error while typechecking of instance definition2019-07-07T18:00:15ZDay1721GHC internal error while typechecking of instance definitionHello. \\\\
This code won't typecheck because of GHC internal error.
```hs
{-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-}
class C a where
type T (n :: a)
-- v--DIFF--v
instance C a => C b => C (a, b) where
type T '(...Hello. \\\\
This code won't typecheck because of GHC internal error.
```hs
{-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-}
class C a where
type T (n :: a)
-- v--DIFF--v
instance C a => C b => C (a, b) where
type T '(n, m) = (T n, T m)
```
with error message:
```
Bug.hs:7:10: error:
• GHC internal error: ‘T’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [a1LS :-> Type variable ‘a’ = a :: *,
a1LT :-> Type variable ‘b’ = b :: *]
• In the type instance declaration for ‘T’
In the instance declaration for ‘C b => C (a, b)’
|
7 | type T (n, m) = (T n, T m)
| ^
Failed, no modules loaded.
```
but this works fine:
```hs
{-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-}
class C a where
type T (n :: a)
-- v--DIFF--v
instance (C a, C b) => C (a, b) where
type T '(n, m) = (T n, T m)
```
Not sure is a bug, but either way it would be better to make more understandable error message
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC internal error while typechecking of instance definition","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello. \\\\\r\nThis code won't typecheck because of GHC internal error.\r\n\r\n{{{#!hs\r\n{-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-}\r\n\r\nclass C a where\r\n type T (n :: a)\r\n\r\n-- v--DIFF--v\r\ninstance C a => C b => C (a, b) where\r\n type T '(n, m) = (T n, T m)\r\n}}}\r\n\r\nwith error message: \r\n{{{\r\nBug.hs:7:10: error:\r\n • GHC internal error: ‘T’ is not in scope during type checking, but it passed the renamer\r\n tcl_env of environment: [a1LS :-> Type variable ‘a’ = a :: *,\r\n a1LT :-> Type variable ‘b’ = b :: *]\r\n • In the type instance declaration for ‘T’\r\n In the instance declaration for ‘C b => C (a, b)’\r\n |\r\n7 | type T (n, m) = (T n, T m)\r\n | ^\r\nFailed, no modules loaded.\r\n\r\n}}}\r\n\r\nbut this works fine:\r\n{{{#!hs\r\n{-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-}\r\n\r\nclass C a where\r\n type T (n :: a)\r\n\r\n-- v--DIFF--v\r\ninstance (C a, C b) => C (a, b) where\r\n type T '(n, m) = (T n, T m)\r\n}}}\r\n\r\nNot sure is a bug, but either way it would be better to make more understandable error message","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15624defer-type-errors and equality constraints2019-07-07T18:03:42ZKrzysztof Gogolewskidefer-type-errors and equality constraintsConsider
```
{-# OPTIONS_GHC -fdefer-type-errors #-}
x = const True ('a' + 'a')
y = const True (not 'a')
```
Currently `x` is True, but `y` is undefined. I think it would make sense for both to be True.
<details><summary>Trac metadata...Consider
```
{-# OPTIONS_GHC -fdefer-type-errors #-}
x = const True ('a' + 'a')
y = const True (not 'a')
```
Currently `x` is True, but `y` is undefined. I think it would make sense for both to be True.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"defer-type-errors and equality constraints","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider\r\n\r\n{{{\r\n{-# OPTIONS_GHC -fdefer-type-errors #-}\r\nx = const True ('a' + 'a')\r\ny = const True (not 'a')\r\n}}}\r\n\r\nCurrently `x` is True, but `y` is undefined. I think it would make sense for both to be True.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/14225"No module named ... is imported" message is a bit misleading with qualified ...2021-05-18T22:18:12ZBen Gamari"No module named ... is imported" message is a bit misleading with qualified importsIt seems that the `No module named ... is imported` message produced in response to out-of-scope identifiers doesn't account for qualified imports. For instance,
```
$ ghci
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
L...It seems that the `No module named ... is imported` message produced in response to out-of-scope identifiers doesn't account for qualified imports. For instance,
```
$ ghci
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/ben/.ghci
λ> import qualified Data.Maybe as M
λ> M.fromJusr
<interactive>:2:1: error:
Not in scope: ‘M.fromJusr’
Perhaps you meant ‘M.fromJust’ (imported from Data.Maybe)
No module named ‘M’ is imported.
λ>
```
I suppose there is the question of whether we consider `M` to be a "module" here; I would argue that I imported it and therefore the message is at very least a bit misleading.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"No module named ... is imported\" message is a bit misleading with qualified imports","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":"It seems that the `No module named ... is imported` message produced in response to out-of-scope identifiers doesn't account for qualified imports. For instance,\r\n\r\n{{{\r\n$ ghci\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/ben/.ghci\r\nλ> import qualified Data.Maybe as M\r\nλ> M.fromJusr\r\n\r\n<interactive>:2:1: error:\r\n Not in scope: ‘M.fromJusr’\r\n Perhaps you meant ‘M.fromJust’ (imported from Data.Maybe)\r\n No module named ‘M’ is imported.\r\nλ> \r\n}}}\r\n\r\nI suppose there is the question of whether we consider `M` to be a \"module\" here; I would argue that I imported it and therefore the message is at very least a bit misleading.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/12525Internal identifiers creeping into :show bindings2019-07-07T18:26:14ZmniipInternal identifiers creeping into :show bindingsWhen binding variables the "new" way, or defining typeclasses, some things that are better left unseen manage to creep into the `:show Bindings` list.
```html
<pre class="wiki">
GHCi, version 8.1.20160725: http://www.haskell.org/ghc/ :...When binding variables the "new" way, or defining typeclasses, some things that are better left unseen manage to creep into the `:show Bindings` list.
```html
<pre class="wiki">
GHCi, version 8.1.20160725: http://www.haskell.org/ghc/ :? for help
> :show bindings
> x = ()
> :show bindings
<b>$trModule :: GHC.Types.Module = _</b>
x :: () = _
> class Foo a
> :show bindings
x :: () = _
class Foo a
<b>$tcFoo :: GHC.Types.TyCon = _
$tc'C:Foo :: GHC.Types.TyCon = _
$trModule :: GHC.Types.Module = _</b>
</pre>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Internal identifiers creeping into :show bindings","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When binding variables the \"new\" way, or defining typeclasses, some things that are better left unseen manage to creep into the `:show Bindings` list.\r\n\r\n{{{#!html\r\n<pre class=\"wiki\">\r\nGHCi, version 8.1.20160725: http://www.haskell.org/ghc/ :? for help\r\n> :show bindings\r\n> x = ()\r\n> :show bindings\r\n<b>$trModule :: GHC.Types.Module = _</b>\r\nx :: () = _\r\n> class Foo a\r\n> :show bindings\r\nx :: () = _\r\nclass Foo a\r\n<b>$tcFoo :: GHC.Types.TyCon = _\r\n$tc'C:Foo :: GHC.Types.TyCon = _\r\n$trModule :: GHC.Types.Module = _</b>\r\n</pre>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/10930missing empty-Enumeration and out-of-range warning for `Natural`2019-07-07T18:33:00ZHerbert Valerio Riedelhvr@gnu.orgmissing empty-Enumeration and out-of-range warning for `Natural````
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
λ:2> :set -XNegativeLiterals
λ:3> (-123) :: Word
<interactive>:3:2: Warning: Literal -123 is out of the Word range 0..18446744073709551615
18446744073709551493
it :: Wo...```
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
λ:2> :set -XNegativeLiterals
λ:3> (-123) :: Word
<interactive>:3:2: Warning: Literal -123 is out of the Word range 0..18446744073709551615
18446744073709551493
it :: Word
λ:4> (-123) :: Numeric.Natural.Natural
*** Exception: arithmetic underflow
λ:5>
λ:6> [10..3] :: [Word]
<interactive>:6:1: Warning: Enumeration is empty
[]
it :: [Word]
λ:7> [10..3] :: [Numeric.Natural.Natural]
[]
it :: [GHC.Natural.Natural]
```8.8.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/4861Documentation for base does not include special items2019-07-07T18:58:10ZNeil MitchellDocumentation for base does not include special itemsThe documentation for base does not include tuples, lists or arrow. I realise these are special in Haskell, but it seems a shame they aren't documented.
For tuples, the documentation for base doesn't include them in either Prelude or Da...The documentation for base does not include tuples, lists or arrow. I realise these are special in Haskell, but it seems a shame they aren't documented.
For tuples, the documentation for base doesn't include them in either Prelude or Data.Tuple, but the documentation for ghc-prim includes them in GHC.Unit and GHC.Tuple. I think the lack of documentation for tuple types is a bug, since it would be relatively easy for them to be documented, and does make the documentation more complete.
For lists (\[\], (:)), there is no documentation in either base or ghc-prim. It would be nice if they were documented in Prelude and Data.List, but not if it was too much effort (I can imagine that Haddock can't accept list definitions).
For the arrow type -\>, it's unclear if it can reasonably be documented, so it might be worth thinking about but probably not bothering to document.
The reason I'm interested in ensuring complete documentation is that Hoogle currently doesn't know about tuple constructors in the base library, but it does know about them in ghc-prim, which seems wrong.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Documentation for base does not include special items","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"The documentation for base does not include tuples, lists or arrow. I realise these are special in Haskell, but it seems a shame they aren't documented.\r\n\r\nFor tuples, the documentation for base doesn't include them in either Prelude or Data.Tuple, but the documentation for ghc-prim includes them in GHC.Unit and GHC.Tuple. I think the lack of documentation for tuple types is a bug, since it would be relatively easy for them to be documented, and does make the documentation more complete.\r\n\r\nFor lists ([], (:)), there is no documentation in either base or ghc-prim. It would be nice if they were documented in Prelude and Data.List, but not if it was too much effort (I can imagine that Haddock can't accept list definitions).\r\n\r\nFor the arrow type ->, it's unclear if it can reasonably be documented, so it might be worth thinking about but probably not bothering to document.\r\n\r\nThe reason I'm interested in ensuring complete documentation is that Hoogle currently doesn't know about tuple constructors in the base library, but it does know about them in ghc-prim, which seems wrong.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/15363Do some cleaning up of the testsuite driver2019-07-07T18:12:59ZlanttiDo some cleaning up of the testsuite driverWhen trying to understand the GHC test suite I noticed some small improvements that I could do to it. This would probably work nicely as my first task on GHC:
Rewrite the timeout.hs in python, it is used for Windows runs but it doesn't ...When trying to understand the GHC test suite I noticed some small improvements that I could do to it. This would probably work nicely as my first task on GHC:
Rewrite the timeout.hs in python, it is used for Windows runs but it doesn't seem to do anything that would strictly need the Haskell libraries to be used and it is the only part of the test suite driver that is not written in python.
Or;
See if the timeout scripts could be eliminated altogether as the python subprocess module that we are using can now (since python 3.3) handle timeouts by itself and using the timeout scripts effectively doubles the number of processes we need to create for each test case. Notice that the timeout scripts do more than just generating the timeout.8.8.1lanttilanttihttps://gitlab.haskell.org/ghc/ghc/-/issues/14534Split T12971 into its own Makefile2019-07-07T18:16:37ZDavid FeuerSplit T12971 into its own Makefile`testsuite/tests/driver/Makefile` includes the `T12971` target. This (intentionally) has non-ASCII characters in it. As a result, any change to that makefile will trigger a lint error. We should give that test its own makefile to isolate...`testsuite/tests/driver/Makefile` includes the `T12971` target. This (intentionally) has non-ASCII characters in it. As a result, any change to that makefile will trigger a lint error. We should give that test its own makefile to isolate it a bit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Split T12971 into its own Makefile","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"`testsuite/tests/driver/Makefile` includes the `T12971` target. This (intentionally) has non-ASCII characters in it. As a result, any change to that makefile will trigger a lint error. We should give that test its own makefile to isolate it a bit.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/13477Turn cIntegerLibraryType into a dynflag2020-01-17T09:03:27ZJoachim Breitnermail@joachim-breitner.deTurn cIntegerLibraryType into a dynflagCurrently, at configure time we tell GHC whether integers are built using `integer-gmp` or `integer-simple`, and this gets baked in via the global constant `cIntegerLibraryType`.
This is all fine for normal use of GHC (the program), but...Currently, at configure time we tell GHC whether integers are built using `integer-gmp` or `integer-simple`, and this gets baked in via the global constant `cIntegerLibraryType`.
This is all fine for normal use of GHC (the program), but users of ghc (the library) might want to have more leeway here.
A good solution seems to be turn this into a dynflag setting, so that users of the GHC API can adjust that as fit. From a cursory glance at the code, this does not seem to be a big problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Turn cIntegerLibraryType into a dynflag","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Currently, at configure time we tell GHC whether integers are built using `integer-gmp` or `integer-simple`, and this gets baked in via the global constant `cIntegerLibraryType`.\r\n\r\nThis is all fine for normal use of GHC (the program), but users of ghc (the library) might want to have more leeway here.\r\n\r\nA good solution seems to be turn this into a dynflag setting, so that users of the GHC API can adjust that as fit. From a cursory glance at the code, this does not seem to be a big problem.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1