GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-01-21T12:06:26Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/17969The haddocks for `sortWith` should give guidance about when it's prefered ove...2024-01-21T12:06:26ZAndreas KlebingerThe haddocks for `sortWith` should give guidance about when it's prefered over `sortOn`As ben explained it somewhere else:
> In general if the mapping function is expensive to compute then you should probably be using `sortOn`, as it only needs to compute it once for each element. `sortWith`, on the other hand must comput...As ben explained it somewhere else:
> In general if the mapping function is expensive to compute then you should probably be using `sortOn`, as it only needs to compute it once for each element. `sortWith`, on the other hand must compute the mapping function for every comparison that it performs. Beyond that general intuition it's hard to give any specific prescription.
I think even without more specific guidance stating this much in the docs would be good.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/17127Remove `StringBuffer` in favor of `Text` or `ByteString`2021-04-22T08:13:57ZSebastian GrafRemove `StringBuffer` in favor of `Text` or `ByteString`@mpickering noticed that GHC seems to have its own type that is practically identical to `Text`/`ByteString`, called `StringBuffer`.
We should investigate how to remove it/make it a newtype around `Text` or `ByteString` without incurrin...@mpickering noticed that GHC seems to have its own type that is practically identical to `Text`/`ByteString`, called `StringBuffer`.
We should investigate how to remove it/make it a newtype around `Text` or `ByteString` without incurring any performance hit.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/16969Refactor MonadUtils and friends to export functions constrained by Foldable i...2023-11-27T10:34:56ZSebastian GrafRefactor MonadUtils and friends to export functions constrained by Foldable instead of hard-coded []`MonadUtils` exports versions of `foldlM`, `foldlM_` and `foldrM` specialised to `[]`. `Bag` also defines its own `foldM`-style combinators. There are probably some other examples. We have had `Data.Foldable` now for some time, so use it.`MonadUtils` exports versions of `foldlM`, `foldlM_` and `foldrM` specialised to `[]`. `Bag` also defines its own `foldM`-style combinators. There are probably some other examples. We have had `Data.Foldable` now for some time, so use it.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/16886-dump-hi includes more information that --show-iface2023-02-21T16:56:53ZNeil Mitchell-dump-hi includes more information that --show-ifaceGiven a file:
```
main = print 1
```
If you compile and show the interface with:
```
$ ghc -ddump-to-file -ddump-hi Main.hs
$ ghc --show-iface Main.hi > Main.show-iface
```
I would expect `Main.dump-hi` (created by the first line) an...Given a file:
```
main = print 1
```
If you compile and show the interface with:
```
$ ghc -ddump-to-file -ddump-hi Main.hs
$ ghc --show-iface Main.hi > Main.show-iface
```
I would expect `Main.dump-hi` (created by the first line) and `Main.show-iface` (created by the second line) to contain roughly the same contents. However, the second form of dumping only shows a subset of the first. As an example:
* `Main.dump-hi` contains `import -/ base-4.12.0.0:Prelude 80c668cb99fbafebd524c5e897f8c982`
* `Main.show-iface` contains `import -/ Prelude 80c668cb99fbafebd524c5e897f8c982`
Importantly (and for what I'm trying to do, frustratingly) the second form lacks the package name. I would have expected both versions to be roughly the same. I use the information from the `.hi` files in [Weeder](https://github.com/ndmitchell/weeder). In old versions I relied on the fact Stack passed `-ddump-hi`. Now that it doesn't I want to manually dump the `.hi` files after the fact, which is not as easy as I hoped.
GHC 8.6.5 x86_64 on Windows.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/16800Hadrian: Symlink Breaks Cached Builds2019-07-09T09:40:40ZDavid EichmannHadrian: Symlink Breaks Cached Builds# Recreation
```bash
$ ./hadrian/build.sh --share=_cache -j --flavour=quickest
...
Error when running Shake build system:
at action, called at src/Rules.hs:68:19 in main:Rules
at need, called at src/Rules.hs:90:5 in main:Rules
* Dep...# Recreation
```bash
$ ./hadrian/build.sh --share=_cache -j --flavour=quickest
...
Error when running Shake build system:
at action, called at src/Rules.hs:68:19 in main:Rules
at need, called at src/Rules.hs:90:5 in main:Rules
* Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf
at need, called at src/Rules/Register.hs:101:5 in main:Rules.Register
* Depends on: _build/stage1/rts/build/libCffi_thr.a
* Raised the exception:
_cache/.shake.cache/5029bef81b20dfbd/0xF03C561F: getPermissions:getFileStatus: does not exist (No such file or directory)
$ ls -l _cache/.shake.cache/5029bef81b20dfbd/0xF03C561F
lrwxrwxrwx 2 david david 9 Jun 11 16:54 _cache/.shake.cache/5029bef81b20dfbd/0xF03C561F -> libCffi.a
```
`_cache/.shake.cache/5029bef81b20dfbd/0xF03C561F` is a broken link, but is "correct" in the sense that we want to copy the symlink as is so that `_build/stage1/rts/build/libCffi_thr.a` is a symlink to `_build/stage1/rts/build/libCffi.a`. This seems like a bug in Shake: it manages to correctly copy the symlink into the cache, but fails on the way back out.⊥David EichmannDavid Eichmannhttps://gitlab.haskell.org/ghc/ghc/-/issues/16696Remove Unique field in StgFCallOp2019-07-07T18:00:04ZAndrew MartinRemove Unique field in StgFCallOpIn https://gitlab.haskell.org/ghc/ghc/merge_requests/939#note_200198, Simon mentions that the `Unique` field in `StgFCallOp` is unused and can be removed. I'm opening this as a reminder to myself to do this after I've dealt with the bigg...In https://gitlab.haskell.org/ghc/ghc/merge_requests/939#note_200198, Simon mentions that the `Unique` field in `StgFCallOp` is unused and can be removed. I'm opening this as a reminder to myself to do this after I've dealt with the bigger problem in that issue.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/15651Check if some auto apply code is dead and remove if appropriate.2021-09-07T15:56:33ZAndreas KlebingerCheck if some auto apply code is dead and remove if appropriate.There is a whole family of stg_ap_stk_\* and stg_stk_save_\* functions generated in AutoApply.cmm which as far as I can tell is not used anywhere in the compiler and can likely be removed.
In particular this would involve:
- Stop the c...There is a whole family of stg_ap_stk_\* and stg_stk_save_\* functions generated in AutoApply.cmm which as far as I can tell is not used anywhere in the compiler and can likely be removed.
In particular this would involve:
- Stop the code in question from being generated. (utils/genapply)
- Make sure that doesn't break things. (Validate/Run the testsuite).
- Grep for stk in the compiler to make sure we don't build calls to these in rare circumstances with string concatenation for extra safety.
- Document the change in patch notes just in case.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Check if some auto apply code is dead and remove if appropriate.","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["Newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"There is a whole family of stg_ap_stk_* and stg_stk_save_* functions generated in AutoApply.cmm which as far as I can tell is not used anywhere in the compiler and can likely be removed.\r\n\r\nIn particular this would involve:\r\n* Stop the code in question from being generated. (utils/genapply)\r\n* Make sure that doesn't break things. (Validate/Run the testsuite).\r\n* Grep for stk in the compiler to make sure we don't build calls to these in rare circumstances with string concatenation for extra safety.\r\n* Document the change in patch notes just in case.","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/15510Qualified Holes2021-09-07T15:52:15ZAndrew MartinQualified HolesLet us consider the following example code:
```
import qualified Data.Map as M
main :: IO ()
main = print (M._ (\k v acc -> k + v + acc) 0 myMap)
myMap :: Map Int Int
myMap = ...
```
This errors with `Not in scope: M._`. It would coo...Let us consider the following example code:
```
import qualified Data.Map as M
main :: IO ()
main = print (M._ (\k v acc -> k + v + acc) 0 myMap)
myMap :: Map Int Int
myMap = ...
```
This errors with `Not in scope: M._`. It would cool if GHC instead treated `M._` as a hole but only gave suggestions from the module `Data.Map`. So, in this case, it would suggest things like `Data.Map.foldrWithKey` and `Data.Map.foldlWithKey`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Qualified Holes","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":"Let us consider the following example code:\r\n\r\n{{{\r\nimport qualified Data.Map as M\r\n\r\nmain :: IO ()\r\nmain = print (M._ (\\k v acc -> k + v + acc) 0 myMap)\r\n\r\nmyMap :: Map Int Int\r\nmyMap = ...\r\n}}}\r\n\r\nThis errors with `Not in scope: M._`. It would cool if GHC instead treated `M._` as a hole but only gave suggestions from the module `Data.Map`. So, in this case, it would suggest things like `Data.Map.foldrWithKey` and `Data.Map.foldlWithKey`.","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/15483ghc -M requires -dep-suffix for no good reason2021-09-17T14:17:53ZArtem Pelenitsynghc -M requires -dep-suffix for no good reasonDoing
```
ghc -M Foo.hs
```
gives
```
You must specify at least one -dep-suffix
```
I went to the documentation and noticed ([7.8.12](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate_compilation.html#makefile-...Doing
```
ghc -M Foo.hs
```
gives
```
You must specify at least one -dep-suffix
```
I went to the documentation and noticed ([7.8.12](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate_compilation.html#makefile-dependencies)) an example:
```
depend :
ghc -dep-suffix '' -M $(HC_OPTS) $(SRCS)
```
So, empty suffix is fine. Why not default to empty string then?
I found a commit which introduced the requirement ([af072fc](https://github.com/ghc/ghc/commit/af072fc35d8dbe7962e62700da052593e999c0ef)): it says, it fixed #7381, and this doesn't seem to do anything with `dep-suffix` in particular. So, maybe there is no good reason to require that.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc -M requires -dep-suffix for no good reason","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Doing\r\n{{{\r\nghc -M Foo.hs\r\n}}}\r\ngives\r\n{{{\r\nYou must specify at least one -dep-suffix\r\n}}}\r\nI went to the documentation and noticed ([https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate_compilation.html#makefile-dependencies 7.8.12]) an example:\r\n{{{\r\ndepend :\r\n ghc -dep-suffix '' -M $(HC_OPTS) $(SRCS)\r\n}}}\r\nSo, empty suffix is fine. Why not default to empty string then?\r\n\r\nI found a commit which introduced the requirement ([https://github.com/ghc/ghc/commit/af072fc35d8dbe7962e62700da052593e999c0ef af072fc]): it says, it fixed #7381, and this doesn't seem to do anything with `dep-suffix` in particular. So, maybe there is no good reason to require that.","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/15402The settings and behaviour of idle GC are very confusing2021-09-07T15:22:00ZNiklas Hambüchenmail@nh2.meThe settings and behaviour of idle GC are very confusingThis extracting the issue between comments
- #13497\##15402 and
- #13497\##15402
into their own issue.
There are a few problems problems (as of GHC 8.4.3):
- \*1) You can't disable idle GC.\*\*
- This is contrary to the [manual](http...This extracting the issue between comments
- #13497\##15402 and
- #13497\##15402
into their own issue.
There are a few problems problems (as of GHC 8.4.3):
- \*1) You can't disable idle GC.\*\*
- This is contrary to the [manual](https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/runtime_control.html#rts-flag--I%20%E2%9F%A8seconds%E2%9F%A9), which says `Specifying -I0 disables the idle GC.`.
- Passing `+RTS -I0` will run the idle GC a few times and then it will stop. [Detailed here](https://ghc.haskell.org/trac/ghc/ticket/13497#comment:10).
- It will run in intervals of `0.3` seconds (which is claimed to be the default for `-I` in the manual).
- \*2) Giving the default for `+RTS -I` explicitly, namely `+RTS -I0.3`, changes the behaviour.\*\*
- With it given, idle GC will run every 0.3 seconds.
- With it not given, it will run for a few times at 0.3 second and then stop.
- This is exactly the behaviour of `-I0`. So if the manual said "the default for `-I` is `-I0`, that would be (perversely) more accurate.
- \*3) The docs suggest idle GC is only in effect with `-threaded`.\*\*
- [manual "In the threaded and SMP versions of the RTS (see -threaded ...)."](https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/runtime_control.html#rts-flag--I%20%E2%9F%A8seconds%E2%9F%A9)
- But idle GC settings like `+RTS -I` clearly also affect the nonthreaded RTS.
- \*4) The concept of running the idle GC "for a little while" is a bit dubious in my opinion.\*\*
- Its [origin as a power-saving mechanism](https://ghc.haskell.org/trac/ghc/ticket/13497#comment:13) is sensible.
- But it makes things "weird": When you look at `strace`, then first there's `SIGVTALRM` going on (because the idle GC timer of 0.3 seconds is checked against in each timer signal tick of 0.02 seconds by default), then after some time they suddenly stop. Of course `SIGVTALRM` occurring can also have effects on underlying library calls (syscalls return with `EINTR`), so (at least in non`-threaded`) a simple idling Haskell program creates some time-dependent behaviour on C libraries being used.
- This makes debugging signal issues and behaviour extra hard, if you constantly have to keep in mind "oh but in the next 0.3 seconds the program will behave like this, and then behaviour will change. When you're debugging with `strace`, you have to be constantly aware whether or not the current output you read is inside or outside that time window.
- But I don't have an idea of how this could be improved without sacrificing something else, so I guess this point just remains as "weird" for now.
----
I think points 1-3 are fixable, we should perhaps
\* make `-I<thedefaultvalue>` behave the same as not giving `-I`
\* change the "default value" to something that reflects what the current default behaviour actually is
- the actual possibilities for this option expressed in Haskell would be `data IdleGcMode = NoneAtAll | StoppingAfterSeconds Double | IntervalSeconds Double`
- so perhaps we should change `-I` to allow passing the following values to it:
\* `-I<seconds>`, e.g. `-I0.3` to mean `IntervalSeconds 0.3`
\* `-I<seconds>stopping`, e.g. `-I0.3stopping` to mean `StoppingAfterSeconds 0.3`
\* `-I0` to mean `NoneAtAll`
- and the default would be `-I0.3stopping` to reflect the current default.
- fix the documentation to reflect all this
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The settings and behaviour of idle GC are very confusing","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2","simonmar"],"type":"Bug","description":"This extracting the issue between comments\r\n\r\n* https://ghc.haskell.org/trac/ghc/ticket/13497#comment:3 and\r\n* https://ghc.haskell.org/trac/ghc/ticket/13497#comment:14\r\n\r\ninto their own issue.\r\n\r\nThere are a few problems problems (as of GHC 8.4.3):\r\n\r\n**1) You can't disable idle GC.**\r\n\r\n* This is contrary to the [https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/runtime_control.html#rts-flag--I%20%E2%9F%A8seconds%E2%9F%A9 manual], which says `Specifying -I0 disables the idle GC.`.\r\n* Passing `+RTS -I0` will run the idle GC a few times and then it will stop. [https://ghc.haskell.org/trac/ghc/ticket/13497#comment:10 Detailed here].\r\n* It will run in intervals of `0.3` seconds (which is claimed to be the default for `-I` in the manual).\r\n\r\n**2) Giving the default for `+RTS -I` explicitly, namely `+RTS -I0.3`, changes the behaviour.**\r\n\r\n* With it given, idle GC will run every 0.3 seconds.\r\n* With it not given, it will run for a few times at 0.3 second and then stop.\r\n* This is exactly the behaviour of `-I0`. So if the manual said \"the default for `-I` is `-I0`, that would be (perversely) more accurate.\r\n\r\n**3) The docs suggest idle GC is only in effect with `-threaded`.**\r\n\r\n* [https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/runtime_control.html#rts-flag--I%20%E2%9F%A8seconds%E2%9F%A9 manual \"In the threaded and SMP versions of the RTS (see -threaded ...).\"]\r\n* But idle GC settings like `+RTS -I` clearly also affect the nonthreaded RTS.\r\n\r\n**4) The concept of running the idle GC \"for a little while\" is a bit dubious in my opinion.**\r\n\r\n* Its [https://ghc.haskell.org/trac/ghc/ticket/13497#comment:13 origin as a power-saving mechanism] is sensible.\r\n* But it makes things \"weird\": When you look at `strace`, then first there's `SIGVTALRM` going on (because the idle GC timer of 0.3 seconds is checked against in each timer signal tick of 0.02 seconds by default), then after some time they suddenly stop. Of course `SIGVTALRM` occurring can also have effects on underlying library calls (syscalls return with `EINTR`), so (at least in non`-threaded`) a simple idling Haskell program creates some time-dependent behaviour on C libraries being used.\r\n* This makes debugging signal issues and behaviour extra hard, if you constantly have to keep in mind \"oh but in the next 0.3 seconds the program will behave like this, and then behaviour will change. When you're debugging with `strace`, you have to be constantly aware whether or not the current output you read is inside or outside that time window.\r\n* But I don't have an idea of how this could be improved without sacrificing something else, so I guess this point just remains as \"weird\" for now.\r\n\r\n----\r\n\r\nI think points 1-3 are fixable, we should perhaps\r\n\r\n* make `-I<thedefaultvalue>` behave the same as not giving `-I`\r\n* change the \"default value\" to something that reflects what the current default behaviour actually is\r\n * the actual possibilities for this option expressed in Haskell would be `data IdleGcMode = NoneAtAll | StoppingAfterSeconds Double | IntervalSeconds Double`\r\n * so perhaps we should change `-I` to allow passing the following values to it:\r\n * `-I<seconds>`, e.g. `-I0.3` to mean `IntervalSeconds 0.3`\r\n * `-I<seconds>stopping`, e.g. `-I0.3stopping` to mean `StoppingAfterSeconds 0.3`\r\n * `-I0` to mean `NoneAtAll`\r\n * and the default would be `-I0.3stopping` to reflect the current default.\r\n* fix the documentation to reflect all this","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/13392ghc --show-options lists flags twice2019-07-07T18:22:06ZThreeFxghc --show-options lists flags twiceRunning `ghc --show-options` with GHC version 8.0.1 returns the flags `-O` and `-W` twice.
To check this, execute the following command in your shell:
```
ghc --show-options | sort | uniq -d
```
At commit `669333d8afaf388a3ce4a56e383b...Running `ghc --show-options` with GHC version 8.0.1 returns the flags `-O` and `-W` twice.
To check this, execute the following command in your shell:
```
ghc --show-options | sort | uniq -d
```
At commit `669333d8afaf388a3ce4a56e383b24ea2bdea145` (GHC 8.1.20170304) only `-O` is duplicated.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"ghc --show-options lists flags twice","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"⊥","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Running `ghc --show-options` with GHC version 8.0.1 returns the flags `-O` and `-W` twice.\r\n\r\nTo check this, execute the following command in your shell:\r\n\r\n{{{\r\nghc --show-options | sort | uniq -d\r\n}}}\r\n\r\nAt commit `669333d8afaf388a3ce4a56e383b24ea2bdea145` (GHC 8.1.20170304) only `-O` is duplicated.","type_of_failure":"OtherFailure","blocking":[]} -->⊥SantiMSantiMhttps://gitlab.haskell.org/ghc/ghc/-/issues/11280getCurrentDirectory should raise better error string when cwd doesn't exist2019-07-07T18:31:08ZEdward Z. YanggetCurrentDirectory should raise better error string when cwd doesn't existRun this script in a directory which no longer exists:
```
import System.Directory
main = getCurrentDirectory >>= putStrLn
```
Currently the error looks like:
```
ezyang@sabre:~/test$ ./test
bash: ./test: No such file or directory
```...Run this script in a directory which no longer exists:
```
import System.Directory
main = getCurrentDirectory >>= putStrLn
```
Currently the error looks like:
```
ezyang@sabre:~/test$ ./test
bash: ./test: No such file or directory
```
It would be nicer to give a better message in this case.
Originally reported https://github.com/haskell/cabal/issues/2902
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/directory |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getCurrentDirectory should raise better error string when cwd doesn't exist","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"⊥","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":["easy"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Run this script in a directory which no longer exists:\r\n\r\n{{{\r\nimport System.Directory\r\nmain = getCurrentDirectory >>= putStrLn\r\n}}}\r\n\r\nCurrently the error looks like:\r\n\r\n{{{\r\nezyang@sabre:~/test$ ./test\r\nbash: ./test: No such file or directory\r\n}}}\r\n\r\nIt would be nicer to give a better message in this case.\r\n\r\nOriginally reported https://github.com/haskell/cabal/issues/2902","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/8949Deprecate -msse2 and -msse flags2021-09-07T15:27:12ZerrgeDeprecate -msse2 and -msse flagsI propose msse2 to be on by default. I guess the default was chosen way back, when Pentium III support was still relevant.
Nowadays we don't really win on the CPU support, because e.g. https://github.com/tibbe/hashable/blob/master/hasha...I propose msse2 to be on by default. I guess the default was chosen way back, when Pentium III support was still relevant.
Nowadays we don't really win on the CPU support, because e.g. https://github.com/tibbe/hashable/blob/master/hashable.cabal is built by default with sse2 on the injected C code level. And hashable has a lot of reverse depends, therefore on an end user system (RedHat or Debian) the user is most probably unlucky with a Pentium III CPU anyways.
Flipping this default would also fix the excess precision problem for most users of GHC on the i686 platform.
GHC should provide a -mno-sse2 flag for the cases when this needs to be disabled.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"switch -msse2 to be on by default","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"I propose msse2 to be on by default. I guess the default was chosen way back, when Pentium III support was still relevant.\r\n\r\nNowadays we don't really win on the CPU support, because e.g. https://github.com/tibbe/hashable/blob/master/hashable.cabal is built by default with sse2 on the injected C code level. And hashable has a lot of reverse depends, therefore on an end user system (RedHat or Debian) the user is most probably unlucky with a Pentium III CPU anyways.\r\n\r\nFlipping this default would also fix the excess precision problem for most users of GHC on the i686 platform.\r\n\r\nGHC should provide a -mno-sse2 flag for the cases when this needs to be disabled.","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/8316GHCi debugger panics when trying force a certain variable2019-07-07T18:45:35ZguestGHCi debugger panics when trying force a certain variableThe file Test.hs has following definition:
```
foo :: [Int]
foo = [1..]
```
Calling ghci as:
```
ghci Test.hs -ignore-dot-ghci
```
and bebugging foo like this:
```
*Main> :break foo
Breakpoint 0 activated at main.hs:2:7-11
*Main> fo...The file Test.hs has following definition:
```
foo :: [Int]
foo = [1..]
```
Calling ghci as:
```
ghci Test.hs -ignore-dot-ghci
```
and bebugging foo like this:
```
*Main> :break foo
Breakpoint 0 activated at main.hs:2:7-11
*Main> foo
Stopped in Main.foo, main.hs:2:7-11
_result :: [Int] = _
[main.hs:2:7-11] *Main> :print foo
foo = (_t1::[Int])
[main.hs:2:7-11] *Main> _t1
```
results in this panic:
```
<interactive>: internal error: TSO object entered!
(GHC version 8.5.20180302 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[1] 5445 abort (core dumped) ghci Test.hs -ignore-dot-ghci
```⊥NolanNolan