GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-10-04T13:51:38Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/20335GHCi discards plugins on reload2021-10-04T13:51:38ZAaron AllenGHCi discards plugins on reload## Summary
When trying to use plugins in an interactive context, the plugins are unloaded whenever GHCi reloads. This bug appears to have been introduced in 9.2.
Loaded plugins used to live in the `DynFlags` but were moved to the `Inte...## Summary
When trying to use plugins in an interactive context, the plugins are unloaded whenever GHCi reloads. This bug appears to have been introduced in 9.2.
Loaded plugins used to live in the `DynFlags` but were moved to the `InteractiveContext` for GHCi, which gets cleared by `discardIC` during the loading process. I found that simply not emptying out the `ic_plugins` field in `discardIC` fixes the issue.
## Steps to reproduce
- Load a plugin in a GHCi session: `:set -fplugin=SomePlugin`
- Use the `:reload` command
- The plugin is no longer in the context
## Expected behavior
Plugins should persist across reloads.
## Environment
* GHC version used: 9.2.0.202108219.2.1Sylvain HenrySylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/20101GHCi 9.2.0.20210422 erases left hand side of interactive declaration when tab...2021-08-13T16:44:39ZAnselm Schülermail@anselmschueler.comGHCi 9.2.0.20210422 erases left hand side of interactive declaration when tab completion is requested## Summary
When pressing <kbd>⭾</kbd> while in an interactive prompt, all entered text left of the last equals sign (`=`) is removed.
## Steps to reproduce
1. Open GHCi (`ghci` or `ghc --interactive`)
2. Type some text containing an e...## Summary
When pressing <kbd>⭾</kbd> while in an interactive prompt, all entered text left of the last equals sign (`=`) is removed.
## Steps to reproduce
1. Open GHCi (`ghci` or `ghc --interactive`)
2. Type some text containing an equals sign (`=`) such as `let x = 2 +`
3. Press the “tab” key (<kbd>⭾</kbd>)
## Expected behavior
GHCi will attempt to autocomplete the word left of the cursor.
## Actual behavior
GHCi performs the expected behavior but also erases all text left of or at the rightmost equals sign (`=`).
## Demonstration
View this behavior in action in this terminal recording:
[https://asciinema.org/a/424970](https://asciinema.org/a/424970)
## Environment
* GHC version used: 9.2.0.20210422
Optional:
* Operating System: Pop!_OS 21.04 on Linux 5.11.0-7620-generic
* System Architecture: x86 649.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/20060Pattern match failure from GHC when compiling module with -O2 that uses mapM ...2021-08-04T20:32:05ZTeo CamarasuPattern match failure from GHC when compiling module with -O2 that uses mapM in TH## Summary
The following module causes GHC HEAD and 9.2 to crash with a pattern match failure.
It looks like this is triggered from some code turning core into stg in the driver.
Interestingly, replacing `mapM` with `traverse` causes it...## Summary
The following module causes GHC HEAD and 9.2 to crash with a pattern match failure.
It looks like this is triggered from some code turning core into stg in the driver.
Interestingly, replacing `mapM` with `traverse` causes it to disappear.
It doesn't happen if we don't compile the module with `-O2`.
## Steps to reproduce
Try to compile the following module:
```
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -O2 #-}
module THBug where
data A
data B
concat <$> mapM (\_ -> (pure []))
[ ''A
, ''B
]
```
ghc produces the following output:
```
[1 of 1] Compiling THBug ( THBug.hs, THBug.o, THBug.dyn_o )
user error (Pattern match failure in 'do' block at compiler/GHC/Driver/Main.hs:1823:5-68)
```
## Expected behaviour
This module should probably compile without an error
## Environment
* GHC version used:
```
The Glorious Glasgow Haskell Compilation System, version 9.3.20210628
```
Optional:
* Operating System: Linux under WSL2
* System Architecture: x86_649.2.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/19688:info no longer shows instances of poly-kinded data families in GHC 9.2+2021-07-28T16:24:29ZRyan Scott:info no longer shows instances of poly-kinded data families in GHC 9.2+If you load this program into GHCi:
```hs
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
data family D (a :: k)
data instance D Int = DInt
```
In GHCi 9.0.1, running `:info D` will show the data family insta...If you load this program into GHCi:
```hs
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
data family D (a :: k)
data instance D Int = DInt
```
In GHCi 9.0.1, running `:info D` will show the data family instance:
```
$ /opt/ghc/9.0.1/bin/ghci Bug.hs
GHCi, version 9.0.1: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/ryanglscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
λ> :info D
type D :: forall k. k -> *
data family D a
-- Defined at Bug.hs:5:1
data instance D Int = DInt -- Defined at Bug.hs:6:15
```
In GHCi 9.2.1-alpha1, however, this no longer happens:
```
$ ~/Software/ghc-9.2.1-alpha1/bin/ghci Bug.hs
GHCi, version 9.2.0.20210331: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/ryanglscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
λ> :info D
type D :: forall k. k -> *
data family D a
-- Defined at Bug.hs:5:1
```
~~This regression was introduced in commit aaa5fc21af8dda26bf6c497d1036833225c94fa1 (`Replace Ord TyLit with nonDetCmpTyLit (#19441)`). cc @int-index~~ Actually, it was introduced in 3e082f8ff5ea2f42c5e6430094683b26b5818fb8 (`Implement BoxedRep proposal`).9.2.1Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/19591GHCi unboxed tuples register saving incompatible with LLVM2021-07-05T16:14:28ZLuite StegemanGHCi unboxed tuples register saving incompatible with LLVMUnfortunately this wasn't picked up by CI. The `stg_ctoi_t` and `stg_ret_t` closures save and restore a tuple from registers, respectively. They use a `tuple_info` word that describes which registers are live. Overlapping registers are n...Unfortunately this wasn't picked up by CI. The `stg_ctoi_t` and `stg_ret_t` closures save and restore a tuple from registers, respectively. They use a `tuple_info` word that describes which registers are live. Overlapping registers are never live at the same time, but the LLVM code generator doesn't know this, resulting in errors like this:
```
ghc-stage1: sorry! (unimplemented feature or known bug)
(GHC version 9.1.20210325:
LLVM code generator
Found two different Cmm registers (F1,D1) both alive AND mapped to the same real register: %r17. This isn't currently supported by the LLVM backend.
```
We probably need to change the Cmm register saving strategy a little bit.9.2.1Luite StegemanLuite Stegemanhttps://gitlab.haskell.org/ghc/ghc/-/issues/19543GHCi panics with small (e.g. `Word8#`, `Int16#`) literals2021-05-17T06:57:42ZLuite StegemanGHCi panics with small (e.g. `Word8#`, `Int16#`) literals## Summary
GHCi panics when it generates bytecode to return literals that are smaller than a machine word.
## Steps to reproduce
Run the `tests/parser/should_run/BinaryLiterals2.hs` test from the testsuite with GHCi.
```
$ ghc -e mai...## Summary
GHCi panics when it generates bytecode to return literals that are smaller than a machine word.
## Steps to reproduce
Run the `tests/parser/should_run/BinaryLiterals2.hs` test from the testsuite with GHCi.
```
$ ghc -e main tests/parser/should_run/BinaryLiterals2.hs
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 9.1.20210311:
GHC.StgToByteCode.bytesToWords: bytes=1
```
## Expected behavior
The testcase should give the same result as when compiled, i.e. the contents of `BinaryLiterals2.stdout`
## Environment
Recent GHC (9.1 / 9.2) branch. It looks like this was introduced by the sized Cmm improvements.9.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/19279Over-instantiation with :kind!2021-02-06T15:14:03ZAdam GundryOver-instantiation with :kind!## Summary
In HEAD, the `:kind!` command prints an incorrect kind when used with a type synonym. It appears to saturate it, rather than displaying the kind of the partially applied type synonym, so it is inconsistent with `:kind` and wi...## Summary
In HEAD, the `:kind!` command prints an incorrect kind when used with a type synonym. It appears to saturate it, rather than displaying the kind of the partially applied type synonym, so it is inconsistent with `:kind` and with previous releases.
I'm guessing this might be related to !4384? I don't think this was changed deliberately though?
## Steps to reproduce
```
GHCi, version 9.1.20201222: https://www.haskell.org/ghc/ :? for help
ghci> type T a = a
ghci> :kind! T
T :: *
= a
ghci> :kind T
T :: * -> *
```
Note that `:kind! T` says `T :: *`, which is nonsense. It could perhaps say either
```
T a :: *
= a
```
or
```
T :: * -> *
T a = a
```
either of which would make more sense.
## Expected behavior
For comparison, here is 8.10.2:
```
GHCi, version 8.10.2: https://www.haskell.org/ghc/ :? for help
Prelude> type T a = a
Prelude> :kind! T
T :: * -> *
= T
Prelude> :kind T
T :: * -> *
```
## Environment
* GHC version used: HEAD (to be specific, 18479dbdeae6127866d99053f0aed938a91a8555)9.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/18828:kind! fails to expand type synonyms2020-11-09T14:05:55ZIcelandjack:kind! fails to expand type synonymsLet me know if this is expected behaviour, I want to return the object type of a category `Cat ob` which is what I use as a shorthand for `ob -> ob -> Type`.
I want to be able to write `Object (->)` and get out `Type`, when written as a...Let me know if this is expected behaviour, I want to return the object type of a category `Cat ob` which is what I use as a shorthand for `ob -> ob -> Type`.
I want to be able to write `Object (->)` and get out `Type`, when written as a type synonym the call to `Object (->)` gets stuck:
```haskell
{-# Language ConstraintKinds #-}
{-# Language DataKinds #-}
{-# Language GADTs #-}
{-# Language PolyKinds #-}
{-# Language RankNTypes #-}
{-# Language StandaloneKindSignatures #-}
{-# Language TypeFamilies #-}
{-# Language TypeOperators #-}
import Data.Kind
type Cat :: Type -> Type
type Cat ob = ob -> ob -> Type
type Dict :: Constraint -> Type
data Dict cls where
Dict :: cls => Dict cls
type (:-) :: Cat Constraint
newtype cls1 :- cls2 where
Sub :: (cls1 => Dict cls2) -> (cls1 :- cls2)
-- > :k! Object ((->) :: Cat Type)
-- = Object (->)
--
-- > import Data.Type.Equality
-- > :k! Object (:~:)
-- = Object (:~:)
--
-- > :k! Object Op
-- = Object Op
--
-- > :k! Object (:-)
-- = Object (:-)
type Object :: Cat ob -> Type
type Object (cat :: ob -> ob -> Type) = ob
```
It works with a type family, what is the difference here?
```haskell
-- > :k! Object (->)
-- = *
--
-- > :k! forall ob. Object ((:~:) :: Cat ob)
-- = ob
--
-- > :k! Object Op
-- = *
--
-- > :k! Object (:-)
-- = Constraint
type
Object :: Cat ob -> Type
type family
Object cat where
Object @ob cat = ob
```
Tested with GHC 9.0.0.20200925.9.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/15646ghci takes super long time to find the type of large fractional number2023-03-23T19:15:49ZJohannkokosghci takes super long time to find the type of large fractional number```
:t 1e123456789
```
takes more than 3 seconds to get the type info.
```
:t 1e1234111111111111111111111
```
shows a warning/error,
```
GNU MP: Cannot allocate memory (size=93978265)
```
<details><summary>Trac metadata</summary>
|...```
:t 1e123456789
```
takes more than 3 seconds to get the type info.
```
:t 1e1234111111111111111111111
```
shows a warning/error,
```
GNU MP: Cannot allocate memory (size=93978265)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci takes super long time to find the type of large fractional number","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["type"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\n{{{\r\n:t 1e123456789\r\n}}}\r\n\r\n\r\ntakes more than 3 seconds to get the type info.\r\n\r\n{{{\r\n\r\n:t 1e1234111111111111111111111\r\n}}}\r\n\r\nshows a warning/error,\r\n\r\n\r\n{{{\r\nGNU MP: Cannot allocate memory (size=93978265)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->9.2.1Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/15424There should be a flag for GHCi that tells it to load as many modules as poss...2021-03-05T21:41:38ZmrkkrpThere should be a flag for GHCi that tells it to load as many modules as possibleRight now if GHCi runs into a module that contains an error, it stop loading altogether, AFAIU. It'd be good if it attempted to load as many modules as possible instead. For example, if I have modules A, B, and C and C contains an error,...Right now if GHCi runs into a module that contains an error, it stop loading altogether, AFAIU. It'd be good if it attempted to load as many modules as possible instead. For example, if I have modules A, B, and C and C contains an error, then as long as A and B do not depend on C, I should end up with them in scope no matter in which order I specify the modules in load script (the `--ghci-script` thing).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"There should be a flag for GHCi that tells it to load as many modules as possible","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":"Right now if GHCi runs into a module that contains an error, it stop loading altogether, AFAIU. It'd be good if it attempted to load as many modules as possible instead. For example, if I have modules A, B, and C and C contains an error, then as long as A and B do not depend on C, I should end up with them in scope no matter in which order I specify the modules in load script (the `--ghci-script` thing).","type_of_failure":"OtherFailure","blocking":[]} -->9.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/14789GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at p...2021-09-16T10:04:36ZKevinBuhrGHCi fails to garbage collect declaration `l = length [1..10^8]` entered at promptThis was recently reported on Stack Overflow (https://stackoverflow.com/questions/48723119/binding-len-length-xs-and-then-calculating-len-causes-ghc-to-consume-lots).
With GHC 8.2.2, assigning the length of a large list as a top-level d...This was recently reported on Stack Overflow (https://stackoverflow.com/questions/48723119/binding-len-length-xs-and-then-calculating-len-causes-ghc-to-consume-lots).
With GHC 8.2.2, assigning the length of a large list as a top-level declaration at the GHCi prompt and evaluating it:
```
Prelude> l = length [1..10^8]
Prelude> l
10000000
Prelude>
```
allocates about 7 gigs of memory before displaying a result, and then memory continues to grow over the next few seconds (at the idle GHCi prompt) until 10 gigs of memory has been allocated. None of it is freed until the interpreter session ends.
In contrast, directly evaluating the expression or assigning it with a let-statement does \*\*not\*\* exhibit this behavior:
```
Prelude> length [1..10^8]
10000000
Prelude> let l = length [1..10^8]
Prelude> l
10000000
Prelude>
```
Also, loading the top-level declaration from a file and then evaluating it at the prompt does \*\*not\*\* exhibit the problem.
I took a look at Ticket [14336](ticket:) and applied the `-fno-it` patch referenced there. This slightly changed the pattern of memory usage: it grew to about 4 gigs before displaying the result, but then continued to grow for several seconds at the GHCi prompt before landing at about 10 gigs.
I verified that the bug still exists on the current "master" branch (though I didn't check the "ghc-8.4" branch).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This was recently reported on Stack Overflow (https://stackoverflow.com/questions/48723119/binding-len-length-xs-and-then-calculating-len-causes-ghc-to-consume-lots).\r\n\r\nWith GHC 8.2.2, assigning the length of a large list as a top-level declaration at the GHCi prompt and evaluating it:\r\n\r\n{{{\r\nPrelude> l = length [1..10^8]\r\nPrelude> l\r\n10000000\r\nPrelude>\r\n}}}\r\n\r\nallocates about 7 gigs of memory before displaying a result, and then memory continues to grow over the next few seconds (at the idle GHCi prompt) until 10 gigs of memory has been allocated. None of it is freed until the interpreter session ends.\r\n\r\nIn contrast, directly evaluating the expression or assigning it with a let-statement does **not** exhibit this behavior:\r\n\r\n{{{\r\nPrelude> length [1..10^8]\r\n10000000\r\nPrelude> let l = length [1..10^8]\r\nPrelude> l\r\n10000000\r\nPrelude>\r\n}}}\r\n\r\nAlso, loading the top-level declaration from a file and then evaluating it at the prompt does **not** exhibit the problem.\r\n\r\nI took a look at Ticket [ticket: 14336] and applied the `-fno-it` patch referenced there. This slightly changed the pattern of memory usage: it grew to about 4 gigs before displaying the result, but then continued to grow for several seconds at the GHCi prompt before landing at about 10 gigs.\r\n\r\nI verified that the bug still exists on the current \"master\" branch (though I didn't check the \"ghc-8.4\" branch).","type_of_failure":"OtherFailure","blocking":[]} -->9.2.1ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/13795:kind! is not expanding type synonyms anymore2020-11-03T12:17:31ZHjulle:kind! is not expanding type synonyms anymoreGiven
```hs
type A = ()
:kind! A
```
Expected result:
```hs
A :: *
= ()
```
Actual result:
```hs
A :: *
= A
```
----
Some IRC conversation on the topic (on \#ghc):
```
23:37 < hjulle> :kind! does not seem to expand type synonyms ...Given
```hs
type A = ()
:kind! A
```
Expected result:
```hs
A :: *
= ()
```
Actual result:
```hs
A :: *
= A
```
----
Some IRC conversation on the topic (on \#ghc):
```
23:37 < hjulle> :kind! does not seem to expand type synonyms for me (in GHC 8.0.2), it just prints them
verbatim. Does anyone else have this problem? Example: "type A = ()" ":kind! A" will print out "A :: * = A" (which is not very helpful).
23:40 < hjulle> Is this a bug? The documentation
(https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#ghci-cmd-:kind)
explicitly states that :kind! should expand type synonyms, so I think yes?
23:57 < RyanGlScott> hjulle: That's absolute a bug. File a ticket!
23:57 < RyanGlScott> *absolutely
23:58 < RyanGlScott> Moreover, I know why that's happening
23:59 < RyanGlScott> Internally, :kind! uses the normalise_type function to reduce type families:
http://git.haskell.org/ghc.git/blob/e77b9a2069bca9018f989d7c4f54da099e3ab215:/compiler/types/FamInstEnv.hs#l1408
23:59 < RyanGlScott> But see the comment there
Day changed to 07 jun 2017
00:00 < RyanGlScott> -- Try to not to disturb type synonyms if possible
00:01 < RyanGlScott> So fixing this would just be a matter of calling coreView afterwards (which expands
type synonyms)
00:02 < RyanGlScott> er, actually, expandTypeSynonyms is even better:
http://git.haskell.org/ghc.git/blob/e77b9a2069bca9018f989d7c4f54da099e3ab215:/compiler/types/Type.hs#l364
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":":kind! is not expanding type synonyms anymore","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Given\r\n{{{#!hs\r\ntype A = ()\r\n:kind! A\r\n}}}\r\n\r\nExpected result:\r\n{{{#!hs\r\nA :: *\r\n= ()\r\n}}}\r\n\r\nActual result:\r\n{{{#!hs\r\nA :: *\r\n= A\r\n}}}\r\n\r\n----\r\n\r\nSome IRC conversation on the topic (on #ghc):\r\n{{{\r\n23:37 < hjulle> :kind! does not seem to expand type synonyms for me (in GHC 8.0.2), it just prints them\r\n verbatim. Does anyone else have this problem? Example: \"type A = ()\" \":kind! A\" will print out \"A :: * = A\" (which is not very helpful).\r\n23:40 < hjulle> Is this a bug? The documentation\r\n (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#ghci-cmd-:kind)\r\n explicitly states that :kind! should expand type synonyms, so I think yes?\r\n23:57 < RyanGlScott> hjulle: That's absolute a bug. File a ticket!\r\n23:57 < RyanGlScott> *absolutely\r\n23:58 < RyanGlScott> Moreover, I know why that's happening\r\n23:59 < RyanGlScott> Internally, :kind! uses the normalise_type function to reduce type families:\r\nhttp://git.haskell.org/ghc.git/blob/e77b9a2069bca9018f989d7c4f54da099e3ab215:/compiler/types/FamInstEnv.hs#l1408\r\n23:59 < RyanGlScott> But see the comment there\r\nDay changed to 07 jun 2017\r\n00:00 < RyanGlScott> -- Try to not to disturb type synonyms if possible\r\n00:01 < RyanGlScott> So fixing this would just be a matter of calling coreView afterwards (which expands\r\n type synonyms)\r\n00:02 < RyanGlScott> er, actually, expandTypeSynonyms is even better:\r\nhttp://git.haskell.org/ghc.git/blob/e77b9a2069bca9018f989d7c4f54da099e3ab215:/compiler/types/Type.hs#l364\r\n\r\n}}}\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->9.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/10576REPL returns list of all imported names when operator completion requested2021-03-01T16:53:34ZGeraldusREPL returns list of all imported names when operator completion requestedWhen querying completions for operators GHCi returns a list containing all imported names rather than suitable completions.
For example, if you simply start GHCi and run `:complete repl ">>"` command it will give you all names from base...When querying completions for operators GHCi returns a list containing all imported names rather than suitable completions.
For example, if you simply start GHCi and run `:complete repl ">>"` command it will give you all names from base and Prelude. Then if you import something else, for example `:m +Data.Text`, the result of query will contain names from Data.Text also.
In case of projects (`cabal repl`) things are worst, because returned list contains all names imported project-wise and it could be really huge.
GHCi behaves similarly with following queries:
```
:complete repl "(>>"
:complete repl "Prelude.>>"
:complete repl "Prelude.(>>"
```
I only tested this on OS X 10.9, GHC 7.8.49.2.1Roland SennRoland Senn