GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2020-05-05T21:27:50Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16110Explicit foralls in associated type family defaults are completely ignored?2020-05-05T21:27:50ZRyan ScottExplicit foralls in associated type family defaults are completely ignored?While playing around with GHC HEAD recently, I noticed some rather bizarre behavior when trying to use explicit `forall`s with associated type family defaults. Let's pop open GHCi and recreate it:
```
$ inplace/bin/ghc-stage2 --interact...While playing around with GHC HEAD recently, I noticed some rather bizarre behavior when trying to use explicit `forall`s with associated type family defaults. Let's pop open GHCi and recreate it:
```
$ inplace/bin/ghc-stage2 --interactive -XTypeFamilies -XScopedTypeVariables
GHCi, version 8.7.20181215: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> class C a where { type T a b; type forall b. T a b = Either a b }
```
OK, so far, so good. Now let's see what happens when I omit the `b`:
```
λ> class C a where { type T a b; type forall. T a b = Either a b }
```
That... works? Wow, I wouldn't have expected that... But it gets even worse—I can type in utter nonsense, and GHCi will accept it:
```
λ> class C a where { type T a b; type forall dup dup dup. T a b = Either a b }
λ> class C a where { type T a b; type forall (a :: a). T a b = Either a b }
λ> class C a where { type T a b; type forall (a :: k) k. T a b = Either a b }
```
How could this possibly happen? After looking at the source code to see how associated type family defaults are renamed, it becomes clear why this is the case. Here is how they are [renamed](http://git.haskell.org/ghc.git/blob/ef57272e28f5047599249ae457609a079d8aebef:/compiler/rename/RnSource.hs#l841):
```hs
rnTyFamDefltEqn cls (FamEqn { ...
, feqn_bndrs = bndrs
, ... })
= do { ...
; return (FamEqn { ...
, feqn_bndrs = ASSERT( isNothing bndrs )
Nothing
, ... }, ...) }
```
Not only are the type variable binders ignored, there's actually an `ASSERT`ion in place which assumes that there will be no binders whatsoever! (I haven't checked, but I suspect the code above will trigger a failure on that `ASSERT`ion.)
My questions after seeing all of this are:
- Should we be accepting explicit `forall`s in associated type family defaults at all?
- If so, should we remove this strange invariant that the binders will always be `Nothing`?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.7 |
| 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":"Explicit foralls in associated type family defaults are completely ignored?","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While playing around with GHC HEAD recently, I noticed some rather bizarre behavior when trying to use explicit `forall`s with associated type family defaults. Let's pop open GHCi and recreate it:\r\n\r\n{{{\r\n$ inplace/bin/ghc-stage2 --interactive -XTypeFamilies -XScopedTypeVariables\r\nGHCi, version 8.7.20181215: https://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\nλ> class C a where { type T a b; type forall b. T a b = Either a b }\r\n}}}\r\n\r\nOK, so far, so good. Now let's see what happens when I omit the `b`:\r\n\r\n{{{\r\nλ> class C a where { type T a b; type forall. T a b = Either a b }\r\n}}}\r\n\r\nThat... works? Wow, I wouldn't have expected that... But it gets even worse—I can type in utter nonsense, and GHCi will accept it:\r\n\r\n{{{\r\nλ> class C a where { type T a b; type forall dup dup dup. T a b = Either a b }\r\nλ> class C a where { type T a b; type forall (a :: a). T a b = Either a b }\r\nλ> class C a where { type T a b; type forall (a :: k) k. T a b = Either a b }\r\n}}}\r\n\r\nHow could this possibly happen? After looking at the source code to see how associated type family defaults are renamed, it becomes clear why this is the case. Here is how they are [http://git.haskell.org/ghc.git/blob/ef57272e28f5047599249ae457609a079d8aebef:/compiler/rename/RnSource.hs#l841 renamed]:\r\n\r\n{{{#!hs\r\nrnTyFamDefltEqn cls (FamEqn { ...\r\n , feqn_bndrs = bndrs\r\n , ... })\r\n = do { ...\r\n ; return (FamEqn { ...\r\n , feqn_bndrs = ASSERT( isNothing bndrs )\r\n Nothing\r\n , ... }, ...) }\r\n}}}\r\n\r\nNot only are the type variable binders ignored, there's actually an `ASSERT`ion in place which assumes that there will be no binders whatsoever! (I haven't checked, but I suspect the code above will trigger a failure on that `ASSERT`ion.)\r\n\r\nMy questions after seeing all of this are:\r\n\r\n* Should we be accepting explicit `forall`s in associated type family defaults at all?\r\n* If so, should we remove this strange invariant that the binders will always be `Nothing`?","type_of_failure":"OtherFailure","blocking":[]} -->Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/16109cabal install H under Windows 10 does not terminate2019-07-07T18:01:28Zdsampericabal install H under Windows 10 does not terminateUnder Windows 10 using ghc c8.6.3 (Haskell Platform), using cabal to install H (HaskellR) stalls after the message "Completed aeson," with ghc consuming about 5-10% of the CPU forever. I let it run all night and the situation does not ch...Under Windows 10 using ghc c8.6.3 (Haskell Platform), using cabal to install H (HaskellR) stalls after the message "Completed aeson," with ghc consuming about 5-10% of the CPU forever. I let it run all night and the situation does not change. The command used: 'cabal update; cabal install H'. I tried increasing the priority of the ghc process to "realtime." This increases the cpu usage from 5% to 10-20%, but still no progress after hours (days?).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"cabal install H under Windows 10 does not terminate","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Under Windows 10 using ghc c8.6.3 (Haskell Platform), using cabal to install H (HaskellR) stalls after the message \"Completed aeson,\" with ghc consuming about 5-10% of the CPU forever. I let it run all night and the situation does not change. The command used: 'cabal update; cabal install H'. I tried increasing the priority of the ghc process to \"realtime.\" This increases the cpu usage from 5% to 10-20%, but still no progress after hours (days?).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16107Update GCC compiler & friends2019-10-22T06:07:09ZPhilippeUpdate GCC compiler & friendsgcc used by ghc is now about 1.5 years old. It's going to take some time for a new GHC release as well. Would be good to update gcc too. Probably it's backwards compatible with old gcc so would be easy to patch.
https://github.com/ghc/g...gcc used by ghc is now about 1.5 years old. It's going to take some time for a new GHC release as well. Would be good to update gcc too. Probably it's backwards compatible with old gcc so would be easy to patch.
https://github.com/ghc/ghc/blob/f11f2521aff16edca150e6eed5102a3da7e4f59a/mk/get-win32-tarballs.sh\#L104-L114
source code also points to other tools of which some have newer versions.
Packages can be browsed here http://repo.msys2.org/mingw/x86_64/
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.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":"Update GCC compiler & friends","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"gcc used by ghc is now about 1.5 years old. It's going to take some time for a new GHC release as well. Would be good to update gcc too. Probably it's backwards compatible with old gcc so would be easy to patch.\r\n\r\nhttps://github.com/ghc/ghc/blob/f11f2521aff16edca150e6eed5102a3da7e4f59a/mk/get-win32-tarballs.sh#L104-L114\r\n\r\nsource code also points to other tools of which some have newer versions.\r\n\r\nPackages can be browsed here http://repo.msys2.org/mingw/x86_64/","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/16106Remove PowerPC OS X (Darwin) support2022-04-06T09:20:42ZPeter Trommlerptrommler@acm.orgRemove PowerPC OS X (Darwin) supportOS X for PowerPC is not supported by Apple anymore. GHC's support has most likely bit-rotted and we have no test machine. Let's go ahead and remove support for PowerPC Darwin.
The following components contain PowerPC Darwin specific cod...OS X for PowerPC is not supported by Apple anymore. GHC's support has most likely bit-rotted and we have no test machine. Let's go ahead and remove support for PowerPC Darwin.
The following components contain PowerPC Darwin specific code:
- native code generator
- RTS
- driver
- build system
- testsuite⊥Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/16105Haddock's resource directory isn't properly handled by Hadrian2019-07-07T18:01:30ZAlec TheriaultHaddock's resource directory isn't properly handled by HadrianI'm still investigating, but several things look off about how Hadrian handles Haddock's resources (which are in `utils/haddock/haddock-api/resource`).
- only the `html` folder is being copied, which means that there is no way `haddock ...I'm still investigating, but several things look off about how Hadrian handles Haddock's resources (which are in `utils/haddock/haddock-api/resource`).
- only the `html` folder is being copied, which means that there is no way `haddock --latex` will work
- the resources (both `html` and `latex`) should probably be specified as `runtimeDependencies` of the `Haddock` builder instead of woven into the doc rules
- the Haddock wrapper in the `BinaryDist` rules specifies the wrong `--lib` dir (we currently put Haddock's resources in the `doc` folder, not the `lib` folder as we do for the Make system)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Haddock's resource directory isn't properly handled by Hadrian","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm still investigating, but several things look off about how Hadrian handles Haddock's resources (which are in `utils/haddock/haddock-api/resource`).\r\n\r\n * only the `html` folder is being copied, which means that there is no way `haddock --latex` will work\r\n * the resources (both `html` and `latex`) should probably be specified as `runtimeDependencies` of the `Haddock` builder instead of woven into the doc rules\r\n * the Haddock wrapper in the `BinaryDist` rules specifies the wrong `--lib` dir (we currently put Haddock's resources in the `doc` folder, not the `lib` folder as we do for the Make system)\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alec TheriaultAlec Theriaulthttps://gitlab.haskell.org/ghc/ghc/-/issues/16104Plugin name lookup behavior change from GHC 8.4 series2019-07-07T18:01:30ZLevent ErkökPlugin name lookup behavior change from GHC 8.4 seriesI'm trying to port a core plugin to GHC 8.6.3, which was last working fine with GHC 8.4 series. Unfortunately, I'm running into issues. Wondering if pluging programming requirements have changed, or is this a regression in GHC itself. I ...I'm trying to port a core plugin to GHC 8.6.3, which was last working fine with GHC 8.4 series. Unfortunately, I'm running into issues. Wondering if pluging programming requirements have changed, or is this a regression in GHC itself. I boiled it down to the following example and would like some guidance on how to make this work:
I have the following in file `TestPlugin.hs`:
```hs
{-# LANGUAGE TemplateHaskell #-}
module TestPlugin (plugin) where
import GhcPlugins
import Data.Bits
plugin :: Plugin
plugin = defaultPlugin {installCoreToDos = install}
where install _ todos = return (test : todos)
test = CoreDoPluginPass "Test" check
check :: ModGuts -> CoreM ModGuts
check m = do mbN <- thNameToGhcName 'complement
case mbN of
Just _ -> liftIO $ putStrLn "Found complement!"
Nothing -> error "Failed to locate complement"
return m
```
And I have a very simple `Test.hs` file:
```hs
{-# OPTIONS_GHC -fplugin TestPlugin #-}
main :: IO ()
main = return ()
```
With GHC-8.4.2, I have:
```
$ ghc-8.4.2 --make -package ghc -c TestPlugin.hs
[1 of 1] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o )
$ ghc-8.4.2 -package ghc -c Test.hs
Found complement!
```
But with GHC 8.6.3, I get:
```
$ ghc-8.6.3 --make -package ghc -c TestPlugin.hs
[1 of 1] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o )
$ ghc-8.6.3 -package ghc -c Test.hs
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.3 for x86_64-apple-darwin):
Failed to locate complement
```
The problem goes away if I change `Test.hs` to:
```hs
{-# OPTIONS_GHC -fplugin TestPlugin #-}
import Data.Bits -- Should not be required in the client code!
main :: IO ()
main = return ()
```
That is, if I explicitly import `Data.Bits`. But this is quite undesirable, since `Test.hs` is client code and the users of the plugin have no reason to import all bunch of modules the plugin might need for its own purposes. (In practice, this would require clients to import a whole bunch of irrelevant modules; quite unworkable and not maintainable.)
Should I be coding my plugin differently? Or is this a GHC regression?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"Plugin name lookup behavior change from GHC 8.4 series","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm trying to port a core plugin to GHC 8.6.3, which was last working fine with GHC 8.4 series. Unfortunately, I'm running into issues. Wondering if pluging programming requirements have changed, or is this a regression in GHC itself. I boiled it down to the following example and would like some guidance on how to make this work:\r\n\r\nI have the following in file `TestPlugin.hs`:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\n\r\nmodule TestPlugin (plugin) where\r\n\r\nimport GhcPlugins\r\nimport Data.Bits\r\n\r\nplugin :: Plugin\r\nplugin = defaultPlugin {installCoreToDos = install}\r\n where install _ todos = return (test : todos)\r\n\r\n test = CoreDoPluginPass \"Test\" check\r\n\r\n check :: ModGuts -> CoreM ModGuts\r\n check m = do mbN <- thNameToGhcName 'complement\r\n case mbN of\r\n Just _ -> liftIO $ putStrLn \"Found complement!\"\r\n Nothing -> error \"Failed to locate complement\"\r\n\r\n return m\r\n}}}\r\n\r\nAnd I have a very simple `Test.hs` file:\r\n\r\n{{{#!hs\r\n{-# OPTIONS_GHC -fplugin TestPlugin #-}\r\n\r\nmain :: IO ()\r\nmain = return ()\r\n}}}\r\n\r\nWith GHC-8.4.2, I have:\r\n\r\n{{{\r\n$ ghc-8.4.2 --make -package ghc -c TestPlugin.hs\r\n[1 of 1] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o )\r\n\r\n$ ghc-8.4.2 -package ghc -c Test.hs\r\nFound complement!\r\n}}}\r\n\r\nBut with GHC 8.6.3, I get:\r\n\r\n{{{\r\n$ ghc-8.6.3 --make -package ghc -c TestPlugin.hs\r\n[1 of 1] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o )\r\n\r\n$ ghc-8.6.3 -package ghc -c Test.hs\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.6.3 for x86_64-apple-darwin):\r\n\tFailed to locate complement\r\n}}}\r\n\r\nThe problem goes away if I change `Test.hs` to:\r\n\r\n{{{#!hs\r\n{-# OPTIONS_GHC -fplugin TestPlugin #-}\r\n\r\nimport Data.Bits -- Should not be required in the client code!\r\n\r\nmain :: IO ()\r\nmain = return ()\r\n}}}\r\n\r\nThat is, if I explicitly import `Data.Bits`. But this is quite undesirable, since `Test.hs` is client code and the users of the plugin have no reason to import all bunch of modules the plugin might need for its own purposes. (In practice, this would require clients to import a whole bunch of irrelevant modules; quite unworkable and not maintainable.)\r\n\r\nShould I be coding my plugin differently? Or is this a GHC regression?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.4https://gitlab.haskell.org/ghc/ghc/-/issues/16103docs-haddock Hadrian target doesn't work reliably2019-07-07T18:01:30ZAlec Theriaultdocs-haddock Hadrian target doesn't work reliablyStarting with a clean build, the following doesn't work:
```
$ ./hadrian/build.sh -c docs-haddock
```
However, it does work if you've already run `./hadrian/build.sh -c`. Here's a sample `--verbose` log (this was produced with `./hadri...Starting with a clean build, the following doesn't work:
```
$ ./hadrian/build.sh -c docs-haddock
```
However, it does work if you've already run `./hadrian/build.sh -c`. Here's a sample `--verbose` log (this was produced with `./hadrian/build.sh -c --build-root=_qkst-integer-simple --flavour=quickest docs-haddock --integer-simple --verbose`, but the problem exhibits even without all the extra options):
```
Up to date
Up to date
| ContextData oracle: resolving data for 'haddock' (Stage2, v)...
| Configure package 'haddock'
Configuring haddock-2.22.0...
creating
/Users/atheriault/Code/ghc/_qkst-integer-simple/stage2/utils/haddock/build
/Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --numeric-version
/Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc is version
8.7.20181227
/Users/atheriault/Code/ghc/_qkst-integer-simple/stage0/bin/ghc-pkg --version
/Users/atheriault/Code/ghc/_qkst-integer-simple/stage0/bin/ghc-pkg is version
8.7.20181227
/Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --supported-languages
/Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --info
Reading installed packages...
/Users/atheriault/Code/ghc/_qkst-integer-simple/stage0/bin/ghc-pkg dump --global -v0 '--global-package-db=/Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/lib/package.conf.d'
/Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --print-libdir '-ghcversion-file=/Users/atheriault/Code/ghc/_qkst-integer-simple/generated/ghcversion.h'
CallStack (from HasCallStack):
die', called at ./Distribution/Simple/Configure.hs:969:20 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure
configureFinalizedPackage, called at ./Distribution/Simple/Configure.hs:467:12 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure
configure, called at ./Distribution/Simple.hs:596:20 in Cabal-2.5.0.0-inplace:Distribution.Simple
confHook, called at ./Distribution/Simple/UserHooks.hs:67:5 in Cabal-2.5.0.0-inplace:Distribution.Simple.UserHooks
configureAction, called at ./Distribution/Simple.hs:178:19 in Cabal-2.5.0.0-inplace:Distribution.Simple
defaultMainHelper, called at ./Distribution/Simple.hs:148:3 in Cabal-2.5.0.0-inplace:Distribution.Simple
defaultMainWithHooksNoReadArgs, called at src/Hadrian/Haskell/Cabal/Parse.hs:145:14 in main:Hadrian.Haskell.Cabal.Parse
hadrian: Encountered missing dependencies:
xhtml ==3000.2.*
shakeArgsWith 0.000s 0%
Function shake 0.010s 0%
Database read 0.317s 12% ===
With database 0.018s 0%
Running rules 2.166s 86% =========================
Total 2.511s 99%
Error when running Shake build system:
at src/Main.hs:58:30-42:
* Depends on: docs-haddock
at src/Rules/Documentation.hs:79:9-48:
* Depends on: _qkst-integer-simple/docs/html/libraries/index.html
at src/Rules/Documentation.hs:136:9-24:
* Depends on: _qkst-integer-simple/docs/html/libraries/ghc-prim/ghc-prim.haddock
at src/Hadrian/Builder.hs:70:5-23:
* Depends on: _qkst-integer-simple/stage2/bin/haddock
at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68:
* Depends on: OracleQ (ContextDataKey (Context {stage = Stage2, package = Package {pkgType = Program, pkgName = "haddock", pkgPath = "utils/haddock"}, way = v}))
at src/Hadrian/Haskell/Cabal/Parse.hs:202:5-36:
* Depends on: _qkst-integer-simple/stage2/utils/haddock/setup-config
* Raised the exception:
ExitFailure 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"docs-haddock Hadrian target doesn't work reliably","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Starting with a clean build, the following doesn't work:\r\n\r\n{{{\r\n$ ./hadrian/build.sh -c docs-haddock\r\n}}}\r\n\r\nHowever, it does work if you've already run `./hadrian/build.sh -c`. Here's a sample `--verbose` log (this was produced with `./hadrian/build.sh -c --build-root=_qkst-integer-simple --flavour=quickest docs-haddock --integer-simple --verbose`, but the problem exhibits even without all the extra options):\r\n\r\n{{{\r\nUp to date\r\nUp to date\r\n| ContextData oracle: resolving data for 'haddock' (Stage2, v)...\r\n| Configure package 'haddock'\r\nConfiguring haddock-2.22.0...\r\ncreating\r\n/Users/atheriault/Code/ghc/_qkst-integer-simple/stage2/utils/haddock/build\r\n/Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --numeric-version\r\n/Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc is version\r\n8.7.20181227\r\n/Users/atheriault/Code/ghc/_qkst-integer-simple/stage0/bin/ghc-pkg --version\r\n/Users/atheriault/Code/ghc/_qkst-integer-simple/stage0/bin/ghc-pkg is version\r\n8.7.20181227\r\n/Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --supported-languages\r\n/Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --info\r\nReading installed packages...\r\n/Users/atheriault/Code/ghc/_qkst-integer-simple/stage0/bin/ghc-pkg dump --global -v0 '--global-package-db=/Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/lib/package.conf.d'\r\n/Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --print-libdir '-ghcversion-file=/Users/atheriault/Code/ghc/_qkst-integer-simple/generated/ghcversion.h'\r\nCallStack (from HasCallStack):\r\n die', called at ./Distribution/Simple/Configure.hs:969:20 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure\r\n configureFinalizedPackage, called at ./Distribution/Simple/Configure.hs:467:12 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure\r\n configure, called at ./Distribution/Simple.hs:596:20 in Cabal-2.5.0.0-inplace:Distribution.Simple\r\n confHook, called at ./Distribution/Simple/UserHooks.hs:67:5 in Cabal-2.5.0.0-inplace:Distribution.Simple.UserHooks\r\n configureAction, called at ./Distribution/Simple.hs:178:19 in Cabal-2.5.0.0-inplace:Distribution.Simple\r\n defaultMainHelper, called at ./Distribution/Simple.hs:148:3 in Cabal-2.5.0.0-inplace:Distribution.Simple\r\n defaultMainWithHooksNoReadArgs, called at src/Hadrian/Haskell/Cabal/Parse.hs:145:14 in main:Hadrian.Haskell.Cabal.Parse\r\nhadrian: Encountered missing dependencies:\r\nxhtml ==3000.2.*\r\n\r\nshakeArgsWith 0.000s 0% \r\nFunction shake 0.010s 0% \r\nDatabase read 0.317s 12% === \r\nWith database 0.018s 0% \r\nRunning rules 2.166s 86% =========================\r\nTotal 2.511s 99% \r\nError when running Shake build system:\r\n at src/Main.hs:58:30-42:\r\n* Depends on: docs-haddock\r\n at src/Rules/Documentation.hs:79:9-48:\r\n* Depends on: _qkst-integer-simple/docs/html/libraries/index.html\r\n at src/Rules/Documentation.hs:136:9-24:\r\n* Depends on: _qkst-integer-simple/docs/html/libraries/ghc-prim/ghc-prim.haddock\r\n at src/Hadrian/Builder.hs:70:5-23:\r\n* Depends on: _qkst-integer-simple/stage2/bin/haddock\r\n at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68:\r\n* Depends on: OracleQ (ContextDataKey (Context {stage = Stage2, package = Package {pkgType = Program, pkgName = \"haddock\", pkgPath = \"utils/haddock\"}, way = v}))\r\n at src/Hadrian/Haskell/Cabal/Parse.hs:202:5-36:\r\n* Depends on: _qkst-integer-simple/stage2/utils/haddock/setup-config\r\n* Raised the exception:\r\nExitFailure 1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16102forkProcess causes weird GC summary in the child process2020-09-28T07:11:39ZÖmer Sinan AğacanforkProcess causes weird GC summary in the child processThe existing test `forkprocess01` actually exhibits this behavior, but we just don't have the necessary assertions in place to catch it. One of the assertions I added in https://gitlab.haskell.org/ghc/ghc/merge_requests/51 catches this b...The existing test `forkprocess01` actually exhibits this behavior, but we just don't have the necessary assertions in place to catch it. One of the assertions I added in https://gitlab.haskell.org/ghc/ghc/merge_requests/51 catches this bug.
Here's the output with GHC 8.4:
```
$ ghc forkprocess01.hs -debug -rtsopts
[1 of 1] Compiling Main ( forkprocess01.hs, forkprocess01.o )
Linking forkprocess01 ...
$ ./forkprocess01 +RTS -s
44,144 bytes allocated in the heap
4,824 bytes copied during GC
37,696 bytes maximum residency (1 sample(s))
19,648 bytes maximum slop
2 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s
Gen 1 1 colls, 0 par 0.001s 0.001s 0.0006s 0.0006s
INIT time 0.000s ( 0.000s elapsed)
MUT time 0.000s ( 0.001s elapsed)
GC time 0.001s ( 0.001s elapsed)
EXIT time 0.000s ( 0.000s elapsed)
Total time 0.000s ( 0.002s elapsed)
%GC time 61200000.0% (32.3% elapsed)
Alloc rate 0 bytes per MUT second
Productivity -100999900.0% of total user, 47.2% of total elapsed
Just (Exited (ExitFailure 72))
54,160 bytes allocated in the heap
3,480 bytes copied during GC
44,576 bytes maximum residency (1 sample(s))
25,056 bytes maximum slop
2 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s
Gen 1 1 colls, 0 par 0.001s 0.001s 0.0005s 0.0005s
INIT time 0.000s ( 0.000s elapsed)
MUT time 0.001s ( 0.003s elapsed)
GC time 0.001s ( 0.001s elapsed)
EXIT time 0.000s ( 0.000s elapsed)
Total time 0.002s ( 0.004s elapsed)
%GC time 32.0% (14.5% elapsed)
Alloc rate 87,073,954 bytes per MUT second
Productivity 43.3% of total user, 74.6% of total elapsed
```
Notice the `-100999900.0%` productivity in the first summary, which is printed by the child process.
Can also reproduce with 8.6.3 and GHC HEAD.
Note that you sometimes need to run this a few times to reproduce. Every once in a while I get normal results (where productivity is not negative).https://gitlab.haskell.org/ghc/ghc/-/issues/16101Write a nix expression to enter a shell with specified build artifact2019-07-07T18:01:31ZMatthew PickeringWrite a nix expression to enter a shell with specified build artifactIt should be quite straightforward to write a nix expression which is parameterised by a CI job which downloads the artifact and enters into a nix shell which provisions that version of GHC.
To be precise, consider the recent job: https...It should be quite straightforward to write a nix expression which is parameterised by a CI job which downloads the artifact and enters into a nix shell which provisions that version of GHC.
To be precise, consider the recent job: https://gitlab.haskell.org/ghc/ghc/-/jobs/6427.
It built these artifacts: https://gitlab.haskell.org/ghc/ghc/-/jobs/6427/artifacts/browse
We should download the bindist and patch it suitably so it works like a normal GHC release.
Some inspiration can probably be drawn from the scripts that Ben wrote for the head.hackage repo: https://github.com/hvr/head.hackage/blob/master/default.nix
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Write a nix expression to enter a shell with specified build artifact","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"It should be quite straightforward to write a nix expression which is parameterised by a CI job which downloads the artifact and enters into a nix shell which provisions that version of GHC. \r\n\r\nTo be precise, consider the recent job: https://gitlab.haskell.org/ghc/ghc/-/jobs/6427. \r\n\r\nIt built these artifacts: https://gitlab.haskell.org/ghc/ghc/-/jobs/6427/artifacts/browse\r\n\r\nWe should download the bindist and patch it suitably so it works like a normal GHC release.\r\n\r\nSome inspiration can probably be drawn from the scripts that Ben wrote for the head.hackage repo: https://github.com/hvr/head.hackage/blob/master/default.nix\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16100T11627a fails sometimes on CI2024-03-06T20:42:17ZMatthew PickeringT11627a fails sometimes on CISee this build - https://gitlab.haskell.org/mpickering/ghc/-/jobs/6459
Causes this panic
```
81384 cd "profiling/should_run/T11627b.run" && ./T11627b +RTS -hd -RTS +RTS -i0 -RTS
81385 Wrong exit code for T11627a(prof_hc_hb)(expected ...See this build - https://gitlab.haskell.org/mpickering/ghc/-/jobs/6459
Causes this panic
```
81384 cd "profiling/should_run/T11627b.run" && ./T11627b +RTS -hd -RTS +RTS -i0 -RTS
81385 Wrong exit code for T11627a(prof_hc_hb)(expected 0 , actual 134 )
81386 Stdout ( T11627a ):
81387 456574
81388 Stderr ( T11627a ):
81389 T11627a: internal error: LDV_recordDead: Failed to find counter for closure 0x42000bf558
81390 (GHC version 8.7.20181227 for x86_64_unknown_linux)
81391 Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"T11627a fails sometimes on CI","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\n\r\nSee this build - https://gitlab.haskell.org/mpickering/ghc/-/jobs/6459\r\n\r\nCauses this panic\r\n\r\n{{{\r\n81384 cd \"profiling/should_run/T11627b.run\" && ./T11627b +RTS -hd -RTS +RTS -i0 -RTS \r\n81385 Wrong exit code for T11627a(prof_hc_hb)(expected 0 , actual 134 ) \r\n81386 Stdout ( T11627a ): \r\n81387 456574 \r\n81388 Stderr ( T11627a ): \r\n81389 T11627a: internal error: LDV_recordDead: Failed to find counter for closure 0x42000bf558\r\n81390 (GHC version 8.7.20181227 for x86_64_unknown_linux) \r\n81391 Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16098More efficient implementation plan for primops with continuation arguments2024-02-27T13:56:52ZÖmer Sinan AğacanMore efficient implementation plan for primops with continuation argumentsNote: this also relates to `keepAlive#` and `touch#`. See #21708 and !8597
Original idea from #14375: in some of the primops that take continuation
arguments we currently have to allocate the continuations but sometimes we
immediately ...Note: this also relates to `keepAlive#` and `touch#`. See #21708 and !8597
Original idea from #14375: in some of the primops that take continuation
arguments we currently have to allocate the continuations but sometimes we
immediately enter one of these continuations. One example is
```
maskAsyncExceptions# :: (State# RealWorld -> (# State# RealWorld, a #))
-> (State# RealWorld -> (# State# RealWorld, a #))
```
which is implemented as
```
stg_maskAsyncExceptionszh /* explicit stack */
{
/* Args: R1 :: IO a */
STK_CHK_P_LL (WDS(1)/* worst case */, stg_maskAsyncExceptionszh, R1);
if ((TO_W_(StgTSO_flags(CurrentTSO)) & TSO_BLOCKEX) == 0) {
/* avoid growing the stack unnecessarily */
if (Sp(0) == stg_maskAsyncExceptionszh_ret_info) {
Sp_adj(1);
} else {
Sp_adj(-1);
Sp(0) = stg_unmaskAsyncExceptionszh_ret_info;
}
} else {
if ((TO_W_(StgTSO_flags(CurrentTSO)) & TSO_INTERRUPTIBLE) == 0) {
Sp_adj(-1);
Sp(0) = stg_maskUninterruptiblezh_ret_info;
}
}
StgTSO_flags(CurrentTSO) = %lobits32(
TO_W_(StgTSO_flags(CurrentTSO)) | TSO_BLOCKEX | TSO_INTERRUPTIBLE);
TICK_UNKNOWN_CALL();
TICK_SLOW_CALL_fast_v();
jump stg_ap_v_fast [R1];
}
```
Here we want to have better compilation for `maskAsyncExceptions# c` where we
don't allocate for `c`.
There are some ideas in [ticket:14375\#comment:144211](https://gitlab.haskell.org//ghc/ghc/issues/14375#note_144211), but the idea was later
superseded by [ticket:14375\#comment:144294](https://gitlab.haskell.org//ghc/ghc/issues/14375#note_144294), which suggests
- Making continuation arguments explicit in STG so that an `maskAsyncExceptions#`
would now look like this in STG: `maskAsyncExceptions# (\s. e)`.
- Then in the code gen generating stack frame push (plus `StgTSO` updates) and
then emitting code for `e` directly. (I don't understand if `bind s:=s2` part
in the comment is necessary?)
Some primops take more than one callback, e.g.
```
catch# :: (State# RealWorld -> (# State# RealWorld, a #) )
-> (b -> State# RealWorld -> (# State# RealWorld, a #) )
-> State# RealWorld
-> (# State# RealWorld, a #)
```
Which is implemented as
```
stg_catchzh ( P_ io, /* :: IO a */
P_ handler /* :: Exception -> IO a */ )
{
W_ exceptions_blocked;
STK_CHK_GEN();
exceptions_blocked =
TO_W_(StgTSO_flags(CurrentTSO)) & (TSO_BLOCKEX | TSO_INTERRUPTIBLE);
TICK_CATCHF_PUSHED();
/* Apply R1 to the realworld token */
TICK_UNKNOWN_CALL();
TICK_SLOW_CALL_fast_v();
jump stg_ap_v_fast
(CATCH_FRAME_FIELDS(,,stg_catch_frame_info, CCCS, 0,
exceptions_blocked, handler))
(io);
}
```
For this example [ticket:14375\#comment:144294](https://gitlab.haskell.org//ghc/ghc/issues/14375#note_144294) suggest using join points for the
`handler` argument (and using the non-allocating callback scheme for the `io`
argument), but I suggest we focus on more efficient implementation of callbacks
that are immediately entered, and worry about the join point stuff in another
ticket.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | 8.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | bgamari, simonmar, simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"More efficient implementation plan for primops with continuation arguments","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["bgamari","simonmar","simonpj"],"type":"Task","description":"Original idea from #14375: in some of the primops that take continuation\r\narguments we currently have to allocate the continuations but sometimes we\r\nimmediately enter one of these continuations. One example is\r\n\r\n{{{\r\nmaskAsyncExceptions# :: (State# RealWorld -> (# State# RealWorld, a #))\r\n -> (State# RealWorld -> (# State# RealWorld, a #))\r\n}}}\r\n\r\nwhich is implemented as\r\n\r\n{{{\r\nstg_maskAsyncExceptionszh /* explicit stack */\r\n{\r\n /* Args: R1 :: IO a */\r\n STK_CHK_P_LL (WDS(1)/* worst case */, stg_maskAsyncExceptionszh, R1);\r\n\r\n if ((TO_W_(StgTSO_flags(CurrentTSO)) & TSO_BLOCKEX) == 0) {\r\n /* avoid growing the stack unnecessarily */\r\n if (Sp(0) == stg_maskAsyncExceptionszh_ret_info) {\r\n Sp_adj(1);\r\n } else {\r\n Sp_adj(-1);\r\n Sp(0) = stg_unmaskAsyncExceptionszh_ret_info;\r\n }\r\n } else {\r\n if ((TO_W_(StgTSO_flags(CurrentTSO)) & TSO_INTERRUPTIBLE) == 0) {\r\n Sp_adj(-1);\r\n Sp(0) = stg_maskUninterruptiblezh_ret_info;\r\n }\r\n }\r\n\r\n StgTSO_flags(CurrentTSO) = %lobits32(\r\n TO_W_(StgTSO_flags(CurrentTSO)) | TSO_BLOCKEX | TSO_INTERRUPTIBLE);\r\n\r\n TICK_UNKNOWN_CALL();\r\n TICK_SLOW_CALL_fast_v();\r\n jump stg_ap_v_fast [R1];\r\n}\r\n}}}\r\n\r\nHere we want to have better compilation for `maskAsyncExceptions# c` where we\r\ndon't allocate for `c`.\r\n\r\nThere are some ideas in ticket:14375#comment:1, but the idea was later\r\nsuperseded by ticket:14375#comment:7, which suggests\r\n\r\n- Making continuation arguments explicit in STG so that an `maskAsyncExceptions#`\r\n would now look like this in STG: `maskAsyncExceptions# (\\s. e)`.\r\n- Then in the code gen generating stack frame push (plus `StgTSO` updates) and\r\n then emitting code for `e` directly. (I don't understand if `bind s:=s2` part\r\n in the comment is necessary?)\r\n\r\nSome primops take more than one callback, e.g.\r\n\r\n{{{\r\ncatch# :: (State# RealWorld -> (# State# RealWorld, a #) )\r\n -> (b -> State# RealWorld -> (# State# RealWorld, a #) )\r\n -> State# RealWorld\r\n -> (# State# RealWorld, a #)\r\n}}}\r\n\r\nWhich is implemented as\r\n\r\n{{{\r\nstg_catchzh ( P_ io, /* :: IO a */\r\n P_ handler /* :: Exception -> IO a */ )\r\n{\r\n W_ exceptions_blocked;\r\n\r\n STK_CHK_GEN();\r\n\r\n exceptions_blocked =\r\n TO_W_(StgTSO_flags(CurrentTSO)) & (TSO_BLOCKEX | TSO_INTERRUPTIBLE);\r\n TICK_CATCHF_PUSHED();\r\n\r\n /* Apply R1 to the realworld token */\r\n TICK_UNKNOWN_CALL();\r\n TICK_SLOW_CALL_fast_v();\r\n\r\n jump stg_ap_v_fast\r\n (CATCH_FRAME_FIELDS(,,stg_catch_frame_info, CCCS, 0,\r\n exceptions_blocked, handler))\r\n (io);\r\n}\r\n}}}\r\n\r\nFor this example ticket:14375#comment:7 suggest using join points for the\r\n`handler` argument (and using the non-allocating callback scheme for the `io`\r\nargument), but I suggest we focus on more efficient implementation of callbacks\r\nthat are immediately entered, and worry about the join point stuff in another\r\nticket.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16097Bad error message for a misaligned case block in a do-let expression2020-02-24T21:47:33ZkanetwBad error message for a misaligned case block in a do-let expressionConsider the following code:
```hs
main = do
code <- getCode
let value = case code of
1 -> 2
3 -> 4
_ -> 5
print value
```
This is a parse error, as the indent of the case statements is under the indent introduced ...Consider the following code:
```hs
main = do
code <- getCode
let value = case code of
1 -> 2
3 -> 4
_ -> 5
print value
```
This is a parse error, as the indent of the case statements is under the indent introduced by let. However, the error message on 8.6 onwards is very misleading:
```
/home/dkr/example/Bad.hs:2:8: error:
Unexpected do block in function application:
do code <- getCode
let value = ...
You could write it with parentheses
Or perhaps you meant to enable BlockArguments?
|
2 | main = do
| ^^...
```
Compare this with 8.4, which is a bit less bad:
```
/home/dkr/example/Bad.hs:5:6: error: parse error on input ‘1’
|
5 | 1 -> 2
| ^
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.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":"Bad error message for a misaligned case block in a do-let expression","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following code:\r\n\r\n{{{#!hs\r\nmain = do\r\n code <- getCode\r\n let value = case code of\r\n 1 -> 2\r\n 3 -> 4\r\n _ -> 5\r\n print value\r\n}}}\r\n\r\nThis is a parse error, as the indent of the case statements is under the indent introduced by let. However, the error message on 8.6 onwards is very misleading:\r\n\r\n{{{\r\n/home/dkr/example/Bad.hs:2:8: error:\r\n Unexpected do block in function application:\r\n do code <- getCode\r\n let value = ...\r\n You could write it with parentheses\r\n Or perhaps you meant to enable BlockArguments?\r\n |\r\n2 | main = do\r\n | ^^...\r\n}}}\r\n\r\nCompare this with 8.4, which is a bit less bad:\r\n{{{\r\n/home/dkr/example/Bad.hs:5:6: error: parse error on input ‘1’\r\n |\r\n5 | 1 -> 2\r\n | ^\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16096let x = ... and x = ... are not the same in GHCi2023-08-29T00:32:44ZÖmer Sinan Ağacanlet x = ... and x = ... are not the same in GHCiWith #7253 we implemented support for `x = ...` in GHCi which is supposed to do the same thing as `let x = ...`, but they're currently different, as observed in #16089, #15721, and probably in other tickets. Here's a reproducer:
```
~ $...With #7253 we implemented support for `x = ...` in GHCi which is supposed to do the same thing as `let x = ...`, but they're currently different, as observed in #16089, #15721, and probably in other tickets. Here's a reproducer:
```
~ $ ghci -ddump-bcos
GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help
...
λ:1> let x = [True,False]
==================== Proto-BCOs ====================
ProtoBCO ExprTopLevel_E0#0 []:
let sat_s1vF = ... in ...
bitmap: 0 []
PUSH_G GHC.Types.[]
PUSH_G GHC.Types.False
PACK : 2
PUSH_L 0
PUSH_G GHC.Types.True
PACK : 2
PUSH_G GHC.Types.[]
PUSH_L 1
PACK : 2
PUSH_L 0
PUSH_APPLY_P
PUSH_G GHC.Base.returnIO
SLIDE 3 3
ENTER
λ:2> x = [True,False]
==================== Proto-BCOs ====================
ProtoBCO x1_r1wJ#0 []:
GHC.Types.:
@ GHC.Types.Bool GHC.Types.False (GHC.Types.[] @ GHC.Types.Bool)
bitmap: 0 []
PUSH_G GHC.Types.[]
PUSH_G GHC.Types.False
PACK : 2
ENTER
ProtoBCO Ghci2.x#0 []:
GHC.Types.: @ GHC.Types.Bool GHC.Types.True x1_r1wJ
bitmap: 0 []
PUSH_G x1_r1wJ
PUSH_G GHC.Types.True
PACK : 2
ENTER
...
```
Expected behavior: these two should generate the same byte code, and should be subject to same checks (e.g. for shadowing).
(Example above uses 8.4.4, but this can be reproduced with GHC HEAD too)8.8.1Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/16095Infinite loop during error reporting (ignores SIGINT/SIGTERM, then OOMs)2023-04-01T11:47:52ZSerge KosyrevInfinite loop during error reporting (ignores SIGINT/SIGTERM, then OOMs)Compiling the repro snippet produces the following incomplete output and hangs GHC:
```
$ ghc repro.hs
[1 of 1] Compiling Main ( repro.hs, repro.o )
repro.hs:16:22: error:
```
The GHC process ignores SIGINT -- so it must b...Compiling the repro snippet produces the following incomplete output and hangs GHC:
```
$ ghc repro.hs
[1 of 1] Compiling Main ( repro.hs, repro.o )
repro.hs:16:22: error:
```
The GHC process ignores SIGINT -- so it must be killed with SIGKILL.
The memory usage grows, until it consumes all memory (\~30G RAM + swap) and is terminated by the OOM killer.
This minimal snippet depends on `generics-sop` (tested with version `0.4.0.0`).
Sadly I didn't find a constraint in `base` to cause this behavior..
```hs
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
import Generics.SOP (HasDatatypeInfo)
data family TF i a :: *
data instance TF i a = R
class C i a where
method :: TF i a
instance C i () where
instance HasDatatypeInfo a => C i a where
method = undefined function
function :: C i a => TF i a
function = method
main = undefined
```
Affects 8.4.3 and 8.6.1.
Not tested on 8.6.2 & 8.6.3.https://gitlab.haskell.org/ghc/ghc/-/issues/16094panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc...2019-07-07T18:01:32ZSergei Trofimovichpanic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64]On current HEAD ghc fails build on powerpc32:
```
$ ./configure --target=powerpc-unknown-linux-gnu
$ make
...
"inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iinclud...On current HEAD ghc fails build on powerpc32:
```
$ ./configure --target=powerpc-unknown-linux-gnu
$ make
...
"inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 8.7.20181223 for powerpc-unknown-linux):
getRegister(ppc)
I64[I32[BaseReg + 812] + 64]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable
pprPanic, called at compiler/nativeGen/PPC/CodeGen.hs:693:24 in ghc:PPC.CodeGen
```
```
$ inplace/bin/ghc-stage1 --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("GCC extra via C opts"," -fwrapv -fno-builtin")
,("C compiler command","powerpc-unknown-linux-gnu-gcc")
,("C compiler flags"," -fno-stack-protector")
,("C compiler link flags"," -fuse-ld=gold")
,("C compiler supports -no-pie","YES")
,("Haskell CPP command","powerpc-unknown-linux-gnu-gcc")
,("Haskell CPP flags","-E -undef -traditional")
,("ld command","powerpc-unknown-linux-gnu-ld.gold")
,("ld flags","")
,("ld supports compact unwind","YES")
,("ld supports build-id","YES")
,("ld supports filelist","NO")
,("ld is GNU ld","YES")
,("ar command","powerpc-unknown-linux-gnu-ar")
,("ar flags","q")
,("ar supports at file","YES")
,("ranlib command","powerpc-unknown-linux-gnu-ranlib")
,("touch command","touch")
,("dllwrap command","/bin/false")
,("windres command","/bin/false")
,("libtool command","libtool")
,("perl command","/usr/bin/perl")
,("cross compiling","YES")
,("target os","OSLinux")
,("target arch","ArchPPC")
,("target word size","4")
,("target has GNU nonexec stack","True")
,("target has .ident directive","True")
,("target has subsections via symbols","False")
,("target has RTS linker","YES")
,("Unregisterised","NO")
,("LLVM llc command","llc")
,("LLVM opt command","opt")
,("LLVM clang command","clang")
,("Project version","8.7.20181223")
,("Project Git commit id","bd8a6bde2ee73e599800137b9428a401bc105985")
,("Booter version","8.4.4")
,("Stage","1")
,("Build platform","x86_64-unknown-linux")
,("Host platform","x86_64-unknown-linux")
,("Target platform","powerpc-unknown-linux")
,("Have interpreter","YES")
,("Object splitting supported","YES")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Tables next to code","YES")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn thr_debug_p debug_p")
,("RTS expects libdw","NO")
,("Support dynamic-too","YES")
,("Support parallel --make","YES")
,("Support reexported-modules","YES")
,("Support thinning and renaming package flags","YES")
,("Support Backpack","YES")
,("Requires unified installed package IDs","YES")
,("Uses package keys","YES")
,("Uses unit IDs","YES")
,("Dynamic by default","NO")
,("GHC Dynamic","NO")
,("GHC Profiled","NO")
,("Leading underscore","NO")
,("Debug on","False")
,("LibDir","/home/slyfox/dev/git/ghc-ppc/inplace/lib")
,("Global Package DB","/home/slyfox/dev/git/ghc-ppc/inplace/lib/package.conf.d")
]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64]","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"On current HEAD ghc fails build on powerpc32:\r\n\r\n{{{\r\n$ ./configure --target=powerpc-unknown-linux-gnu\r\n$ make\r\n...\r\n\"inplace/bin/ghc-stage1\" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o\r\nghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 8.7.20181223 for powerpc-unknown-linux):\r\n getRegister(ppc)\r\n I64[I32[BaseReg + 812] + 64]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable\r\n pprPanic, called at compiler/nativeGen/PPC/CodeGen.hs:693:24 in ghc:PPC.CodeGen\r\n}}}\r\n\r\n{{{\r\n$ inplace/bin/ghc-stage1 --info\r\n [(\"Project name\",\"The Glorious Glasgow Haskell Compilation System\")\r\n ,(\"GCC extra via C opts\",\" -fwrapv -fno-builtin\")\r\n ,(\"C compiler command\",\"powerpc-unknown-linux-gnu-gcc\")\r\n ,(\"C compiler flags\",\" -fno-stack-protector\")\r\n ,(\"C compiler link flags\",\" -fuse-ld=gold\")\r\n ,(\"C compiler supports -no-pie\",\"YES\")\r\n ,(\"Haskell CPP command\",\"powerpc-unknown-linux-gnu-gcc\")\r\n ,(\"Haskell CPP flags\",\"-E -undef -traditional\")\r\n ,(\"ld command\",\"powerpc-unknown-linux-gnu-ld.gold\")\r\n ,(\"ld flags\",\"\")\r\n ,(\"ld supports compact unwind\",\"YES\")\r\n ,(\"ld supports build-id\",\"YES\")\r\n ,(\"ld supports filelist\",\"NO\")\r\n ,(\"ld is GNU ld\",\"YES\")\r\n ,(\"ar command\",\"powerpc-unknown-linux-gnu-ar\")\r\n ,(\"ar flags\",\"q\")\r\n ,(\"ar supports at file\",\"YES\")\r\n ,(\"ranlib command\",\"powerpc-unknown-linux-gnu-ranlib\")\r\n ,(\"touch command\",\"touch\")\r\n ,(\"dllwrap command\",\"/bin/false\")\r\n ,(\"windres command\",\"/bin/false\")\r\n ,(\"libtool command\",\"libtool\")\r\n ,(\"perl command\",\"/usr/bin/perl\")\r\n ,(\"cross compiling\",\"YES\")\r\n ,(\"target os\",\"OSLinux\")\r\n ,(\"target arch\",\"ArchPPC\")\r\n ,(\"target word size\",\"4\")\r\n ,(\"target has GNU nonexec stack\",\"True\")\r\n ,(\"target has .ident directive\",\"True\")\r\n ,(\"target has subsections via symbols\",\"False\")\r\n ,(\"target has RTS linker\",\"YES\")\r\n ,(\"Unregisterised\",\"NO\")\r\n ,(\"LLVM llc command\",\"llc\")\r\n ,(\"LLVM opt command\",\"opt\")\r\n ,(\"LLVM clang command\",\"clang\")\r\n ,(\"Project version\",\"8.7.20181223\")\r\n ,(\"Project Git commit id\",\"bd8a6bde2ee73e599800137b9428a401bc105985\")\r\n ,(\"Booter version\",\"8.4.4\")\r\n ,(\"Stage\",\"1\")\r\n ,(\"Build platform\",\"x86_64-unknown-linux\")\r\n ,(\"Host platform\",\"x86_64-unknown-linux\")\r\n ,(\"Target platform\",\"powerpc-unknown-linux\")\r\n ,(\"Have interpreter\",\"YES\")\r\n ,(\"Object splitting supported\",\"YES\")\r\n ,(\"Have native code generator\",\"YES\")\r\n ,(\"Support SMP\",\"YES\")\r\n ,(\"Tables next to code\",\"YES\")\r\n ,(\"RTS ways\",\"l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn thr_debug_p debug_p\")\r\n ,(\"RTS expects libdw\",\"NO\")\r\n ,(\"Support dynamic-too\",\"YES\")\r\n ,(\"Support parallel --make\",\"YES\")\r\n ,(\"Support reexported-modules\",\"YES\")\r\n ,(\"Support thinning and renaming package flags\",\"YES\")\r\n ,(\"Support Backpack\",\"YES\")\r\n ,(\"Requires unified installed package IDs\",\"YES\")\r\n ,(\"Uses package keys\",\"YES\")\r\n ,(\"Uses unit IDs\",\"YES\")\r\n ,(\"Dynamic by default\",\"NO\")\r\n ,(\"GHC Dynamic\",\"NO\")\r\n ,(\"GHC Profiled\",\"NO\")\r\n ,(\"Leading underscore\",\"NO\")\r\n ,(\"Debug on\",\"False\")\r\n ,(\"LibDir\",\"/home/slyfox/dev/git/ghc-ppc/inplace/lib\")\r\n ,(\"Global Package DB\",\"/home/slyfox/dev/git/ghc-ppc/inplace/lib/package.conf.d\")\r\n ]\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/16093mkPluginUsage: file not found2021-06-08T19:30:58ZLevent ErkökmkPluginUsage: file not foundI have the following `TestPlugin.hs` file:
```hs
module TestPlugin (plugin) where
import GhcPlugins
plugin :: Plugin
plugin = defaultPlugin {installCoreToDos = install}
where install _ todos = return (test : todos)
test = C...I have the following `TestPlugin.hs` file:
```hs
module TestPlugin (plugin) where
import GhcPlugins
plugin :: Plugin
plugin = defaultPlugin {installCoreToDos = install}
where install _ todos = return (test : todos)
test = CoreDoPluginPass "Test" return
```
And the following `Test.hs` file:
```hs
{-# OPTIONS_GHC -fplugin TestPlugin #-}
main :: IO ()
main = return ()
```
They are both in the same directory. With ghc 8.4.2, I have:
```
$ ghci-8.4.2 -package ghc Test.hs
GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help
[1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted )
[2 of 2] Compiling Main ( Test.hs, interpreted )
Ok, two modules loaded.
```
But with ghc 8.6.3, I get:
```
$ ghci-8.6.3 -package ghc Test.hs
GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help
[1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted )
[2 of 2] Compiling Main ( Test.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.3 for x86_64-apple-darwin):
mkPluginUsage: file not found
TestPlugin ./TestPlugin.o
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/deSugar/DsUsage.hs:234:15 in ghc:DsUsage
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The problem goes away if I first compile `TestPlugin.hs` and create a `.o` file; but nonetheless this seems to be a regression from 8.4.2.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/16092Bug when trying to combine two lists2019-07-07T18:01:33ZsutbultBug when trying to combine two listsI want to write a function that takes two lists and returns a list that includes every possible combination of elements from the two given lists, using a given function. I thought that this code would work:
```hs
combine :: (a -> b -> c...I want to write a function that takes two lists and returns a list that includes every possible combination of elements from the two given lists, using a given function. I thought that this code would work:
```hs
combine :: (a -> b -> c) [a] -> [b] -> [c]
combine fn alist blist = [fn a b | a <- alist, b <- blist]
```
However, when compiling, this message arises from GHC:
```
Glasgow Haskell Compiler, Version 8.2.1, stage 2 booted by GHC version 7.10.3
Using binary package database: /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d/package.cache
Using binary package database: /Users/samuelutbult/.ghc/x86_64-darwin-8.2.1/package.conf.d/package.cache
package flags []
loading package database /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d
loading package database /Users/samuelutbult/.ghc/x86_64-darwin-8.2.1/package.conf.d
wired-in package ghc-prim mapped to ghc-prim-0.5.1.0
wired-in package integer-gmp mapped to integer-gmp-1.0.1.0
wired-in package base mapped to base-4.10.0.0
wired-in package rts mapped to rts
wired-in package template-haskell mapped to template-haskell-2.12.0.0
wired-in package ghc mapped to ghc-8.2.1
wired-in package dph-seq not found.
wired-in package dph-par not found.
package flags []
loading package database /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d
loading package database /Users/samuelutbult/.ghc/x86_64-darwin-8.2.1/package.conf.d
wired-in package ghc-prim mapped to ghc-prim-0.5.1.0
wired-in package integer-gmp mapped to integer-gmp-1.0.1.0
wired-in package base mapped to base-4.10.0.0
wired-in package rts mapped to rts-1.0
wired-in package template-haskell mapped to template-haskell-2.12.0.0
wired-in package ghc mapped to ghc-8.2.1
wired-in package dph-seq not found.
wired-in package dph-par not found.
*** Chasing dependencies:
Chasing modules from: *Combine.hs
!!! Chasing dependencies: finished in 0.69 milliseconds, allocated 0.222 megabytes
Stable obj: []
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = 2018-12-23 17:18:05.830132761 UTC
ms_mod = Main,
ms_textual_imps = [(Nothing, Prelude)]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file Combine.hs
*** Checking old interface for Main (use -ddump-hi-diffs for more details):
[1 of 1] Compiling Main ( Combine.hs, Combine.o )
*** Parser [Main]:
!!! Parser [Main]: finished in 1.05 milliseconds, allocated 0.171 megabytes
*** Renamer/typechecker [Main]:
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.1 for x86_64-apple-darwin):
repSplitAppTys
a_anL[sk:1]
b_anM[sk:1] -> c_anN[sk:1]
[]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```https://gitlab.haskell.org/ghc/ghc/-/issues/16091arith011 broken with integer-simple2019-07-07T18:01:33ZBen Gamariarith011 broken with integer-simpleThe `arith011` test fails unexpected when using `integer-simple`.
The test output is [quite long](https://gitlab.haskell.org/ghc/ghc/-/jobs/4892/raw) but here is the end:
```
#
negate 0 = 0
#
testReal
toRational 0 = 0 % 1
toRational 1 ...The `arith011` test fails unexpected when using `integer-simple`.
The test output is [quite long](https://gitlab.haskell.org/ghc/ghc/-/jobs/4892/raw) but here is the end:
```
#
negate 0 = 0
#
testReal
toRational 0 = 0 % 1
toRational 1 = 1 % 1
toRational 2 = 2 % 1
toRational 3 = 3 % 1
#
testIntegral
Stderr ( arith011 ):
arith011: divide by zero
*** unexpected failure for arith011(normal)
```
This is concerning since it suggests a behavioral difference between `integer-simple` and `integer-gmp`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"arith011 broken with integer-simple","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `arith011` test fails unexpected when using `integer-simple`. \r\n\r\nThe test output is [[https://gitlab.haskell.org/ghc/ghc/-/jobs/4892/raw|quite long]] but here is the end:\r\n{{{\r\n#\r\nnegate 0 = 0\r\n#\r\ntestReal\r\ntoRational 0 = 0 % 1\r\ntoRational 1 = 1 % 1\r\ntoRational 2 = 2 % 1\r\ntoRational 3 = 3 % 1\r\n#\r\ntestIntegral\r\nStderr ( arith011 ):\r\narith011: divide by zero\r\n*** unexpected failure for arith011(normal)\r\n}}}\r\nThis is concerning since it suggests a behavioral difference between `integer-simple` and `integer-gmp`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16090Typeset Big-O complexities with TeX-style notation in libraries/base2019-07-07T18:01:33ZSven TennieTypeset Big-O complexities with TeX-style notation in libraries/baseIn the code review of #15003, \@hvr proposed to typeset Big-Os in TeX-style instead of using italic (1). This will lead to a more idiomatic typesetting.
See 2 for an example.
- \*Task:\*\* Replace all italic Big-Os in libraries/base wi...In the code review of #15003, \@hvr proposed to typeset Big-Os in TeX-style instead of using italic (1). This will lead to a more idiomatic typesetting.
See 2 for an example.
- \*Task:\*\* Replace all italic Big-Os in libraries/base with TeX-style notation.
1. - https://github.com/ghc/ghc/pull/239
1. - https://hackage.haskell.org/package/text-containers-0.1.0.0/docs/Data-TextSet-Unboxed.html\#v:size
Please Note: I'm creating this ticket in trac, because the GitLab migration doesn't seem to be finished, yet.
If this leads to any troubles: Please don't care about this ticket - When I see that this ticket isn't migrated, I'll simply re-create it in GitLab.Sven TennieSven Tenniehttps://gitlab.haskell.org/ghc/ghc/-/issues/16089seq is not cooperating with :sprint in GHCi as expected2023-08-29T00:32:45Zradrowseq is not cooperating with :sprint in GHCi as expectedI was playing around with strictness and performed following test:
```hs
Prelude> x = [True, False]
Prelude> :sprint x
x = _
Prelude> x `seq` True
True
Prelude> :sprint x
x = _
```
I completely don't understand why `x = _` at this mome...I was playing around with strictness and performed following test:
```hs
Prelude> x = [True, False]
Prelude> :sprint x
x = _
Prelude> x `seq` True
True
Prelude> :sprint x
x = _
```
I completely don't understand why `x = _` at this moment. `seq` must evaluate one level of `x` achieving `x = True : _` to ensure that it is not `undefined`, so why is this information lost?
I am testing it on GHCi version 8.6.3, but it is not reproducible on other versions (checked on 8.4.4, 8.2.2 and 7._._).
I have asked about it on SO, so if this behavior is intended I kindly ask for explaination here [https://stackoverflow.com/questions/53898220/sprint-and-seq-together-missing-evaluation](https://stackoverflow.com/questions/53898220/sprint-and-seq-together-missing-evaluation) to let others know.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.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":"seq is not cooperating with :sprint in GHCi as expected","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":["seq","sprint","strictness"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was playing around with strictness and performed following test:\r\n\r\n{{{#!hs\r\nPrelude> x = [True, False]\r\nPrelude> :sprint x\r\nx = _\r\nPrelude> x `seq` True\r\nTrue\r\nPrelude> :sprint x\r\nx = _\r\n}}}\r\n\r\nI completely don't understand why `x = _` at this moment. `seq` must evaluate one level of `x` achieving `x = True : _` to ensure that it is not `undefined`, so why is this information lost? \r\n\r\nI am testing it on GHCi version 8.6.3, but it is not reproducible on other versions (checked on 8.4.4, 8.2.2 and 7._._). \r\n\r\nI have asked about it on SO, so if this behavior is intended I kindly ask for explaination here [https://stackoverflow.com/questions/53898220/sprint-and-seq-together-missing-evaluation] to let others know.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1