GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:02:33Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15892Segmentation fault with ByteString2019-07-07T18:02:33Ztakano-akioSegmentation fault with ByteStringThe attached program consistently segfaults (within a few seconds) when compiled with ghc-8.6.1 or ghc-8.6.2. It runs forever (as expected) when compiled with ghc-8.4.
To reproduce:
```
ghc segfault.hs
```
then,
```
./segfault >/dev/...The attached program consistently segfaults (within a few seconds) when compiled with ghc-8.6.1 or ghc-8.6.2. It runs forever (as expected) when compiled with ghc-8.4.
To reproduce:
```
ghc segfault.hs
```
then,
```
./segfault >/dev/null
```
<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":"Segmentation fault with ByteString and -O","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached program consistently segfaults (within a few seconds) when compiled with ghc-8.6.1 or ghc-8.6.2. It runs forever (as expected) when compiled with ghc-8.4.\r\n\r\nTo reproduce:\r\n\r\n{{{\r\nghc segfault.hs\r\n}}}\r\n\r\nthen,\r\n\r\n{{{\r\n./segfault >/dev/null\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15891Excessive system time during execution of GHC-built executables on macOS2019-07-07T18:02:33ZRichard Eisenbergrae@richarde.devExcessive system time during execution of GHC-built executables on macOSIt seems that the executables built by GHC on my configuration of macOS are slow, clocking in 80% of my machine's cycles in system time.
Here is what I know.
- Everything tested bootstrapping with both GHC 8.6.1 and GHC 8.6.2. There is...It seems that the executables built by GHC on my configuration of macOS are slow, clocking in 80% of my machine's cycles in system time.
Here is what I know.
- Everything tested bootstrapping with both GHC 8.6.1 and GHC 8.6.2. There is no observable difference between these bootstrapping compilers. The detailed data reported is all from GHC 8.6.1.
- When I try to build GHC, stage 1 builds snappily. But once stage-1 gets used, it slows to a crawl.
- Activity Monitor reports that my computer is spending roughly 80% of its time in the System space, not the User space. (While building ghc-stage1 itself, there is barely any system activity.)
- I have sampled ghc-stage1 during a rts_dist_HC call. Samples are at https://gist.github.com/goldfirere/7316920ad37d776c25c15dbb0ed5996f
- I then `dtruss`d the same, with output at https://gist.github.com/goldfirere/621ce9072e1204d30e96e7daecc80d02
- System information:
- macOS High Sierra, 10.13.6
- Processor: 3.5 GHz Intel Core i5
- Memory: 16 GB 2400 MHz DDR4
- SSD main storage, formatted with APFS
- happy 1.19.9
- alex 3.2.4
- XCode 10.1
- gcc is clang-1000.11.45.5, Apple LLVM version 10.0.0, thread model: posix
Others (see [thread](https://mail.haskell.org/pipermail/ghc-devs/2018-November/016507.html)) have not been able to repro, but this is very reliable for me.
Any ideas?
<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":"Excessive system time during execution of GHC-built executables on macOS","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It seems that the executables built by GHC on my configuration of macOS are slow, clocking in 80% of my machine's cycles in system time.\r\n\r\nHere is what I know.\r\n\r\n- Everything tested bootstrapping with both GHC 8.6.1 and GHC 8.6.2. There is no observable difference between these bootstrapping compilers. The detailed data reported is all from GHC 8.6.1.\r\n\r\n- When I try to build GHC, stage 1 builds snappily. But once stage-1 gets used, it slows to a crawl.\r\n\r\n- Activity Monitor reports that my computer is spending roughly 80% of its time in the System space, not the User space. (While building ghc-stage1 itself, there is barely any system activity.)\r\n\r\n- I have sampled ghc-stage1 during a rts_dist_HC call. Samples are at https://gist.github.com/goldfirere/7316920ad37d776c25c15dbb0ed5996f\r\n\r\n- I then `dtruss`d the same, with output at https://gist.github.com/goldfirere/621ce9072e1204d30e96e7daecc80d02\r\n\r\n- System information:\r\n * macOS High Sierra, 10.13.6\r\n * Processor: 3.5 GHz Intel Core i5\r\n * Memory: 16 GB 2400 MHz DDR4\r\n * SSD main storage, formatted with APFS\r\n * happy 1.19.9\r\n * alex 3.2.4\r\n * XCode 10.1\r\n * gcc is clang-1000.11.45.5, Apple LLVM version 10.0.0, thread model: posix\r\n\r\nOthers (see [https://mail.haskell.org/pipermail/ghc-devs/2018-November/016507.html thread]) have not been able to repro, but this is very reliable for me.\r\n\r\nAny ideas?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15890Provide a way for hadrian users to always pass some options to hadrian itself2021-05-11T10:01:57ZAlp MestanogullariProvide a way for hadrian users to always pass some options to hadrian itselfAnd more generally, is there any chance that we could make something like our builder `Args`/predicate logic work for specifying arguments to hadrian itself?
Regardless of the answer to that last question, it seems only natural to have ...And more generally, is there any chance that we could make something like our builder `Args`/predicate logic work for specifying arguments to hadrian itself?
Regardless of the answer to that last question, it seems only natural to have a simple/trivial solution for the case where we are always passing the same options to hadrian, over and over again, while working on GHC. "Yes, hadrian, I still want to build with the `perf` flavour, still with `integer-simple`, and you should still put all the build artifacts under `./ghc-prof-build/` while using all of my 4 cores", is something that I often told hadrian myself, while investigating a particular problem a few weeks ago, for example.
Ryan in particular has expressed interested in having a slightly cleaner solution than writing a tiny wrapper script that just does `hadrian/build.sh --flavour=perf -oghc-prof-build $@` or something along those lines. Especially given that our `Args` infrastructure seems perfect to specify that kind of thing. It does seem a little bit circular though, of course.
An alternative would be look at a build.mk-ish file, without support for any Make construct, just the good old key=value syntax + comments, and reconstruct a `Flavour` and everything else out of it. This way, instead of "implicitly" passing the same arguments on the CLI, we would "implicitly" look them up from some file, without having to create a wrapper script.
(This build.mk-ish file is something I discussed with hvr some time ago, which he would like so as to programmatically specify how he wants his GHCs. He can't reasonably programmatically edit the settings file.)
Thoughts?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 8.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | RyanGlScott, snowleopard |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Provide a way for hadrian users to always pass some options to hadrian itself","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["RyanGlScott","snowleopard"],"type":"FeatureRequest","description":"And more generally, is there any chance that we could make something like our builder `Args`/predicate logic work for specifying arguments to hadrian itself?\r\n\r\nRegardless of the answer to that last question, it seems only natural to have a simple/trivial solution for the case where we are always passing the same options to hadrian, over and over again, while working on GHC. \"Yes, hadrian, I still want to build with the `perf` flavour, still with `integer-simple`, and you should still put all the build artifacts under `./ghc-prof-build/` while using all of my 4 cores\", is something that I often told hadrian myself, while investigating a particular problem a few weeks ago, for example.\r\n\r\nRyan in particular has expressed interested in having a slightly cleaner solution than writing a tiny wrapper script that just does `hadrian/build.sh --flavour=perf -oghc-prof-build $@` or something along those lines. Especially given that our `Args` infrastructure seems perfect to specify that kind of thing. It does seem a little bit circular though, of course.\r\n\r\nAn alternative would be look at a build.mk-ish file, without support for any Make construct, just the good old key=value syntax + comments, and reconstruct a `Flavour` and everything else out of it. This way, instead of \"implicitly\" passing the same arguments on the CLI, we would \"implicitly\" look them up from some file, without having to create a wrapper script.\r\n\r\n(This build.mk-ish file is something I discussed with hvr some time ago, which he would like so as to programmatically specify how he wants his GHCs. He can't reasonably programmatically edit the settings file.)\r\n\r\nThoughts?","type_of_failure":"OtherFailure","blocking":[]} -->Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15889ghc documentation doesn't explain difference between dwarf levels 1 2 and 32019-07-07T18:02:34ZCarter Schonwaldghc documentation doesn't explain difference between dwarf levels 1 2 and 3I tried digging into current ghc source (well a 8.6.2 checkout) to track down where / how `debugLevel` crops up.
The docs/examples support g0 (off ) through g3. But when looking at where debugLevel appears in code, there isn't any diffe...I tried digging into current ghc source (well a 8.6.2 checkout) to track down where / how `debugLevel` crops up.
The docs/examples support g0 (off ) through g3. But when looking at where debugLevel appears in code, there isn't any different currently at the GHC layer for g3 vs g2! (is there a difference at the C compiler layer?)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc documentation doesn't explain difference between dwarf levels 1 2 and 3","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I tried digging into current ghc source (well a 8.6.2 checkout) to track down where / how `debugLevel` crops up.\r\n\r\nThe docs/examples support g0 (off ) through g3. But when looking at where debugLevel appears in code, there isn't any different currently at the GHC layer for g3 vs g2! (is there a difference at the C compiler layer?)","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15888Quantified constraints can be loopy2019-07-07T18:02:34ZRichard Eisenbergrae@richarde.devQuantified constraints can be loopyConsider this abuse:
```hs
{-# LANGUAGE QuantifiedConstraints, UndecidableInstances #-}
module Bug where
data T1 a
data T2 a
class C a where
meth :: a
instance (forall a. C (T2 a)) => C (T1 b) where
meth = error "instance T1"
i...Consider this abuse:
```hs
{-# LANGUAGE QuantifiedConstraints, UndecidableInstances #-}
module Bug where
data T1 a
data T2 a
class C a where
meth :: a
instance (forall a. C (T2 a)) => C (T1 b) where
meth = error "instance T1"
instance (forall a. C (T1 a)) => C (T2 b) where
meth = error "instance T2"
example :: T1 Int
example = meth
```
GHC says
```
• Reduction stack overflow; size = 201
When simplifying the following type: C (T1 a)
Use -freduction-depth=0 to disable this check
(any upper bound you could choose might fail unpredictably with
minor updates to GHC, so disabling the check is recommended if
you're sure that type checking should terminate)
• In the expression: meth
In an equation for ‘example’: example = meth
```
Of course, I've taken on some responsibility for my actions here by saying `UndecidableInstances`, but GHC really should be able to figure this out. Here's what's happening:
1. We get a Wanted `C (T1 Int)`.
1. GHC chooses the appropriate instance, emitting a Wanted `forall a. C (T2 a)`.
1. GHC skolemizes the `a` to `a1` and tries solve a Wanted `C (T2 a1)`.
1. GHC chooses the appropriate instance, emitting a Wanted `forall a. C (T1 a)`.
1. GHC skolemizes the `a` to `a2` and tries to solve a Wanted `C (T1 a2)`.
And around and around we go.
(This loop is guessed at from knowing GHC's algorithms in general. I did not look at a trace.)
We *could* get this one, though. Before skolemizing, we could stash the Wanted in the `inert_solved_dicts`, which is where we record uses of top-level instances. (See `Note [Solved dictionaries]` in TcSMonad.) Then, later, when we see the same Wanted arise again, we would just use the cached value, making a well-formed recursive dictionary.
This deficiency was discovered in `singletons` (https://github.com/goldfirere/singletons/issues/371). Perhaps that's not "the wild", but it's not quite contrived either.
Note that we don't need two datatypes to trigger this, but having one recursive instance like this seems awfully silly.
<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":"Quantified constraints can be loopy","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["QuantifiedConstraints"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider this abuse:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE QuantifiedConstraints, UndecidableInstances #-}\r\n\r\nmodule Bug where\r\n\r\ndata T1 a\r\ndata T2 a\r\n\r\nclass C a where\r\n meth :: a\r\n\r\ninstance (forall a. C (T2 a)) => C (T1 b) where\r\n meth = error \"instance T1\"\r\n\r\ninstance (forall a. C (T1 a)) => C (T2 b) where\r\n meth = error \"instance T2\"\r\n\r\nexample :: T1 Int\r\nexample = meth\r\n}}}\r\n\r\nGHC says\r\n\r\n{{{\r\n • Reduction stack overflow; size = 201\r\n When simplifying the following type: C (T1 a)\r\n Use -freduction-depth=0 to disable this check\r\n (any upper bound you could choose might fail unpredictably with\r\n minor updates to GHC, so disabling the check is recommended if\r\n you're sure that type checking should terminate)\r\n • In the expression: meth\r\n In an equation for ‘example’: example = meth\r\n}}}\r\n\r\nOf course, I've taken on some responsibility for my actions here by saying `UndecidableInstances`, but GHC really should be able to figure this out. Here's what's happening:\r\n\r\n1. We get a Wanted `C (T1 Int)`.\r\n\r\n2. GHC chooses the appropriate instance, emitting a Wanted `forall a. C (T2 a)`.\r\n\r\n3. GHC skolemizes the `a` to `a1` and tries solve a Wanted `C (T2 a1)`.\r\n\r\n4. GHC chooses the appropriate instance, emitting a Wanted `forall a. C (T1 a)`.\r\n\r\n5. GHC skolemizes the `a` to `a2` and tries to solve a Wanted `C (T1 a2)`.\r\n\r\nAnd around and around we go.\r\n\r\n(This loop is guessed at from knowing GHC's algorithms in general. I did not look at a trace.)\r\n\r\nWe ''could'' get this one, though. Before skolemizing, we could stash the Wanted in the `inert_solved_dicts`, which is where we record uses of top-level instances. (See `Note [Solved dictionaries]` in TcSMonad.) Then, later, when we see the same Wanted arise again, we would just use the cached value, making a well-formed recursive dictionary.\r\n\r\nThis deficiency was discovered in `singletons` (https://github.com/goldfirere/singletons/issues/371). Perhaps that's not \"the wild\", but it's not quite contrived either.\r\n\r\nNote that we don't need two datatypes to trigger this, but having one recursive instance like this seems awfully silly.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15887Ideas for a better GHCi editing experience2019-07-07T18:02:34ZAnchpopIdeas for a better GHCi editing experienceI have a two annoyances when writing Haskell code in GHCi which I will enumerate here. While minor, I think if these were fixed there would be a marked improvement of the GHCi editing experience.
1) Syntax/Keyword Highlighting.
> Hask...I have a two annoyances when writing Haskell code in GHCi which I will enumerate here. While minor, I think if these were fixed there would be a marked improvement of the GHCi editing experience.
1) Syntax/Keyword Highlighting.
> Haskell has some very common keywords. Simply writing `if`, `then`, `else`, `where`, `do`, etc. in some color other than the default when not inside a string literal would be a huge improvement in my opinion, and might not be very difficult.
2) Multiline editing
> Writing multiline expressions in Haskell is somewhat difficult for four reasons. Firstly, to even start a multiline expression you must enter `:{` end end it with `:}`. Secondly, GHCi does not attempt to automatically indent your code, which is usually (always?) required when writing a multiline expression. Thirdly, you cannot navigate the curor to previous lines to edit them. Lastly, pressing the up arrow on the keyboard shows the last line of the multiline expression which is useless because it's almost always `:}`.
> My proposal is as follows.
> 1) The issue of how to enter multiline mode without needing to enter `:{` and exit it without needing `:}`.
Instead of entering multiline mode only when the user enters `:{`, we add the following additional criteria. When I discuss haskell keywords in here, assume I mean "while not in a string literal".
a) When the input code contains an odd number of unescaped quotation marks and ends in a backslash.
b) When the input code ends with `where`, `let`, `in`, `if`, `then`, `else`, `do`, `of`, `case`, or `->` preceeded by and in the same level of parenthetical nesting of `case`.
c) When the input code contains a `let` that is not eventually followed by `in`, an `if` not followed by `then`, or a `then` not followed by `else`.
d) When the input code contains a `case` followed by `of`, not enclosed by parentheses.
e) When the input code contains a `[` that is not followed by a `]`, or an `(` that is not followed by a `)`.
f) When the input starts with two or more consecutive space-seperated tokens that do not contain haskell keywords (other than the backtick) followed by `=`.
g)
i) When the input contains a single token that is not a haskell keyword, followed by `::`, ending in `=>` or `->`.
ii) When the input contains a single token that is not a haskell keyword, followed by `::`, not ending in `=>` or `->`.
e) When the user hits `shift-return` instead of simply `return`, or hits `return` when there are non-whitespace characters after the cursor.
This should cover the majority of cases where it can be safely assumed one would want to enter multiline mode. Criterion f is intended to enter multiline mode when defining any function, to make it simple to define functions that use pattern matching. Criterion g is to make it simple to place a function signature right above a function definition.
In situations where multiline mode was not entered with `:{`, you should be able to exit it and submit your code to GHCi for execution by pressing `return` twice, or `meta-return`.
2) The issue of GHCi not attempting to indent your code.
How to indent depends on the reason GHCi entered multiline mode. If GHCi entered multiline mode because the user entered `:{`, no indentation should take place. If the user is in multiline mode but their code does not match criteria a-f, the default indentation should be the same as the indentation on the previous line. If the line is just whitespace and the user presses enter, indentation should be the same as the previous line. For criteria a-f, here is how to respond (I've ordered these from greatest to least precedence I think they should take, but I could be entirely wrong here).
a) Indent to the same column as the last unescaped quotation mark. For bonus points add a backslash too.
b) Indent to two columns as the token that caused the activation of multiline mode.
c) Indent to the same column as the token that caused the activation of multiline mode.
d) Indent to the character after the final `of` not contained in parentheses
e) Indent to the column of the next non-whitespace character after `(` or `[`, if one exists. Otherwise, indent one column farther than the `(`/`[`.
f) No indentation.
g)
i) Indent to the column of the first non-whitespace character after the `::`
ii) No indentation.
e) No indentation
If the user is not editing the last line, use the code up to the point of their cursor for advice on how to indent.
3) The issue of not being able to navigate the curor to previous lines in order to edit them when in multiline editing mode.
I think this would require a complete rewrite of the user interface for multiline editing, and I anticipate it would be the hardest part of this whole endevor. I don't have the knowledge to suggest how one might go about implementing it, though. If possible, pressing ctrl-c should cancel the current code and make a new `Prelude> ` prompt.
4) The issue of pressing `up` only displaying one line at a time.
See above.
I would be happy to try to implement some of these, but I have never contributed to GHC or GHCi before and would need some pointers on where to start (Either in here or in the \#ghc irc channel).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"It would be very nice to have a better GHCi editing experience","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"Research needed","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["QoL"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I have a two annoyances when writing Haskell code in GHCi which I will enumerate here. While minor, I think if these were fixed there would be a marked improvement of the GHCi editing experience.\r\n\r\n1) Syntax/Keyword Highlighting.\r\n\r\n Haskell has some very common keywords. Simply writing `if`, `then`, `else`, `where`, `do`, etc. in some color other than the default when not inside a string literal would be a huge improvement in my opinion, and might not be very difficult.\r\n\r\n2) Multiline editing\r\n\r\n Writing multiline expressions in Haskell is somewhat difficult for four reasons. Firstly, to even start a multiline expression you must enter `:{` end end it with `:}`. Secondly, GHCi does not attempt to automatically indent your code, which is usually (always?) required when writing a multiline expression. Thirdly, you cannot navigate the curor to previous lines to edit them. Lastly, pressing the up arrow on the keyboard shows the last line of the multiline expression which is useless because it's almost always `:}`. \r\n\r\n My proposal is as follows. \r\n\r\n 1) The issue of how to enter multiline mode without needing to enter `:{` and exit it without needing `:}`.\r\n\r\n\t Instead of entering multiline mode only when the user enters `:{`, we add the following additional criteria. When I discuss haskell keywords in here, assume I mean \"while not in a string literal\".\r\n\r\n\t a) When the input code contains an odd number of unescaped quotation marks and ends in a backslash.\r\n\r\n\t b) When the input code ends with `where`, `let`, `in`, `if`, `then`, `else`, `do`, `of`, `case`, or `->` preceeded by and in the same level of parenthetical nesting of `case`.\r\n\r\n\t c) When the input code contains a `let` that is not eventually followed by `in`, an `if` not followed by `then`, or a `then` not followed by `else`.\r\n\r\n\t d) When the input code contains a `case` followed by `of`, not enclosed by parentheses.\r\n\r\n\t e) When the input code contains a `[` that is not followed by a `]`, or an `(` that is not followed by a `)`.\r\n\r\n\t f) When the input starts with two or more consecutive space-seperated tokens that do not contain haskell keywords (other than the backtick) followed by `=`.\r\n\r\n\t g) \r\n\r\n\t \ti) When the input contains a single token that is not a haskell keyword, followed by `::`, ending in `=>` or `->`.\r\n\r\n\t \tii) When the input contains a single token that is not a haskell keyword, followed by `::`, not ending in `=>` or `->`.\r\n\r\n\t e) When the user hits `shift-return` instead of simply `return`, or hits `return` when there are non-whitespace characters after the cursor.\r\n\r\n\t This should cover the majority of cases where it can be safely assumed one would want to enter multiline mode. Criterion f is intended to enter multiline mode when defining any function, to make it simple to define functions that use pattern matching. Criterion g is to make it simple to place a function signature right above a function definition.\r\n\r\n\t In situations where multiline mode was not entered with `:{`, you should be able to exit it and submit your code to GHCi for execution by pressing `return` twice, or `meta-return`.\r\n\r\n\t2) The issue of GHCi not attempting to indent your code.\r\n\r\n\t\tHow to indent depends on the reason GHCi entered multiline mode. If GHCi entered multiline mode because the user entered `:{`, no indentation should take place. If the user is in multiline mode but their code does not match criteria a-f, the default indentation should be the same as the indentation on the previous line. If the line is just whitespace and the user presses enter, indentation should be the same as the previous line. For criteria a-f, here is how to respond (I've ordered these from greatest to least precedence I think they should take, but I could be entirely wrong here).\r\n\r\n\t\ta) Indent to the same column as the last unescaped quotation mark. For bonus points add a backslash too.\r\n\r\n\t\tb) Indent to two columns as the token that caused the activation of multiline mode.\r\n\r\n\t\tc) Indent to the same column as the token that caused the activation of multiline mode.\r\n\r\n\t\td) Indent to the character after the final `of` not contained in parentheses\r\n\r\n\t\te) Indent to the column of the next non-whitespace character after `(` or `[`, if one exists. Otherwise, indent one column farther than the `(`/`[`.\r\n\r\n\t\tf) No indentation.\r\n\r\n\t\tg)\r\n\r\n\t\t\ti) Indent to the column of the first non-whitespace character after the `::`\r\n\r\n\t\t\tii) No indentation.\r\n\r\n\t\te) No indentation\r\n\r\n\t\tIf the user is not editing the last line, use the code up to the point of their cursor for advice on how to indent.\r\n\r\n\t3) The issue of not being able to navigate the curor to previous lines in order to edit them when in multiline editing mode.\r\n\r\n\t I think this would require a complete rewrite of the user interface for multiline editing, and I anticipate it would be the hardest part of this whole endevor. I don't have the knowledge to suggest how one might go about implementing it, though. If possible, pressing ctrl-c should cancel the current code and make a new `Prelude> ` prompt.\r\n\r\n\t4) The issue of pressing `up` only displaying one line at a time.\r\n\r\n\t\tSee above.\r\n\r\nI would be happy to try to implement some of these, but I have never contributed to GHC or GHCi before and would need some pointers on where to start (Either in here or in the #ghc irc channel).","type_of_failure":"OtherFailure","blocking":[]} -->Research neededhttps://gitlab.haskell.org/ghc/ghc/-/issues/15886Spurious warning about incomplete pattern with PatternSynonyms2019-07-07T18:02:34ZselingerSpurious warning about incomplete pattern with PatternSynonyms```hs
{-# LANGUAGE ViewPatterns #-}
{-# LANGUAGE PatternSynonyms #-}
module Test where
f :: Int -> Bool
f (id -> a) = True
pattern X a <- (id -> a)
g :: Int -> Bool
g (X a) = True
```
When compiling with -Wincomplete-patterns, this ...```hs
{-# LANGUAGE ViewPatterns #-}
{-# LANGUAGE PatternSynonyms #-}
module Test where
f :: Int -> Bool
f (id -> a) = True
pattern X a <- (id -> a)
g :: Int -> Bool
g (X a) = True
```
When compiling with -Wincomplete-patterns, this code produces an (incorrect) warning for `g`, but not for `f`. The only difference is that `g` uses a pattern synonym.
```
K.hs:12:1: warning: [-Wincomplete-patterns]
Pattern match(es) are non-exhaustive
In an equation for ‘g’: Patterns not matched: _
|
12 | g (X a) = True
| ^^^^^^^^^^^^^^
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Spurious warning about incomplete pattern with PatternSynonyms","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE ViewPatterns #-}\r\n{-# LANGUAGE PatternSynonyms #-}\r\n\r\nmodule Test where\r\n\r\nf :: Int -> Bool\r\nf (id -> a) = True\r\n\r\npattern X a <- (id -> a)\r\n\r\ng :: Int -> Bool\r\ng (X a) = True\r\n}}}\r\n\r\nWhen compiling with -Wincomplete-patterns, this code produces an (incorrect) warning for `g`, but not for `f`. The only difference is that `g` uses a pattern synonym.\r\n\r\n{{{\r\nK.hs:12:1: warning: [-Wincomplete-patterns]\r\n Pattern match(es) are non-exhaustive\r\n In an equation for ‘g’: Patterns not matched: _\r\n |\r\n12 | g (X a) = True\r\n | ^^^^^^^^^^^^^^\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15885Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (outpu...2021-02-22T21:15:08ZShayan-NajdEnhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) typesOn our work on the [new front-end AST for GHC](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow) based on [TTG](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance), we would like to use [...On our work on the [new front-end AST for GHC](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow) based on [TTG](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance), we would like to use [a pattern synonym](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSourceLocations) similar to the following:
```hs
pattern LL :: HasSrcSpan a => SrcSpan -> SrcSpanLess a -> a
pattern LL s m <- (decomposeSrcSpan -> (m , s))
where
LL s m = composeSrcSpan (m , s)
```
We know that any match on `LL` patterns, makes the pattern matching total, as it uses a view pattern with a total output pattern (i.e., in `decomposeSrcSpan -> (m , s)`, the pattern `(m , s)` is total).
As far as I understand, currently COMPLETE pragmas cannot be used with such a polymorphic pattern synonym.
I believe we need to enhance COMPLETE pragmas to support such pattern synonyms.
This can be done either syntactically, or (preferably) type-directed.
For example, we should be able to write `{-# COMPLETE LL #-}` or `{-# COMPLETE LL :: HasSrcSpan a => a #-}`.
In the type-directed approach
a. the totality checker \*may\* need to track, at least, the set of required constraints of pattern synonyms mentioned in a COMPLETE pragma; and
b. the order of pattern synonyms mentioned in a pragma should be taken into account (as noted by \@carter).
For example, in the case of `LL`, `HasSrcSpan a` is a required type constraint.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| 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":"Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"On our work on the [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow new front-end AST for GHC] based on [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance TTG], we would like to use [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSourceLocations a pattern synonym] similar to the following:\r\n\r\n{{{#!hs\r\npattern LL :: HasSrcSpan a => SrcSpan -> SrcSpanLess a -> a\r\npattern LL s m <- (decomposeSrcSpan -> (m , s))\r\n where\r\n LL s m = composeSrcSpan (m , s)\r\n}}}\r\n\r\nWe know that any match on `LL` patterns, makes the pattern matching total, as it uses a view pattern with a total output pattern (i.e., in `decomposeSrcSpan -> (m , s)`, the pattern `(m , s)` is total).\r\n\r\nAs far as I understand, currently COMPLETE pragmas cannot be used with such a polymorphic pattern synonym.\r\nI believe we need to enhance COMPLETE pragmas to support such pattern synonyms.\r\n\r\nThis can be done either syntactically, or (preferably) type-directed.\r\n\r\nFor example, we should be able to write `{-# COMPLETE LL #-}` or `{-# COMPLETE LL :: HasSrcSpan a => a #-}`.\r\n\r\nIn the type-directed approach\r\na. the totality checker *may* need to track, at least, the set of required constraints of pattern synonyms mentioned in a COMPLETE pragma; and\r\nb. the order of pattern synonyms mentioned in a pragma should be taken into account (as noted by @carter).\r\n\r\nFor example, in the case of `LL`, `HasSrcSpan a` is a required type constraint.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15884Completeness of View Patterns With a Complete Set of Output Patterns2023-07-31T10:31:25ZShayan-NajdCompleteness of View Patterns With a Complete Set of Output PatternsFor example, the code
```hs
{-# OPTIONS_GHC -Wall #-}
{-# LANGUAGE ViewPatterns #-}
f :: Maybe a -> Bool
f (id->Nothing) = False
f (id->(Just _)) = True
```
mistakenly returns the warning
```
warning: [-Wincomplete-patterns]
Patt...For example, the code
```hs
{-# OPTIONS_GHC -Wall #-}
{-# LANGUAGE ViewPatterns #-}
f :: Maybe a -> Bool
f (id->Nothing) = False
f (id->(Just _)) = True
```
mistakenly returns the warning
```
warning: [-Wincomplete-patterns]
Pattern match(es) are non-exhaustive
In an equation for ‘f’: Patterns not matched: _
|
4 | f (id->Nothing) = False
| ^^^^^^^^^^^^^^^^^^^^^^^^...
```
<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 | alanz, bgamari |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Completeness of View Patterns With a Complete Set of Output Patterns","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["alanz","bgamari"],"type":"Bug","description":"For example, the code\r\n\r\n{{{#!hs\r\n{-# OPTIONS_GHC -Wall #-}\r\n{-# LANGUAGE ViewPatterns #-}\r\nf :: Maybe a -> Bool\r\nf (id->Nothing) = False\r\nf (id->(Just _)) = True\r\n}}}\r\n\r\nmistakenly returns the warning\r\n\r\n{{{\r\nwarning: [-Wincomplete-patterns]\r\n Pattern match(es) are non-exhaustive\r\n In an equation for ‘f’: Patterns not matched: _\r\n |\r\n4 | f (id->Nothing) = False\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^...\r\n}}}\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15883GHC panic: newtype F rep = F (forall (a :: TYPE rep). a)2020-01-17T16:43:24ZIcelandjackGHC panic: newtype F rep = F (forall (a :: TYPE rep). a)```hs
{-# Language RankNTypes #-}
{-# Language KindSignatures #-}
{-# Language PolyKinds #-}
import GHC.Exts
newtype Foo rep = MkFoo (forall (a :: TYPE rep). a)
```
```
$ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interact...```hs
{-# Language RankNTypes #-}
{-# Language KindSignatures #-}
{-# Language PolyKinds #-}
import GHC.Exts
newtype Foo rep = MkFoo (forall (a :: TYPE rep). a)
```
```
$ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci /tmp/U.hs
GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( /tmp/U.hs, interpreted )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.7.20181029 for x86_64-unknown-linux):
isUnliftedType
forall (a :: TYPE rep_a1AA[sk:0]). a :: TYPE rep_a1AA[sk:0]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:2332:10 in ghc:Type
isUnliftedType, called at compiler/typecheck/TcTyClsDecls.hs:3055:25 in ghc:TcTyClsDecls
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```
<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":"GHC panic: newtype F rep = F (forall (a :: TYPE rep). a)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# Language RankNTypes #-}\r\n{-# Language KindSignatures #-}\r\n{-# Language PolyKinds #-}\r\n\r\nimport GHC.Exts\r\n\r\nnewtype Foo rep = MkFoo (forall (a :: TYPE rep). a)\r\n}}}\r\n\r\n{{{\r\n$ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci /tmp/U.hs\r\nGHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( /tmp/U.hs, interpreted )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.7.20181029 for x86_64-unknown-linux):\r\n isUnliftedType\r\n forall (a :: TYPE rep_a1AA[sk:0]). a :: TYPE rep_a1AA[sk:0]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Type.hs:2332:10 in ghc:Type\r\n isUnliftedType, called at compiler/typecheck/TcTyClsDecls.hs:3055:25 in ghc:TcTyClsDecls\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/15882:load in ghci should expose the entire namespace of a module2019-07-07T18:02:35ZEyalLotem:load in ghci should expose the entire namespace of a moduleWhen using "import" in ghci, only exported names are available.
When using :load, the use case is typically for "toying around" or testing a module. In that case, the export list restrictions are much less useful.
There is currently no ...When using "import" in ghci, only exported names are available.
When using :load, the use case is typically for "toying around" or testing a module. In that case, the export list restrictions are much less useful.
There is currently no way to just expose the same namespace context of the code in a module in ghci, and having :load do that sounds like it would be very useful. The ordinary "import" namespace semantics are after all available too.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":":load in ghci should expose the entire namespace of a module","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"When using \"import\" in ghci, only exported names are available.\r\n\r\nWhen using :load, the use case is typically for \"toying around\" or testing a module. In that case, the export list restrictions are much less useful.\r\n \r\nThere is currently no way to just expose the same namespace context of the code in a module in ghci, and having :load do that sounds like it would be very useful. The ordinary \"import\" namespace semantics are after all available too.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15881GHC Panic: data A n (a :: n) :: a -> Type2019-07-07T18:02:35ZIcelandjackGHC Panic: data A n (a :: n) :: a -> Type```hs
{-# Language KindSignatures #-}
{-# Language PolyKinds #-}
import Data.Kind
data A n (a :: n) :: a -> Type
```
causes a panic on 8.7.20181017
```
$ ~/code/headghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 665_b...```hs
{-# Language KindSignatures #-}
{-# Language PolyKinds #-}
import Data.Kind
data A n (a :: n) :: a -> Type
```
causes a panic on 8.7.20181017
```
$ ~/code/headghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 665_bug.hs
GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( 665_bug.hs, interpreted )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.7.20181017 for x86_64-unknown-linux):
ASSERT failed!
Type-correct unfilled coercion hole {co_a1xR}
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable
assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```
and an assertion failure in 8.7.20181029
```
$ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 665_bug.hs
GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( 665_bug.hs, interpreted )
*** Exception: ASSERT failed! file compiler/types/TyCon.hs, line 420
>
```
<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":"GHC Panic: data A n (a :: n) :: a -> Type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# Language KindSignatures #-}\r\n{-# Language PolyKinds #-}\r\n\r\nimport Data.Kind\r\n\r\ndata A n (a :: n) :: a -> Type\r\n}}}\r\n\r\ncauses a panic on 8.7.20181017\r\n\r\n{{{\r\n$ ~/code/headghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 665_bug.hs\r\nGHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( 665_bug.hs, interpreted )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.7.20181017 for x86_64-unknown-linux):\r\n\tASSERT failed!\r\n Type-correct unfilled coercion hole {co_a1xR}\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable\r\n pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable\r\n assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n>\r\n}}}\r\n\r\nand an assertion failure in 8.7.20181029\r\n{{{\r\n$ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 665_bug.hs\r\nGHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( 665_bug.hs, interpreted )\r\n*** Exception: ASSERT failed! file compiler/types/TyCon.hs, line 420\r\n>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15880GHC.Stats: Add info on amount of pinned memory2019-08-03T11:16:56ZNiklas Hambüchenmail@nh2.meGHC.Stats: Add info on amount of pinned memoryhttps://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Stats.html
`GHC.Stats`'s `GCDetails` tells us, separately, the amount of
- total heap data (including large objects and compact data)
- large ojects
- compact data
- "Total amo...https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Stats.html
`GHC.Stats`'s `GCDetails` tells us, separately, the amount of
- total heap data (including large objects and compact data)
- large ojects
- compact data
- "Total amount of memory in use by the RTS" (`gcdetails_mem_in_use_bytes`)
There currently doesn't seem to be a way to get the amount of pinned memory in use.
So some questions:
- Is pinned memory accounted for in `gcdetails_mem_in_use_bytes`?
- If yes, is it pretty much that value minus `gcdetails_live_bytes`, or are there other memory uses that count to the latter?
- If I wanted to add the amount of pinned memory directly to `GHC.Stats`, where would I take that value from?
In general, my goal is to collect _all_ easily (cheaply) collectable memory info so that I can add it to `ekg`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.Stats: Add info on amount of pinned memory","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2"],"type":"Task","description":"https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Stats.html\r\n\r\n`GHC.Stats`'s `GCDetails` tells us, separately, the amount of \r\n\r\n* total heap data (including large objects and compact data)\r\n* large ojects\r\n* compact data\r\n* \"Total amount of memory in use by the RTS\" (`gcdetails_mem_in_use_bytes`)\r\n\r\nThere currently doesn't seem to be a way to get the amount of pinned memory in use.\r\n\r\nSo some questions:\r\n\r\n* Is pinned memory accounted for in `gcdetails_mem_in_use_bytes`?\r\n* If yes, is it pretty much that value minus `gcdetails_live_bytes`, or are there other memory uses that count to the latter?\r\n* If I wanted to add the amount of pinned memory directly to `GHC.Stats`, where would I take that value from?\r\n\r\nIn general, my goal is to collect _all_ easily (cheaply) collectable memory info so that I can add it to `ekg`.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15879Make UniqDSet a newtype2019-07-07T18:02:36ZSebastian GrafMake UniqDSet a newtypeFor the same reasons as in #13114 and [D3146](https://phabricator.haskell.org/D3146) we should make `UniqDSet` a newtype of `UniqDFM`.
I wonder if we can also have a prettier `Outputable` instance this way.
<details><summary>Trac metad...For the same reasons as in #13114 and [D3146](https://phabricator.haskell.org/D3146) we should make `UniqDSet` a newtype of `UniqDFM`.
I wonder if we can also have a prettier `Outputable` instance this way.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| 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":"Make UniqDSet a newtype","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"For the same reasons as in #13114 and Phab:D3146 we should make `UniqDSet` a newtype of `UniqDFM`.\r\n\r\nI wonder if we can also have a prettier `Outputable` instance this way.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15878Unused data type with a "deriving" clause is falsely considered used2021-06-17T16:32:40ZEyalLotemUnused data type with a "deriving" clause is falsely considered usedmodule M () where data Foo = Bar deriving (Eq)
If there are no explicit references to Foo and none to Bar, the data-type is necessarily unused, so I expect a warning about an unused data-type.
Even if it is referenced, but only from in...module M () where data Foo = Bar deriving (Eq)
If there are no explicit references to Foo and none to Bar, the data-type is necessarily unused, so I expect a warning about an unused data-type.
Even if it is referenced, but only from instance declarations, it is necessarily unused in the program.
One potential exception is functional dependencies, where the instance declaration itself has an effect. But even then, perhaps it is worth warning that the \*type\* is unused.
<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":"Unused data type with a \"deriving\" clause is falsely considered used","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"module M () where data Foo = Bar deriving (Eq)\r\n\r\nIf there are no explicit references to Foo and none to Bar, the data-type is necessarily unused, so I expect a warning about an unused data-type.\r\n\r\nEven if it is referenced, but only from instance declarations, it is necessarily unused in the program.\r\n\r\nOne potential exception is functional dependencies, where the instance declaration itself has an effect. But even then, perhaps it is worth warning that the *type* is unused.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15877--flavour=quick followed by --flavour=prof fails2020-03-13T16:31:15ZMatthew Pickering--flavour=quick followed by --flavour=prof failsStarting from a clean tree I first built successfully with `--flavour=quick`, I then changed to `--flavour=prof` and the build failed as follows:
```
/root/ghc/_build/stage1/rts/build/libCffi_p.a: copyFile: does not exist (No such file ...Starting from a clean tree I first built successfully with `--flavour=quick`, I then changed to `--flavour=prof` and the build failed as follows:
```
/root/ghc/_build/stage1/rts/build/libCffi_p.a: copyFile: does not exist (No such file or directory)
shakeArgsWith 0.010s 0%
Function shake 0.435s 0%
Database read 0.670s 0%
With database 0.035s 0%
Running rules 123.401s 99% =========================
Total 124.551s 100%
Error when running Shake build system:
at src/Rules.hs:(32,19)-(45,17):
at src/Rules.hs:45:5-17:
* Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf
* Raised the exception:
ExitFailure 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| 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":"--flavour=quick followed by --flavour=prof fails","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Starting from a clean tree I first built successfully with `--flavour=quick`, I then changed to `--flavour=prof` and the build failed as follows:\r\n\r\n{{{\r\n/root/ghc/_build/stage1/rts/build/libCffi_p.a: copyFile: does not exist (No such file or directory)\r\nshakeArgsWith 0.010s 0% \r\nFunction shake 0.435s 0% \r\nDatabase read 0.670s 0% \r\nWith database 0.035s 0% \r\nRunning rules 123.401s 99% =========================\r\nTotal 124.551s 100% \r\nError when running Shake build system:\r\n at src/Rules.hs:(32,19)-(45,17):\r\n at src/Rules.hs:45:5-17:\r\n* Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf\r\n* Raised the exception:\r\nExitFailure 1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Make removalhttps://gitlab.haskell.org/ghc/ghc/-/issues/15876Function versioning instead of compilation flags...2019-07-07T18:02:36ZMichalGajdaFunction versioning instead of compilation flags...Wanting to take advantage of SIMD, we need to compile a different implementation of certain core libraries functions (like `ByteString` c_memchr to make it 16x faster).
This would require recompiling most of the libraries for new flags....Wanting to take advantage of SIMD, we need to compile a different implementation of certain core libraries functions (like `ByteString` c_memchr to make it 16x faster).
This would require recompiling most of the libraries for new flags.
Instead, it would be much simpler to add function versioning a la GCC: https://lwn.net/Articles/691932/
This would allow us to write code like this:
{-\# target(avx512) \#-}
c_memchr = ...SIMD code...
{-\# !target(avx512) \#-}
c_memchr = ...current code...
We currently use special libraries for these kind of speedups, but it would be much better to use SIMD across few key functions in all libraries to get 16x speedups across the board (`c_memchr` for parsing.)
Ideally we could also use it to remove some of _flavoring_ in the future.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Linking) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | abhir00p, marlowsd@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Function versioning instead of compilation flags...","status":"New","operating_system":"","component":"Compiler (Linking)","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":["flavors,","simd,","speed"],"differentials":[],"test_case":"","architecture":"","cc":["abhir00p","marlowsd@gmail.com"],"type":"FeatureRequest","description":"Wanting to take advantage of SIMD, we need to compile a different implementation of certain core libraries functions (like `ByteString` c_memchr to make it 16x faster).\r\n\r\nThis would require recompiling most of the libraries for new flags.\r\n\r\nInstead, it would be much simpler to add function versioning a la GCC: https://lwn.net/Articles/691932/\r\n\r\nThis would allow us to write code like this:\r\n{-# target(avx512) #-}\r\nc_memchr = ...SIMD code...\r\n{-# !target(avx512) #-}\r\nc_memchr = ...current code...\r\n\r\nWe currently use special libraries for these kind of speedups, but it would be much better to use SIMD across few key functions in all libraries to get 16x speedups across the board (`c_memchr` for parsing.)\r\n\r\nIdeally we could also use it to remove some of _flavoring_ in the future.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15875Detection of ranlib by binary distribution is broken2019-07-07T18:02:37ZBen GamariDetection of ranlib by binary distribution is brokenThe `configure` shipped with binary distributions fails to set `RanlibCmd` which therefore means that we end up installing `settings` with an empty `ranlib command` configuration field.
<details><summary>Trac metadata</summary>
| Trac ...The `configure` shipped with binary distributions fails to set `RanlibCmd` which therefore means that we end up installing `settings` with an empty `ranlib command` configuration field.
<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":"Detection of ranlib by binary distribution is broken","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `configure` shipped with binary distributions fails to set `RanlibCmd` which therefore means that we end up installing `settings` with an empty `ranlib command` configuration field.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15874Data families with higher-rank kinds2019-07-07T18:02:37ZIcelandjackData families with higher-rank kinds```hs
{-# Language RankNTypes #-}
{-# Language DataKinds #-}
{-# Language PolyKinds #-}
{-# Language GADTs #-}
{-# Language TypeFamilies #-}
import Data.Kind
data Var where
Op :: Var
Id :: Var
-- type family
-- Fl...```hs
{-# Language RankNTypes #-}
{-# Language DataKinds #-}
{-# Language PolyKinds #-}
{-# Language GADTs #-}
{-# Language TypeFamilies #-}
import Data.Kind
data Var where
Op :: Var
Id :: Var
-- type family
-- Flip (var :: Var) = (res :: Var) | res -> var where
-- Flip Op = Id
-- Flip Id = Op
type Varianced = (forall (var :: Var). Type)
-- data A :: Varianced where
-- MkA :: Int -> A @Id
-- data OpA :: Varianced where
-- MkOpA :: Int -> OpA @Op
-- data Exp :: Varianced -> Varianced where
-- X :: forall (ext::Varianced) (var :: Var). Exp ext @var
-- OpExp1 :: forall (var :: Varianced). var @op -> Exp var @(Flip op)
data family Parser :: Varianced
data instance Parser = P
```
```
$ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 656.hs
GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( 656.hs, interpreted )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.7.20181029 for x86_64-unknown-linux):
ASSERT failed!
kind axiom D:R:Parservar0 ::
Parser = R:Parservar -- Defined at 656.hs:31:15
forall (var :: Var). *
Var -> *
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable
assertPprPanic, called at compiler/typecheck/FamInst.hs:158:61 in ghc:FamInst
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```
<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":"Data families with higher-rank kinds","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":"{{{#!hs\r\n{-# Language RankNTypes #-}\r\n{-# Language DataKinds #-}\r\n{-# Language PolyKinds #-}\r\n{-# Language GADTs #-}\r\n{-# Language TypeFamilies #-}\r\n\r\nimport Data.Kind\r\n\r\ndata Var where\r\n Op :: Var\r\n Id :: Var\r\n\r\n-- type family\r\n-- Flip (var :: Var) = (res :: Var) | res -> var where\r\n-- Flip Op = Id\r\n-- Flip Id = Op\r\n\r\ntype Varianced = (forall (var :: Var). Type)\r\n\r\n-- data A :: Varianced where\r\n-- MkA :: Int -> A @Id\r\n\r\n-- data OpA :: Varianced where\r\n-- MkOpA :: Int -> OpA @Op\r\n\r\n-- data Exp :: Varianced -> Varianced where\r\n-- X :: forall (ext::Varianced) (var :: Var). Exp ext @var\r\n -- OpExp1 :: forall (var :: Varianced). var @op -> Exp var @(Flip op)\r\n\r\ndata family Parser :: Varianced\r\ndata instance Parser = P\r\n}}}\r\n\r\n{{{\r\n$ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 656.hs\r\nGHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( 656.hs, interpreted )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.7.20181029 for x86_64-unknown-linux):\r\n ASSERT failed!\r\n kind axiom D:R:Parservar0 ::\r\n Parser = R:Parservar -- Defined at 656.hs:31:15\r\n forall (var :: Var). *\r\n Var -> *\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable\r\n pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable\r\n assertPprPanic, called at compiler/typecheck/FamInst.hs:158:61 in ghc:FamInst\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15873move to llvm 7 for 8.8.12019-07-07T18:02:37Zgeorge.colpittsmove to llvm 7 for 8.8.1<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure |...<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"move to llvm 7 for 8.8.1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1