GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-05-18T22:18:12Zhttps://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/15611scope errors lie about what modules are imported2021-05-18T21:55:32Zdmwitscope errors lie about what modules are importedHere's Test.hs:
```
module Test where
```
And here's a ghci session:
```
% ghci Test.hs
GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help
*Test> Test.foo
<interactive>:1:1: error:
Not in scope: ‘Test.foo’
No modul...Here's Test.hs:
```
module Test where
```
And here's a ghci session:
```
% ghci Test.hs
GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help
*Test> Test.foo
<interactive>:1:1: error:
Not in scope: ‘Test.foo’
No module named ‘Test’ is imported.
```
That "No module named ‘Test’ is imported." part seems blatantly wrong (and persists even if I explicitly `import Test` rather than using the implicit loading of the module).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.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":"scope errors lie about what modules are imported","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here's Test.hs:\r\n\r\n{{{\r\nmodule Test where\r\n}}}\r\n\r\nAnd here's a ghci session:\r\n\r\n{{{\r\n% ghci Test.hs\r\nGHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help\r\n*Test> Test.foo\r\n\r\n<interactive>:1:1: error:\r\n Not in scope: ‘Test.foo’\r\n No module named ‘Test’ is imported.\r\n}}}\r\n\r\nThat \"No module named ‘Test’ is imported.\" part seems blatantly wrong (and persists even if I explicitly `import Test` rather than using the implicit loading of the module).","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/11647GHCi does not honour implicit `module Main (main) where` for re-exported `main`s2019-11-03T20:24:49ZHerbert Valerio Riedelhvr@gnu.orgGHCi does not honour implicit `module Main (main) where` for re-exported `main`sHaskell2010 states:
> An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be `module Main(main) where`.
Consider the following two modules:
```hs
-- module Main (m...Haskell2010 states:
> An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be `module Main(main) where`.
Consider the following two modules:
```hs
-- module Main (main) where
import Main2 (main)
```
```hs
module Main2 (main) where
main :: IO ()
main = return ()
```
A non-interactive GHC happily compiles `ghc --make Main`, however, GHCi fails with
```
$ ghci Main.hs
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
unknown option: 'c'
[1 of 2] Compiling Main2 ( Main2.hs, interpreted )
[2 of 2] Compiling Main ( Main.hs, interpreted )
Main.hs:1:1: The IO action ‘main’ is not exported by module ‘Main’
Failed, modules loaded: Main2.
```
For GHCi we need to uncomment the explicit `module Main (main) where` line to make it work.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi does not honour implicit `module Main (main) where` for re-exported `main`s","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Haskell2010 states:\r\n\r\n> An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be `module Main(main) where`.\r\n\r\n\r\nConsider the following two modules:\r\n\r\n{{{#!hs\r\n-- module Main (main) where\r\nimport Main2 (main)\r\n}}}\r\n\r\n{{{#!hs\r\nmodule Main2 (main) where\r\nmain :: IO ()\r\nmain = return ()\r\n}}}\r\n\r\nA non-interactive GHC happily compiles `ghc --make Main`, however, GHCi fails with\r\n\r\n{{{\r\n$ ghci Main.hs\r\nGHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help\r\nunknown option: 'c'\r\n[1 of 2] Compiling Main2 ( Main2.hs, interpreted )\r\n[2 of 2] Compiling Main ( Main.hs, interpreted )\r\n\r\nMain.hs:1:1: The IO action ‘main’ is not exported by module ‘Main’\r\nFailed, modules loaded: Main2.\r\n}}}\r\n\r\nFor GHCi we need to uncomment the explicit `module Main (main) where` line to make it work.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/10857"ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction2019-07-07T18:33:28Zrwbarton"ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restrictionCompare
```
rwbarton@morphism:/tmp$ ghci-7.10.1 -XMonomorphismRestriction
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
Prelude> let a = (+)
Prelude> :t a
a :: Num a => a -> a -> a
```
with
```
rwbarton@morphism:/tmp$...Compare
```
rwbarton@morphism:/tmp$ ghci-7.10.1 -XMonomorphismRestriction
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
Prelude> let a = (+)
Prelude> :t a
a :: Num a => a -> a -> a
```
with
```
rwbarton@morphism:/tmp$ ghci-7.10.1
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XMonomorphismRestriction
Prelude> let a = (+)
Prelude> :t a
a :: Integer -> Integer -> Integer
```
Confusing!
This also occurred in 7.8.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"ghci -XMonomorphismRestriction\" doesn't turn on the monomorphism restriction","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compare\r\n{{{\r\nrwbarton@morphism:/tmp$ ghci-7.10.1 -XMonomorphismRestriction\r\nGHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help\r\nPrelude> let a = (+)\r\nPrelude> :t a\r\na :: Num a => a -> a -> a\r\n}}}\r\nwith\r\n{{{\r\nrwbarton@morphism:/tmp$ ghci-7.10.1 \r\nGHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set -XMonomorphismRestriction\r\nPrelude> let a = (+)\r\nPrelude> :t a\r\na :: Integer -> Integer -> Integer\r\n}}}\r\nConfusing!\r\n\r\nThis also occurred in 7.8.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://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/11477Remove -Wamp2019-07-07T18:30:15ZBen GamariRemove -WampThis warning is intended as a temporary measure to aid the Applicative-Monad Proposal transition. It should be eventually removed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ------------------...This warning is intended as a temporary measure to aid the Applicative-Monad Proposal transition. It should be eventually removed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove -Wamp","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Task","description":"This warning is intended as a temporary measure to aid the Applicative-Monad Proposal transition. It should be eventually removed.","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/12625Bad error message for flags with required but missing arguments2019-07-07T18:25:48ZdramforeverBad error message for flags with required but missing arguments```
$ ghc -I
ghc: unrecognised flag: -I
did you mean one of:
-I
-F
-v
Usage: For basic information, try the `--help' option.
```
Which is confusing (Unrecognized `-I`. Did you mean `-I`?), and not informative (No mention of the m...```
$ ghc -I
ghc: unrecognised flag: -I
did you mean one of:
-I
-F
-v
Usage: For basic information, try the `--help' option.
```
Which is confusing (Unrecognized `-I`. Did you mean `-I`?), and not informative (No mention of the missing argument)
I expect something like "missing argument for `-I`", or a basic usage info on `-I` instead.
It looks similar to #9776 to me.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"Bad error message for flags with required but missing arguments","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ ghc -I\r\nghc: unrecognised flag: -I\r\ndid you mean one of:\r\n -I\r\n -F\r\n -v\r\n\r\nUsage: For basic information, try the `--help' option.\r\n}}}\r\n\r\nWhich is confusing (Unrecognized `-I`. Did you mean `-I`?), and not informative (No mention of the missing argument)\r\n\r\nI expect something like \"missing argument for `-I`\", or a basic usage info on `-I` instead.\r\n\r\nIt looks similar to #9776 to me.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/12674GHC doesn't handle ./ prefixed paths correctly2019-07-07T18:25:37ZdobenourGHC doesn't handle ./ prefixed paths correctlyGHC doesn't correctly handle paths preceded by `./` on the command line, if their first character (after any number of `./`s) is a `-`.
For instance, `ghc ./-a.hs` fails, even if `a.hs` exists.
Somewhere, `./-a.hs` is being converted t...GHC doesn't correctly handle paths preceded by `./` on the command line, if their first character (after any number of `./`s) is a `-`.
For instance, `ghc ./-a.hs` fails, even if `a.hs` exists.
Somewhere, `./-a.hs` is being converted to `-a.hs`. I have not been able to figure out where this happens.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"GHC doesn't handle ./ prefixed paths correctly","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC doesn't correctly handle paths preceded by `./` on the command line, if their first character (after any number of `./`s) is a `-`.\r\n\r\nFor instance, `ghc ./-a.hs` fails, even if `a.hs` exists.\r\n\r\nSomewhere, `./-a.hs` is being converted to `-a.hs`. I have not been able to figure out where this happens.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/13862Optional "-v" not allowed with :load in GHCi2019-07-07T18:19:47ZvantoOptional "-v" not allowed with :load in GHCiWhen loading a file in GHCi with the command `:load` and the file must import another file, if that other file is unavailable then GHCi sends the following error\\\\
```
Failed to load interface for `xxx`
Use -v to see a list of the fil...When loading a file in GHCi with the command `:load` and the file must import another file, if that other file is unavailable then GHCi sends the following error\\\\
```
Failed to load interface for `xxx`
Use -v to see a list of the files searched for.
```
' xxx ' is the name of the imported file that GHCi cannot find.\\\\
But we can not use a flag ( ie -v) with the command `:load` in GHCi.\\\\
This error is not appropriate in GHCi when using `:load`
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Optional \"-v\" not allowed with :load in GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When loading a file in GHCi with the command {{{:load}}} and the file must import another file, if that other file is unavailable then GHCi sends the following error\\\\\r\n\r\n{{{\r\nFailed to load interface for `xxx`\r\nUse -v to see a list of the files searched for.\r\n}}}\r\n' xxx ' is the name of the imported file that GHCi cannot find.\\\\\r\nBut we can not use a flag ( ie -v) with the command {{{:load}}} in GHCi.\\\\\r\nThis error is not appropriate in GHCi when using {{{:load}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/14452`-optc-O3` getting shadowed by automatically injected -O flags2019-07-07T18:16:59ZHerbert Valerio Riedelhvr@gnu.org`-optc-O3` getting shadowed by automatically injected -O flagsConsider the following example:
```hs
{-# LANGUAGE CApiFFI #-}
{-# OPTIONS_GHC -optc-O3 #-}
module M where
foreign import capi unsafe "stdlib.h exit" c_exit :: Int -> IO ()
```
However, the `-optc-O3` flag has no effect, unless `ghc...Consider the following example:
```hs
{-# LANGUAGE CApiFFI #-}
{-# OPTIONS_GHC -optc-O3 #-}
module M where
foreign import capi unsafe "stdlib.h exit" c_exit :: Int -> IO ()
```
However, the `-optc-O3` flag has no effect, unless `ghc` is called without any `-O` flags, or with `-O0`.
Here's the resulting C compiler invocations for different `-O` flags:
```
$ ghc -fforce-recomp -v -c m.hs |& grep O3
gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14023_0/ghc_2.c -o /tmp/ghc14023_0/ghc_3.s -Wimplicit -S -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include
```
```
$ ghc -fforce-recomp -O0 -v -c m.hs |& grep O3
gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14045_0/ghc_2.c -o /tmp/ghc14045_0/ghc_3.s -Wimplicit -S -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include
```
```
$ ghc -fforce-recomp -O1 -v -c m.hs |& grep O3
gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14073_0/ghc_2.c -o /tmp/ghc14073_0/ghc_3.s -Wimplicit -S -O -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include
```
```
$ ghc -fforce-recomp -O2 -v -c m.hs |& grep O3
gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14093_0/ghc_2.c -o /tmp/ghc14093_0/ghc_3.s -Wimplicit -S -O2 -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include
```
```
$ ghc -fforce-recomp -O3 -v -c m.hs |& grep O3
gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14119_0/ghc_2.c -o /tmp/ghc14119_0/ghc_3.s -Wimplicit -S -O2 -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include
```
To summarise, here's the resulting effective `-O`-level passed to `gcc`:
<table><tr><th> GHC invocation </th>
<th> GCC invocation </th>
<th> Effective C `-O`-level </th></tr>
<tr><td> `ghc` </td>
<td> `gcc -O3` </td>
<td> `-O3` </td></tr>
<tr><td> `ghc -O0` </td>
<td> `gcc -O3` </td>
<td> `-O3` </td></tr>
<tr><td> `ghc -O1` </td>
<td> `gcc -O3 -O1` </td>
<td> `-O1` </td></tr>
<tr><td> `ghc -O2` </td>
<td> `gcc -O3 -O2` </td>
<td> `-O2` </td></tr>
<tr><td> `ghc -O3` </td>
<td> `gcc -O3 -O2` </td>
<td> `-O2` </td></tr></table>
Consequently, the only way to have C code compiled with `-O3` is to force GHC into `-O0` mode; this is obviously not ideal, as it easily kills any benefit you'd gain from passing `-O3` to the C compiler... ;-)
I see a few alternatives on how to resolve this:
1. Have GHC recognise `-optc-O[0-9]` and suppress automatically injecting any `-O<n>` of its own
1. Have GHC inject its automatic `-O`-flags before user-provided `-optc` flags
1. Have GHC inject `-optc` flags as late as possible on the C compiler command-line
1. Implement a new variant of the `-optc` flag which injects its flags as late as possible on the C compiler command-line
<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":"`-optc-O3` getting shadowed by automatically injected -O flags","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":"Consider the following example:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE CApiFFI #-}\r\n\r\n{-# OPTIONS_GHC -optc-O3 #-}\r\n\r\nmodule M where\r\n\r\nforeign import capi unsafe \"stdlib.h exit\" c_exit :: Int -> IO ()\r\n}}}\r\n\r\nHowever, the `-optc-O3` flag has no effect, unless `ghc` is called without any `-O` flags, or with `-O0`.\r\n\r\n\r\nHere's the resulting C compiler invocations for different `-O` flags:\r\n\r\n{{{\r\n$ ghc -fforce-recomp -v -c m.hs |& grep O3\r\ngcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14023_0/ghc_2.c -o /tmp/ghc14023_0/ghc_3.s -Wimplicit -S -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include\r\n}}}\r\n\r\n{{{\r\n$ ghc -fforce-recomp -O0 -v -c m.hs |& grep O3\r\ngcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14045_0/ghc_2.c -o /tmp/ghc14045_0/ghc_3.s -Wimplicit -S -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include\r\n}}}\r\n\r\n{{{\r\n$ ghc -fforce-recomp -O1 -v -c m.hs |& grep O3\r\ngcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14073_0/ghc_2.c -o /tmp/ghc14073_0/ghc_3.s -Wimplicit -S -O -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include\r\n}}}\r\n\r\n{{{\r\n$ ghc -fforce-recomp -O2 -v -c m.hs |& grep O3\r\ngcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14093_0/ghc_2.c -o /tmp/ghc14093_0/ghc_3.s -Wimplicit -S -O2 -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include\r\n}}}\r\n\r\n{{{\r\n$ ghc -fforce-recomp -O3 -v -c m.hs |& grep O3\r\ngcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14119_0/ghc_2.c -o /tmp/ghc14119_0/ghc_3.s -Wimplicit -S -O2 -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include\r\n}}}\r\n\r\n\r\nTo summarise, here's the resulting effective `-O`-level passed to `gcc`:\r\n\r\n||= GHC invocation =||= GCC invocation =||= Effective C `-O`-level =||\r\n|| `ghc` || `gcc -O3` || `-O3` ||\r\n|| `ghc -O0` || `gcc -O3` || `-O3` ||\r\n|| `ghc -O1` || `gcc -O3 -O1` || `-O1` ||\r\n|| `ghc -O2` || `gcc -O3 -O2` || `-O2` ||\r\n|| `ghc -O3` || `gcc -O3 -O2` || `-O2` ||\r\n\r\n\r\n\r\nConsequently, the only way to have C code compiled with `-O3` is to force GHC into `-O0` mode; this is obviously not ideal, as it easily kills any benefit you'd gain from passing `-O3` to the C compiler... ;-)\r\n\r\n\r\nI see a few alternatives on how to resolve this:\r\n\r\n 1. Have GHC recognise `-optc-O[0-9]` and suppress automatically injecting any `-O<n>` of its own\r\n 2. Have GHC inject its automatic `-O`-flags before user-provided `-optc` flags\r\n 3. Have GHC inject `-optc` flags as late as possible on the C compiler command-line\r\n 4. Implement a new variant of the `-optc` flag which injects its flags as late as possible on the C compiler command-line","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/15071:set usage in ghci tests breaks platform independence of output2019-07-07T18:14:24ZBen Gamari:set usage in ghci tests breaks platform independence of outputNumerous GHCi tests are currently failing on Windows due to the use of `:set`, which prints the default flag set, which is platform dependent. For instance:
```
--- "/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024...Numerous GHCi tests are currently failing on Windows due to the use of `:set`, which prints the default flag set, which is platform dependent. For instance:
```
--- "/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024.stdout.normalised" 2018-04-19 18:35:50.927278200 +0000
+++ "/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024.run.stdout.normalised" 2018-04-19 18:35:50.927278200 +0000
@@ -7,7 +7,6 @@
GHCi-specific dynamic flag settings:
other dynamic, non-language, flag settings:
-fno-diagnostics-show-caret
- -fexternal-dynamic-refs
-fignore-optim-changes
-fignore-hpc-changes
-fno-ghci-history
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":":set usage in ghci tests breaks platform independence of output","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Numerous GHCi tests are currently failing on Windows due to the use of `:set`, which prints the default flag set, which is platform dependent. For instance:\r\n{{{\r\n--- \"/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024.stdout.normalised\"\t2018-04-19 18:35:50.927278200 +0000\r\n+++ \"/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024.run.stdout.normalised\"\t2018-04-19 18:35:50.927278200 +0000\r\n@@ -7,7 +7,6 @@\r\n GHCi-specific dynamic flag settings:\r\n other dynamic, non-language, flag settings:\r\n -fno-diagnostics-show-caret\r\n- -fexternal-dynamic-refs\r\n -fignore-optim-changes\r\n -fignore-hpc-changes\r\n -fno-ghci-history\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/15261Show -with-rtsopts options in runtime's --info2019-07-07T18:13:35ZÖmer Sinan AğacanShow -with-rtsopts options in runtime's --infoAs far as I know currently we don't have a way to show `-with-rtsopts` options provided when compiling an executable. It'd be useful if `--info` showed this. Some use cases:
- When you have multiple binaries of the same program you can ...As far as I know currently we don't have a way to show `-with-rtsopts` options provided when compiling an executable. It'd be useful if `--info` showed this. Some use cases:
- When you have multiple binaries of the same program you can see how each one is compiled. Useful when debugging.
- Sometimes we instruct users saying "compile with this and run with that". This steps becomes easier with `-with-rtsopts` because with that the user doesn't have to pass runtime parameters. But currently we don't have an easy way check if the users did it right. If `+RTS --info` showed this information we could say "look at the info, you should see this and that".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| 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":"Show -with-rtsopts options in runtime's --info","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"As far as I know currently we don't have a way to show `-with-rtsopts` options provided when compiling an executable. It'd be useful if `--info` showed this. Some use cases:\r\n\r\n- When you have multiple binaries of the same program you can see how each one is compiled. Useful when debugging.\r\n- Sometimes we instruct users saying \"compile with this and run with that\". This steps becomes easier with `-with-rtsopts` because with that the user doesn't have to pass runtime parameters. But currently we don't have an easy way check if the users did it right. If `+RTS --info` showed this information we could say \"look at the info, you should see this and that\".","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Sennhttps://gitlab.haskell.org/ghc/ghc/-/issues/15369GHCi doesn't honor ':set +c' when loading, for a second time, a file that has...2019-07-07T18:12:57ZdramforeverGHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.oIf a file `foo.hs` is compiled and has `foo.hi` and `foo.o` lying around, then the *second time* `foo.hs` is loaded in GHCi (with `set +c` set), even with `:load *foo.hs` to force interpretation, the file loads fine but the type informat...If a file `foo.hs` is compiled and has `foo.hi` and `foo.o` lying around, then the *second time* `foo.hs` is loaded in GHCi (with `set +c` set), even with `:load *foo.hs` to force interpretation, the file loads fine but the type information is not collected, as if `:set +c` wasn't in effect.
This means that commands like `:type-at` and `:all-types` work as if they had the old file.
I expect that given `:set +c`, a successful `:load *foo.hs` would always collect the new type information for `foo.hs`.
## Steps to reproduce
The contents of `setc.hs` is the following, although it's pretty surely irrelevant.
```hs
module SetC where
```
The following is a GHCi session showing the problem (my comments are marked with `--`).
```
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> :set +c
-- dir /b is basically ls on Windows
Prelude> :! dir /b setc*
setc.hs
-- When I load a file multiple times it works fine
Prelude> :load *setc.hs
[1 of 1] Compiling SetC ( setc.hs, interpreted )
Ok, one module loaded.
Collecting type info for 1 module(s) ... -- Collected
*SetC> :load *setc.hs
[1 of 1] Compiling SetC ( setc.hs, interpreted )
Ok, one module loaded.
Collecting type info for 1 module(s) ... -- Collected
-- But if I compile it
*SetC> :! ghc -c setc.hs
*SetC> :! dir /b setc*
setc.hi
setc.hs
setc.o
-- The first time the type info is collected
*SetC> :load *setc.hs
[1 of 1] Compiling SetC ( setc.hs, interpreted )
Ok, one module loaded.
Collecting type info for 1 module(s) ... -- Collected
-- But then it is no longer collected
*SetC> :load *setc.hs
[1 of 1] Compiling SetC ( setc.hs, interpreted )
Ok, one module loaded. -- NOT collected!
*SetC>
```
Then if I change `setc.hs` to add some expressions:
```hs
module SetC where
x :: Int
x = 1
```
```
*SetC> :load *setc.hs
[1 of 1] Compiling SetC ( setc.hs, interpreted )
Ok, one module loaded. -- NOT collected!
-- The new definition is loaded fine
*SetC> x
1
-- But the type information is not there (no output!)
*SetC> :all-types
*SetC>
-- Then if I delete the compiled .hi and .o files
*SetC> :! del setc.hi setc.o
-- ... and load again, :all-types suddenly works
*SetC> :load *setc.hs
[1 of 1] Compiling SetC ( setc.hs, interpreted )
Ok, one module loaded.
Collecting type info for 1 module(s) ... -- Collected
*SetC> :all-types
setc.hs:(4,1)-(4,2): GHC.Types.Int
setc.hs:(4,5)-(4,6): GHC.Types.Int
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If a file `foo.hs` is compiled and has `foo.hi` and `foo.o` lying around, then the ''second time'' `foo.hs` is loaded in GHCi (with `set +c` set), even with `:load *foo.hs` to force interpretation, the file loads fine but the type information is not collected, as if `:set +c` wasn't in effect.\r\n\r\nThis means that commands like `:type-at` and `:all-types` work as if they had the old file.\r\n\r\nI expect that given `:set +c`, a successful `:load *foo.hs` would always collect the new type information for `foo.hs`.\r\n\r\n== Steps to reproduce\r\n\r\nThe contents of `setc.hs` is the following, although it's pretty surely irrelevant.\r\n\r\n{{{#!hs\r\nmodule SetC where\r\n}}}\r\n\r\nThe following is a GHCi session showing the problem (my comments are marked with `--`).\r\n\r\n{{{\r\nGHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set +c\r\n\r\n-- dir /b is basically ls on Windows\r\nPrelude> :! dir /b setc*\r\nsetc.hs\r\n\r\n-- When I load a file multiple times it works fine\r\nPrelude> :load *setc.hs\r\n[1 of 1] Compiling SetC ( setc.hs, interpreted )\r\nOk, one module loaded.\r\nCollecting type info for 1 module(s) ... -- Collected\r\n*SetC> :load *setc.hs\r\n[1 of 1] Compiling SetC ( setc.hs, interpreted )\r\nOk, one module loaded.\r\nCollecting type info for 1 module(s) ... -- Collected\r\n\r\n-- But if I compile it\r\n*SetC> :! ghc -c setc.hs\r\n*SetC> :! dir /b setc*\r\nsetc.hi\r\nsetc.hs\r\nsetc.o\r\n\r\n-- The first time the type info is collected\r\n*SetC> :load *setc.hs\r\n[1 of 1] Compiling SetC ( setc.hs, interpreted )\r\nOk, one module loaded.\r\nCollecting type info for 1 module(s) ... -- Collected\r\n\r\n-- But then it is no longer collected\r\n*SetC> :load *setc.hs\r\n[1 of 1] Compiling SetC ( setc.hs, interpreted )\r\nOk, one module loaded. -- NOT collected!\r\n*SetC>\r\n}}}\r\n\r\nThen if I change `setc.hs` to add some expressions:\r\n\r\n{{{#!hs\r\nmodule SetC where\r\n\r\nx :: Int\r\nx = 1\r\n}}}\r\n\r\n{{{\r\n*SetC> :load *setc.hs\r\n[1 of 1] Compiling SetC ( setc.hs, interpreted )\r\nOk, one module loaded. -- NOT collected!\r\n\r\n-- The new definition is loaded fine\r\n*SetC> x\r\n1\r\n\r\n-- But the type information is not there (no output!)\r\n*SetC> :all-types\r\n*SetC> \r\n\r\n-- Then if I delete the compiled .hi and .o files\r\n*SetC> :! del setc.hi setc.o\r\n\r\n-- ... and load again, :all-types suddenly works\r\n*SetC> :load *setc.hs\r\n[1 of 1] Compiling SetC ( setc.hs, interpreted )\r\nOk, one module loaded.\r\nCollecting type info for 1 module(s) ... -- Collected\r\n*SetC> :all-types\r\nsetc.hs:(4,1)-(4,2): GHC.Types.Int\r\nsetc.hs:(4,5)-(4,6): GHC.Types.Int\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Roland SennRoland Senn