GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-19T15:09:52Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24544Suggestion to add entity information to HieFile2024-03-19T15:09:52ZPatrickSuggestion to add entity information to HieFileNamespace is used to distinguish between different kinds of names that appear in a Haskell program in ghc.
But namespaces are falling too much behind the the number of entities that ghc can offers.
* By ghc 9.8.2: we are only having:`V...Namespace is used to distinguish between different kinds of names that appear in a Haskell program in ghc.
But namespaces are falling too much behind the the number of entities that ghc can offers.
* By ghc 9.8.2: we are only having:`VarName, DataName, TvName, TcClsName, FldName`.
* While we are having entities(simplified from `TyThing`): `patsyn, class, class method, type syn, type family...`
~~It might be a good idea to expand the namespace to support some more discrete classification as mentioned above. Like what we did with field name, `varName` is refined to `field name` in the rename stage. As a result, It can offer a cheap way to query more accurately what entity the occname refers to, especially combining with #24244 to expose the NameSpace constructor. ~~
The primary motivation is to ease the implementation of our tools and protocols without having to query `tyThing` or `Id`. It is expecially useful for tools are depend only on `HieFile`. Some related issue in HLS https://github.com/haskell/haskell-language-server/issues/4119
Protocols that need this information are:
1. `SymbolKind` in [LSIF](https://microsoft.github.io/language-server-protocol/specifications/lsif/0.6.0/specification/#documentSymbol) for document symbols
2. Semantic token's `tokenTypes` in [LSP](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#semanticTokensLegend) for semantic tokens
3. `Kind` in [scip](https://github.com/sourcegraph/scip/blob/f6c9fe6bf9a86f0bf904451a05fb47e0924818d2/scip.proto#L261)
Some tools for haskell that benefits:
Static-ls, HLS and other tools or library that wish to generate result for the above protocols solely based on `HieFile`.
----------------------------------
After discussion with simon, we probally should take another approach than messing up with namespaces,
create the a new data type for `EntityInfo` from `TyThing` and store it in the `IdentifierDetails` of the `HieFile`. (direct store of `TyThing` is too much).ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24493Module name in `module Hello where` is missing in the hieAst2024-03-09T14:39:42ZPatrickModule name in `module Hello where` is missing in the hieAst## Summary
ModuleName identifier is missing in the hieAst
## Steps to reproduce
hello.hs
```
module Hello where
go = "1"
```
ghc hello.hs -fno-code -fwrite-ide-info -fvalidate-ide-info -ddump-hie -fforce-recomp > result.txt
```
[1 of...## Summary
ModuleName identifier is missing in the hieAst
## Steps to reproduce
hello.hs
```
module Hello where
go = "1"
```
ghc hello.hs -fno-code -fwrite-ide-info -fvalidate-ide-info -ddump-hie -fforce-recomp > result.txt
```
[1 of 1] Compiling Hello ( hello.hs, nothing )
==================== HIE AST ====================
File: hello.hs
Node@hello.hs:3:1-8: Source: From source
{(annotations: {(FunBind, HsBindLR), (Match, Match),
(Module, Module), (XHsBindsLR, HsBindLR)}),
(types: [0]), (identifier info: {})}
Node@hello.hs:3:1-2: Source: From source
{(annotations: {}), (types: []),
(identifier info: {(name Hello.go, Details: Just 0 {LHS of a match group,
regular value bound with scope: ModuleScope bound at: hello.hs:3:1-8})})}
Node@hello.hs:3:4-8: Source: From source
{(annotations: {(GRHS, GRHS)}), (types: []),
(identifier info: {})}
Node@hello.hs:3:6-8: Source: From source
{(annotations: {(HsLit, HsExpr)}), (types: [0]),
(identifier info: {})}
```
## Expected behavior
Expect to get a node with an identifier moduleName `Hello`.
## Use case
The use case of this is in haskell language server when computing semantic tokens,
we are giving semantic token type to the identifier from the hieAst to enable
semantic highlighting.
Missing moduleName `Hello` introduce inconsistency when we generate semantic token type for module name.
See relevant discussion in https://github.com/haskell/haskell-language-server/discussions/4055#discussioncomment-85832909.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/20415HsMatchContext GhcTc story2024-01-31T13:59:31ZArtyom KuznetsovHsMatchContext GhcTc story`HsMatchContext` has `FunRhs` constructor with `mc_fun` field which is only used for pretty printing (and as it turned out, in HIE). Since removal of `NoGhcTc` from that field, we now have to deal with having `IdP` there which introduces...`HsMatchContext` has `FunRhs` constructor with `mc_fun` field which is only used for pretty printing (and as it turned out, in HIE). Since removal of `NoGhcTc` from that field, we now have to deal with having `IdP` there which introduces several complications.
## Approach 0 (mpickering): Use `IdP (NoGhcTc p)` in `HsMatchCtxt`( !9624 )
If we accept the existing of `NoGhcTc` then the simplest implementation is to replace the `mc_fun` field
in `HsMatchContext` with `IdP (NoGhcTc p)` so that the field contains a RdrName during parsing and a `Name` as context.
This is precisely the right approach to take because the "Context" is something which we define, and in the typechecker the context can't be an Id, precisely because we haven't constructed that Id yet when we need to provide the context for which we will construct the Id.
## Approach 1: an new type family for `mc_fun` instead of `IdP`
Instead of having `IdP` in `mc_fun` we have `CtxIdP` type family which is defined like this:
```haskell
type instance CtxIdP (GhcPass p) = CtxIdGhcP p
type family CtxIdGhcP p where
CtxIdGhcP 'Parsed = RdrName
CtxIdGhcP 'Renamed = Name
CtxIdGhcP 'Typechecked = Name
```
This approach was deemed unsatisfactory because:
* This is basically a local reimplementation of `NoGhcTc`. We lose the consistency of "`GhcPs` things have `RdrName`s in them, `GhcRn` things have `Name`s in them and `GhcTc` things have `Id`s in them".
* This results in a fairly invasive change because we change the inner structure of a data type here and also because of `OutputableBndr`. In order to pretty print `CtxIdP` we need to know that it's outputable. This results in a bunch of extra `OutputableBndr` constraints everywhere.
## Approach 2: `SDoc` in `mc_fun`
Since `mc_fun` is only used for pretty printing, and having to add a lot of new `Outputable` constraints everywhere is annoying, why not just put `SDoc` there? This would let us to remove pass parametrization from `HsMatchContext` and `HsStmtContext` completely.
Well, turns out, there is another obstacle: HIE. We need `Name` for a `ToHie (HsMatchContext p)` instance. Me, @int-index and @simonpj talked about this and concluded that we don't know enough about HIE to determine whether it would break things to somehow avoid having that instance at all or deal with this some other way.
One thing that's known for sure is that it is used by Haddock one way or another, because using `Id` there resulted in some broken Haddock tests: https://gitlab.haskell.org/hithroc/ghc/-/jobs/764890#L4106
## Approach 3 (current approach): Keep `IdP` in `mc_fun` and work around having `Id` there for `GhcTc`
This turned out to be the least invasive approach, yet not without its drawbacks.
The main problem of this approach lies within `tcMonoBinds`. `tcMatchesFun` needs to put an `Id` in `mc_fun`, but in `tcMonoBinds` we don't get the `mono_id` until after we have `rhs_ty` which we get in `tcMatchesFun`. This was solved by using `fixM` and making a thunk of `rhs_ty` to put into `mono_id` and then `mono_id` is passed to `tcMatchesFun` which then fills in that thunk.
The drawback is that `fixM` code is fragile, we rely on the fact that `tcMatchesFun` doesn't look at `varType` of `mono_id`. This might result in some fun debugging experience for someone who accidentally changes some code and inspects that value. Dancing around black holes as @rae calls it I believe (and I'm really fond of this metaphor)
Another thing of note that having `fixM` here should let us get rid of `TcIdBndr_ExpType`, however that turned out to be problematic, because `TcIdBndr_ExpType` is used in `zonkTidyTcLclEnvs` to determine whether to zonk or not and without that it always zonks, which results in inspection of the value and an infinite loop.
Relevant merge request: !5579
## What is the best way forward?
All 3 approaches seem unsatisfactory. Seems like Approach 2 is the closest to being ideal: we don't want to introduce something like `CtxIdP` and we don't want `fixM`. Approach 2 achieves that if someone figures out how to deal with HIE.https://gitlab.haskell.org/ghc/ghc/-/issues/23492Wrong reported types for partial field selectors in HIE files2023-09-13T12:07:02ZArtin Ghasivandghasivand.artin@gmail.comWrong reported types for partial field selectors in HIE filesWhen using HLS to ask for the type of a partial field selector, the reported type is:
```haskell
recSelError :: forall a. Addr# -> a
```
Example:
```haskell
module Test (T(..)) where
data T = A | RecordSel { a :: Bool
...When using HLS to ask for the type of a partial field selector, the reported type is:
```haskell
recSelError :: forall a. Addr# -> a
```
Example:
```haskell
module Test (T(..)) where
data T = A | RecordSel { a :: Bool
, b :: String
, c :: Char }
```
Dumping the hie-file of the source above results in the following output:
```
scope: ModuleScope bound at: Test.hs:4:26,
record field declaration bound at: Test.hs:4:31-34})})}
Source: generated by ghc
{(annotations: {(ConPat, Pat), (GRHS, GRHS), (HsApp, HsExpr),
(HsLit, HsExpr), (HsVar, HsExpr), (Match, Match),
(VarPat, Pat), (WildPat, Pat), (XExpr, HsExpr)}),
(types: [4, 1, 0, 5, 12]),
(identifier info: {(name Control.Exception.Base.recSelError, Details: Just 12 {usage}),
(name Test.RecordSel, Details: Nothing {usage}),
(name Test.a, Details: Just 3 {LHS of a match group,
record field pattern match bound at: Test.hs:4:26})})}
```
platform: macOs
ghc: 9.6.19.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/23120HIE file doesn't mention function referred to in left section with -XGHC20212023-08-29T20:41:58ZOllie CharlesHIE file doesn't mention function referred to in left section with -XGHC2021## Summary
The use of a section doesn't produce a corresponding reference in the generated `.hie` file.
## Steps to reproduce
Take the following as `Wat.hs`:
```haskell
module Wat where
wat x = (x &&)
```
Then compile this using:
...## Summary
The use of a section doesn't produce a corresponding reference in the generated `.hie` file.
## Steps to reproduce
Take the following as `Wat.hs`:
```haskell
module Wat where
wat x = (x &&)
```
Then compile this using:
```
ghc --make -fwrite-ide-info -XGHC2021 Wat.hs
```
Finally inspect the generated `Wat.hie` using `hiedb dump`:
```
$ hiedb dump Wat.hie
Node@Wat.hs:2:1-14: Source: From source
{(annotations: {(Module, Module), (AbsBinds, HsBindLR),
(FunBind, HsBindLR), (Match, Match)}),
(types: [3]), (identifier info: {})}
Node@Wat.hs:2:1-3: Source: From source
{(annotations: {}), (types: []),
(identifier info: {(name wat, Details: Just 3 {LHS of a match group,
regular value bound with scope: ModuleScope bound at: Wat.hs:2:1-14})})}
Node@Wat.hs:2:5: Source: From source
{(annotations: {(VarPat, Pat)}), (types: [0]),
(identifier info: {(name x, Details: Just 0 {bound in a pattern with scope: LocalScope Wat.hs:2:7-14 , NoScope })})}
Node@Wat.hs:2:7-14: Source: From source
{(annotations: {(GRHS, GRHS)}), (types: []),
(identifier info: {})}
Node@Wat.hs:2:9-14: Source: From source
{(annotations: {(HsPar, HsExpr)}), (types: []),
(identifier info: {})}
Node@Wat.hs:2:10-13: Source: From source
{(annotations: {(XExpr, HsExpr), (HsApp, HsExpr)}), (types: [2]),
(identifier info: {})}
Node@Wat.hs:2:10: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [0]),
(identifier info: {(name x, Details: Just 0 {usage})})}
```
Notice that there is a `{usage}` for x, but no usage for `&&`.
If we change `wat to be a right section:
```haskell
wat x = (&& x)
```
Then we get
```
Node@Wat.hs:2:1-14: Source: From source
{(annotations: {(Module, Module), (AbsBinds, HsBindLR),
(FunBind, HsBindLR), (Match, Match)}),
(types: [3]), (identifier info: {})}
Node@Wat.hs:2:1-3: Source: From source
{(annotations: {}), (types: []),
(identifier info: {(name wat, Details: Just 3 {LHS of a match group,
regular value bound with scope: ModuleScope bound at: Wat.hs:2:1-14})})}
Node@Wat.hs:2:5: Source: From source
{(annotations: {(VarPat, Pat)}), (types: [0]),
(identifier info: {(name x, Details: Just 0 {bound in a pattern with scope: LocalScope Wat.hs:2:7-14 , NoScope })})}
Node@Wat.hs:2:7-14: Source: From source
{(annotations: {(GRHS, GRHS)}), (types: []),
(identifier info: {})}
Node@Wat.hs:2:9-14: Source: From source
{(annotations: {(HsPar, HsExpr)}), (types: []),
(identifier info: {})}
Node@Wat.hs:2:10-13: Source: From source
{(annotations: {(XExpr, HsExpr), (HsApp, HsExpr)}), (types: [2]),
(identifier info: {})}
Node@Wat.hs:2:10-11: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [3]),
(identifier info: {(name &&, Details: Just 3 {usage})})}
Node@Wat.hs:2:13: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [0]),
(identifier info: {(name x, Details: Just 0 {usage})})}
```
which clearly mentions `&&`.
If we compile with `-XHaskell2010`, all is well:
```
ghc --make -fwrite-ide-info -XGHC2021 Wat.hs
Node@Wat.hs:2:1-14: Source: From source
{(annotations: {(Module, Module), (AbsBinds, HsBindLR),
(FunBind, HsBindLR), (Match, Match)}),
(types: [3]), (identifier info: {})}
Node@Wat.hs:2:1-3: Source: From source
{(annotations: {}), (types: []),
(identifier info: {(name wat, Details: Just 3 {LHS of a match group,
regular value bound with scope: ModuleScope bound at: Wat.hs:2:1-14})})}
Node@Wat.hs:2:5: Source: From source
{(annotations: {(VarPat, Pat)}), (types: [0]),
(identifier info: {(name x, Details: Just 0 {bound in a pattern with scope: LocalScope Wat.hs:2:7-14 , NoScope })})}
Node@Wat.hs:2:7-14: Source: From source
{(annotations: {(GRHS, GRHS)}), (types: []),
(identifier info: {})}
Node@Wat.hs:2:9-14: Source: From source
{(annotations: {(HsPar, HsExpr)}), (types: []),
(identifier info: {})}
Node@Wat.hs:2:10-13: Source: From source
{(annotations: {(XExpr, HsExpr), (HsApp, HsExpr)}), (types: [2]),
(identifier info: {})}
Node@Wat.hs:2:10: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [0]),
(identifier info: {(name x, Details: Just 0 {usage})})}
Node@Wat.hs:2:12-13: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [3]),
(identifier info: {(name &&, Details: Just 3 {usage})})}
````
If we change `wat` to have two arguments:
```haskell
wat x y = (x && y)
``
Then we get
```
...
Node@Wat.hs:2:12: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [0]),
(identifier info: {(name x, Details: Just 0 {usage})})}
Node@Wat.hs:2:14-15: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [3]),
(identifier info: {(name &&, Details: Just 3 {usage})})}
Node@Wat.hs:2:17: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [0]),
(identifier info: {(name y, Details: Just 0 {usage})})}
```
Likewise, if we remove all arguments from `wat`:
```haskell
wat = (&&)
```
We get
```
Node@Wat.hs:2:1-10: Source: From source
{(annotations: {(Module, Module), (AbsBinds, HsBindLR),
(FunBind, HsBindLR), (Match, Match)}),
(types: [3]), (identifier info: {})}
Node@Wat.hs:2:1-3: Source: From source
{(annotations: {}), (types: []),
(identifier info: {(name wat, Details: Just 3 {LHS of a match group,
regular value bound with scope: ModuleScope bound at: Wat.hs:2:1-10})})}
Node@Wat.hs:2:5-10: Source: From source
{(annotations: {(GRHS, GRHS)}), (types: []),
(identifier info: {})}
Node@Wat.hs:2:7-10: Source: From source
{(annotations: {(HsVar, HsExpr)}), (types: [3]),
(identifier info: {(name &&, Details: Just 3 {usage})})}
```
## Expected behavior
The expression
```haskell
wat x = (x &&)
```
should produce `{usage}` nodes mentioning both `x` and `(&&)`.
## Environment
* GHC version used: 9.2.6
Optional:
* Operating System: NixOS
* System Architecture: x86_64-linuxZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/23540Type signatures break evidence for syntactic constructs in hie files2023-08-29T20:41:58ZVasily SterekhovType signatures break evidence for syntactic constructs in hie files## Summary
Bindings that make use of syntactic constructs requiring special type class instances (`Monad` with do notation, `Num` with integer literals, `Enum` with ranges, `IsString`, `IsList`, etc.) refer to all relevant evidence vari...## Summary
Bindings that make use of syntactic constructs requiring special type class instances (`Monad` with do notation, `Num` with integer literals, `Enum` with ranges, `IsString`, `IsList`, etc.) refer to all relevant evidence variables in their corresponding nodes in `.hie` files only if the binding has no top-level type signature.
## Steps to reproduce
Compile the following with `ghc -fwrite-ide-info`:
```haskell
module Modulo1 where
data Modulo1 = Zero
instance Num Modulo1 where
fromInteger _ = Zero
zero = 0 :: Modulo1
zero' :: Modulo1
zero' = 0
```
Inspect the generated `.hie` file using `hiedb dump`. Only `zero` contains an evidence use for `$fNumModulo1`, `zero'` does not.
`zero`:
```
92 │ Node@Modulo1.hs:8:1-19: Source: From source
93 │ {(annotations: {(FunBind, HsBindLR), (Match, Match),
94 │ (XHsBindsLR, HsBindLR)}),
95 │ (types: [0]),
96 │ (identifier info: {(name $fNumModulo1, Details: Just 1 {usage of evidence variable}),
97 │ (name $dNum, Details: Just 1 {evidence variable bound by a let, depending on: [$fNumModulo1]
98 │ with scope: LocalScope Modulo1.hs:8:1-19
99 │ bound at: Modulo1.hs:8:1-19})})}
100 │
```
`zero'`:
```
136 │ Node@Modulo1.hs:11:1-9: Source: From source
137 │ {(annotations: {(FunBind, HsBindLR), (Match, Match),
138 │ (XHsBindsLR, HsBindLR)}),
139 │ (types: [0]), (identifier info: {})}
140 │
```
## Expected behavior
`zero` and `zero'` should both have evidence uses of `$fNumModulo1`.
## Environment
* GHC version used: 9.4.5, 9.6.1
## Possible cause
From my own investigation, the problem seems to come from the typechecker. For bindings without a type signature the evidence goes into the `abs_ev_binds` field of their corresponding `AbsBinds`. Meanwhile, for bindings with a type signature the evidence is instead assigned to `tcg_ev_binds` in `TcGblEnv`.ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/21698Missing documentation for HieAST etc structures2023-07-06T12:52:53ZOleg GrenrusMissing documentation for HieAST etc structuresIs there some documentation of why `HieAST` structure looks like what it does. There is probably some logic (`Data` based?) on how its generated, but it doesn't make much sense by just reading haddocks.
- Why annotations is a Set, (whic...Is there some documentation of why `HieAST` structure looks like what it does. There is probably some logic (`Data` based?) on how its generated, but it doesn't make much sense by just reading haddocks.
- Why annotations is a Set, (which is mostly singleton, but sometimes empty, or actually containing multiple annotations)
- Why `HieFile` has a `Map HiePath (HieAST a)`, what are these paths? Can this map be empty?
- What is `NodeOrigin` for? Can node has both, either or **none** of `NodeInfo`. What is the difference?9.2.4ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/16901GHC needs to distribute .hie files for base libraries2023-06-27T15:12:24ZMatthew PickeringGHC needs to distribute .hie files for base libraries`.hie` files need to be distributed as part of the release process so that projects using `.hie` files work with
the base libraries.
For example, go-to definition should work for functions defined in the base libraries as well as userl...`.hie` files need to be distributed as part of the release process so that projects using `.hie` files work with
the base libraries.
For example, go-to definition should work for functions defined in the base libraries as well as userland.
The best way to do this might be to distribute a separate tarball which just contains the `.hie` files which can be downloaded and installed separately to the usual bindists. Another option is to include the `.hie` files in the bindists, just like how we do for other documentation.
I made a MR !1337 towards this direction in the expectation of some refinement.ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/21619Panic when compiling module with typed TH splice with -fwrite-ide-info2023-04-28T12:59:40ZAlexis KingPanic when compiling module with typed TH splice with -fwrite-ide-infoCompiling the following module panics on GHC HEAD:
```haskell
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -fwrite-ide-info #-}
module M where
import Language.Haskell.TH.Syntax
newtype T = T { getT :: Int }
instance Lift T where
...Compiling the following module panics on GHC HEAD:
```haskell
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -fwrite-ide-info #-}
module M where
import Language.Haskell.TH.Syntax
newtype T = T { getT :: Int }
instance Lift T where
liftTyped v = [||T $$(liftTyped (getT v))||]
```
```
ghc: panic! (the 'impossible' happened)
GHC version 9.5.20220523:
hsExprType: Unexpected HsSpliceE
unTypeCode (liftTyped (getT v_a1Ww))
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:182:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Hs/Syn/Type.hs:134:30 in ghc:GHC.Hs.Syn.Type
```
I haven’t investigated what’s going on here yet, so there might be a simpler reproduction case, but this is the one I found.9.4.3Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/23085stale hie files are not deleted by GHC2023-03-14T14:51:37ZCody Goodmanstale hie files are not deleted by GHC## Summary
In our company CI we use weeder with an option to make sure source files exist:
```
weeder --require-hs-files
```
That flag is essentially an imperfect workaround for GHC not deleting stale HIE files. After we began cachin...## Summary
In our company CI we use weeder with an option to make sure source files exist:
```
weeder --require-hs-files
```
That flag is essentially an imperfect workaround for GHC not deleting stale HIE files. After we began caching dist-newstyle across CI runs in GHC 9.4 however the workaround stopped working for us.
It seems to me that the proper fix is for GHC to delete these stale HIE files by default.
## Steps to reproduce
I haven't retested this set of steps, but to best of my memory:
- Build a haskell project using `-fwrite-ide-info` with module `A` and function `f`
- copy the dist-newstyle directory that includes hie files to `initial-dist-newstyle`
- verify the HIE file for module A is there
- remove module `A` entirely
- build again with `-fwrite-ide-info`
- observe that the HIE file for module A still exists
## Expected behavior
When I remove the source file for module A, any subsequent call to ghc should remove any stale HIE files.
## Environment
* GHC version used: 9.4.4
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/22416ghc 9.4.3 panic with funResultTy2022-12-13T09:31:01ZDoug Burkeghc 9.4.3 panic with funResultTy## Summary
I mentioned this as part of #22171 but now that 9.4.3 has been released I wanted to make sure it's not lost.
Trying to compile the swish package results in
```
Building library for swish-0.10.2.0..
[ 1 of 55] Compiling Dat...## Summary
I mentioned this as part of #22171 but now that 9.4.3 has been released I wanted to make sure it's not lost.
Trying to compile the swish package results in
```
Building library for swish-0.10.2.0..
[ 1 of 55] Compiling Data.Interned.URI
[ 2 of 55] Compiling Data.Ord.Partial
[ 3 of 55] Compiling Data.String.ShowLines
[ 4 of 55] Compiling Network.URI.Ord
[ 5 of 55] Compiling Swish.GraphClass
[ 6 of 55] Compiling Swish.GraphMatch
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.4.3:
funResultTy
GenLabelMap lb_adso LabelIndex
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:182:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Core/Type.hs:1334:49 in ghc:GHC.Core.Type
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Steps to reproduce
With GHC 9.4.3 (thanks ghcup)
```
% ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.4.3
```
we have
```
% git checkout https://gitlab.com/dburke/swish
% cd swish
% cabal install --allow-newer=base
Wrote tarball sdist to
/home/dburke/haskell/ghcup/swish/dist-newstyle/sdist/swish-0.10.2.0.tar.gz
Resolving dependencies...
Build profile: -w ghc-9.4.3 -O1
In order, the following will be built (use -v for more details):
- swish-0.10.2.0 (lib) (requires build)
- swish-0.10.2.0 (exe:Swish) (requires build)
Starting swish-0.10.2.0 (lib)
Building swish-0.10.2.0 (lib)
Failed to build swish-0.10.2.0.
Build log (
/home/dburke/.cabal/logs/ghc-9.4.3/swish-0.10.2.0-e3487166464e6bbde8ec07c43b2587c3fef0f74f131cda10f70441643557d8ef.log
):
Configuring library for swish-0.10.2.0..
Preprocessing library for swish-0.10.2.0..
Building library for swish-0.10.2.0..
[ 1 of 55] Compiling Data.Interned.URI
[ 2 of 55] Compiling Data.Ord.Partial
[ 3 of 55] Compiling Data.String.ShowLines
[ 4 of 55] Compiling Network.URI.Ord
[ 5 of 55] Compiling Swish.GraphClass
[ 6 of 55] Compiling Swish.GraphMatch
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.4.3:
funResultTy
GenLabelMap lb_adso LabelIndex
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:182:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Core/Type.hs:1334:49 in ghc:GHC.Core.Type
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
[ 8 of 55] Compiling Swish.GraphPartition
[ 9 of 55] Compiling Swish.QName
...
... a lot of other stuff that's not relevant here
...
```
## Expected behavior
To be able to build and test the code
## Environment
* GHC version used: 9.4.3
Optional:
* Operating System: Linux
* System Architecture: x86_649.4.4https://gitlab.haskell.org/ghc/ghc/-/issues/21797HieAST missing types with record-dot-syntax2022-08-04T14:18:38ZColten WebbHieAST missing types with record-dot-syntax## Summary
HieAST doesn't contain the proper type information for record dot syntax usage.
## Steps to reproduce
Here is a [sample program](https://github.com/coltenwebb/hiedemo) that demonstrates the issue. The program is written for...## Summary
HieAST doesn't contain the proper type information for record dot syntax usage.
## Steps to reproduce
Here is a [sample program](https://github.com/coltenwebb/hiedemo) that demonstrates the issue. The program is written for 9.2.2, but the output is the same for the 9.4 pre-release.
## Expected behavior
I expect HieAST to have type information for the nodes that correspond to the use of record-dot-syntax. Instead, the node corresponding to `x.b` has no type information, shown below.
```
Node@app/Test.hs:14:17-19: Source: From source
{(annotations: {(HsApp, HsExpr), (XExpr, HsExpr)}),
(types: []), (identifier info: {})}
```
The full outputs/comparison are also shown in the readme of the sample program above.
## Environment
* GHC version used: 9.2.2
* (also tested on 9.4 prerelease with some modifications to sample code, but gives identical output)9.4.1ZubinColten WebbZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/18425Various -fvalidate-ide-info failures on HEAD involving type variable scoping2022-07-14T21:41:16ZRyan ScottVarious -fvalidate-ide-info failures on HEAD involving type variable scopingIf you compile the following file with GHC HEAD using `-fwrite-ide-info -fvalidate-ide-info`:
```hs
{-# LANGUAGE DerivingVia #-}
{-# LANGUAGE InstanceSigs #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE StandaloneDeriving #-}
{-# ...If you compile the following file with GHC HEAD using `-fwrite-ide-info -fvalidate-ide-info`:
```hs
{-# LANGUAGE DerivingVia #-}
{-# LANGUAGE InstanceSigs #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
newtype List a = MkList [a]
deriving via forall a. [a] instance Eq a => Eq (List a)
class C a where
m :: forall b. a -> b -> b
m _ = undefined @_ @a `seq` id @b
instance C [a] where
m :: forall b. [a] -> b -> b
m _ = undefined @_ @a `seq` id @b
type family T a
type instance T [a] = a
```
You will get a volley of errors:
```
$ ~/Software/ghc5/inplace/bin/ghc-stage2 Bug.hs -fforce-recomp -fwrite-ide-info -fvalidate-ide-info
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Got invalid scopes
Name b Defined at Bug.hs:17:15 at position Bug.hs:18:35 doesn't occur in calculated scope [LocalScope Bug.hs:17:18-30,
LocalScope Bug.hs:14:3-35]
Name a Defined at Bug.hs:10:21 at position Bug.hs:10:40 doesn't occur in calculated scope [LocalScope Bug.hs:10:24-26]
Name a Defined at Bug.hs:10:21 at position Bug.hs:10:54 doesn't occur in calculated scope [LocalScope Bug.hs:10:24-26]
Got roundtrip errors
LocalName a{tv} Bug.hs:21:17-19 and LocalName a{tv} Bug.hs:21:1-23 do not match
In Node:
([(Right a{tv agy},
Details: Nothing {type variable binding with scope: LocalScope Bug.hs:21:15-23 , type variable scopes: LocalScope Bug.hs:21:1-23})],
Bug.hs:21:17-19)
and
([(Right a{tv r1lk},
Details: Nothing {type variable binding with scope: LocalScope Bug.hs:21:15-23 , type variable scopes: LocalScope Bug.hs:21:1-23})],
Bug.hs:21:17-19)
While comparing
[(Right LocalName a{tv} Bug.hs:21:17-19,
Details: Nothing {type variable binding with scope: LocalScope Bug.hs:21:15-23 , type variable scopes: LocalScope Bug.hs:21:1-23})]
and
[(Right LocalName a{tv} Bug.hs:21:1-23,
Details: Nothing {type variable binding with scope: LocalScope Bug.hs:21:15-23 , type variable scopes: LocalScope Bug.hs:21:1-23})]
```
I noticed these when perusing the code in `GHC.Iface.Ext.Ast` recently. cc @wz10009.4.1ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/16233HIE file generation is inefficient2022-07-05T10:21:03ZAlec TheriaultHIE file generation is inefficientGenerating HIE files eats up a lot of memory and takes a long time. There are at least two big parts to this:
- Every expression in the AST is desugared via `deSugarExpr` for the purpose of extracting a type. GHC ends up doing the same ...Generating HIE files eats up a lot of memory and takes a long time. There are at least two big parts to this:
- Every expression in the AST is desugared via `deSugarExpr` for the purpose of extracting a type. GHC ends up doing the same work multiple times for the same nodes. Ex: in order to desugar `HsApp _ fun arg`, GHC desugars both `fun` and `arg`, yet the HIE code doesn't cache that (so it ends up desugaring `fun` and `arg` at least once more).
- There is a lot of stuff being written into these HIE files, making them quite big (even after compressing/deduplicating type information). One data point: the largest HIE file at time of writing is `Parser.hie`, which is 7.2MB, compared to just 58K for `Parser.hi`Q Writing large files is naturally going to take up memory and be slow.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"HIE file generation is inefficient","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Generating HIE files eats up a lot of memory and takes a long time. There are at least two big parts to this:\r\n\r\n * Every expression in the AST is desugared via `deSugarExpr` for the purpose of extracting a type. GHC ends up doing the same work multiple times for the same nodes. Ex: in order to desugar `HsApp _ fun arg`, GHC desugars both `fun` and `arg`, yet the HIE code doesn't cache that (so it ends up desugaring `fun` and `arg` at least once more).\r\n\r\n * There is a lot of stuff being written into these HIE files, making them quite big (even after compressing/deduplicating type information). One data point: the largest HIE file at time of writing is `Parser.hie`, which is 7.2MB, compared to just 58K for `Parser.hi`Q Writing large files is naturally going to take up memory and be slow.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/20341HIE evidence for ToJSON instances derived using DeriveAnyClass don't rely on ...2022-03-29T10:52:24ZOllie CharlesHIE evidence for ToJSON instances derived using DeriveAnyClass don't rely on Generic evidence## Summary
HIE files in GHC 9 onwards contain evidence for type class dictionaries. However, this evidence chain doesn't seem complete when we look at instances that are derived using `DeriveAnyClass`, default methods, and `Generics`.
...## Summary
HIE files in GHC 9 onwards contain evidence for type class dictionaries. However, this evidence chain doesn't seem complete when we look at instances that are derived using `DeriveAnyClass`, default methods, and `Generics`.
## Steps to reproduce
Compile the following with `-fwrite-ide-info`:
```haskell
{-# language DeriveAnyClass #-}
{-# language DeriveGeneric #-}
module Test where
import Data.Aeson
import GHC.Generics ( Generic )
data T = MkT { fieldName :: Bool }
deriving (Generic, ToJSON, FromJSON)
```
Next, load the resulting `.hie` file with `hiedb dump` and search the pretty-printed tree for `Generic`. You should find `$dGeneric` and `$dToJSON` symbols, but no connection between them. This seems to suggest that the `ToJSON T` instance doesn't depend on the `Generic T` instance, but that's incorrect.
## Expected behavior
The evidence for `ToJSON T` should mention the evidence for `Generic T`.
## Environment
* GHC version used: 9.0.19.4.1ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/20150hsExprType returns incorrect type for static forms2022-01-18T21:46:05ZMatthew PickeringhsExprType returns incorrect type for static forms`hsExprType` has the clause:
```
hsExprType (HsStatic _ e) = lhsExprType e
```
but this is wrong, the type of `static 0` is not `Int` but `StaticPtr Int`.
The fix is morally to instead have
```
hsExprType (HsStatic _ e) = mkTyConApp ...`hsExprType` has the clause:
```
hsExprType (HsStatic _ e) = lhsExprType e
```
but this is wrong, the type of `static 0` is not `Int` but `StaticPtr Int`.
The fix is morally to instead have
```
hsExprType (HsStatic _ e) = mkTyConApp staticPtrTyCon (lhsExprType e)
```
but right now `StaticPtr` is not wired-in so this is a bit awkward.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/19693Data.Typeable.Internal with -fwrite-ide-info causes a panic2021-05-05T09:43:44ZMatthew PickeringData.Typeable.Internal with -fwrite-ide-info causes a panicI was trying to build GHC with `-fwrite-ide-info` but this leads to a hard to understand panic when compiling `Data.Typeable.Internal`.
To reproduce, the following goes in `hadrian.settings`.
```
stage1.*.ghc.hs.opts += -fwrite-ide-info...I was trying to build GHC with `-fwrite-ide-info` but this leads to a hard to understand panic when compiling `Data.Typeable.Internal`.
To reproduce, the following goes in `hadrian.settings`.
```
stage1.*.ghc.hs.opts += -fwrite-ide-info
```
Then this command line fails.
```
_build/stage0/bin/ghc -Wall -fdiagnostics-color=never -dynamic-too -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id base-4.16.0.0' '-package-id ghc-bignum-1.0' '-package-id ghc-prim-0.8.0' '-package-id rts-1.0' -i -i/home/matt/ghc-ticky/_build/stage1/libraries/base/build -i/home/matt/ghc-ticky/_build/stage1/libraries/base/build/autogen -i/home/matt/ghc-ticky/libraries/base -Iincludes -I_build/stage1/lib -I_build/stage1/libraries/base/build -I/nix/store/7jz3aqg5ls1jpzvra512spih4asidr2i-gmp-6.2.0-dev/include -I_build/stage1/libraries/base/build/include -Ilibraries/base/include -I/nix/store/7jz3aqg5ls1jpzvra512spih4asidr2i-gmp-6.2.0-dev/include -I/home/matt/ghc-ticky/_build/stage1/lib/x86_64-linux-ghc-9.1.20210323/ghc-bignum-1.0/include -I/nix/store/35v0m2ih9q4x3crhxiyr3pxc8ckn73gi-elfutils-0.180/include -I/nix/store/saghih5p46g1nm8vmvxc5vw5pfj1nc79-numactl-2.0.13/include -I/home/matt/ghc-ticky/_build/stage1/lib/x86_64-linux-ghc-9.1.20210323/rts-1.0/include -I_build/stage1/lib -optc-I_build/stage1/lib -optP-include -optP_build/stage1/libraries/base/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/base/build -Wnoncanonical-monad-instances -optc-Wno-error=inline -optP-Wno-nonportable-include-path -c libraries/base/Data/Typeable/Internal.hs -o _build/stage1/libraries/base/build/Data/Typeable/Internal.o -O2 -H32m -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -no-global-package-db -package-db=/home/matt/ghc-ticky/_build/stage1/lib/package.conf.d -ghcversion-file=/home/matt/ghc-ticky/_build/stage1/lib/ghcversion.h -haddock -Wno-deprecated-flags -Wno-trustworthy-safe -ticky -ticky-allocd -ticky-dyn-thunk -ddump-to-file -ddump-stg-final -fwrite-ide-info
```
Removing the final `-write-ide-info` leads to the command succeeding.
I suspect this is related to #19334https://gitlab.haskell.org/ghc/ghc/-/issues/18426-fwrite-ide-info/-fvalidate-ide-info not listed in User's Guide flag reference2020-09-16T09:26:08ZRyan Scott-fwrite-ide-info/-fvalidate-ide-info not listed in User's Guide flag reference`-fwrite-ide-info` and `-fvalidate-ide-info` are described in https://downloads.haskell.org/~ghc/8.10.1/docs/html/users_guide/separate_compilation.html#options-related-to-extended-interface-files. However, they are _not_ listed in the fl...`-fwrite-ide-info` and `-fvalidate-ide-info` are described in https://downloads.haskell.org/~ghc/8.10.1/docs/html/users_guide/separate_compilation.html#options-related-to-extended-interface-files. However, they are _not_ listed in the flag reference (https://downloads.haskell.org/~ghc/8.10.1/docs/html/users_guide/flags.html) for some reason. Why not?https://gitlab.haskell.org/ghc/ghc/-/issues/18686Question about .hie files2020-09-14T18:13:37ZRik van der KleijQuestion about .hie files## Question
To have better support for navigation within library files (e.g. with IntelliJ-Haskell) it would be cool when GHC also generates .hie files for (transitive) dependencies of a Haskell project.
Question, is that currently pos...## Question
To have better support for navigation within library files (e.g. with IntelliJ-Haskell) it would be cool when GHC also generates .hie files for (transitive) dependencies of a Haskell project.
Question, is that currently possible?https://gitlab.haskell.org/ghc/ghc/-/issues/16804GHCi: Reimplement +c using the same machinery as .hie files2020-08-12T17:06:22ZMatthew PickeringGHCi: Reimplement +c using the same machinery as .hie filesA number of operations driven by `+c` in GHCi are inefficient, for example finding all the types in a module involves a lot of redundant calls to `dsExpr`.
A lot of the same logic is implemented more efficiently in the logic which gene...A number of operations driven by `+c` in GHCi are inefficient, for example finding all the types in a module involves a lot of redundant calls to `dsExpr`.
A lot of the same logic is implemented more efficiently in the logic which generates `.hie` files. It would be good to unify the two mechanisms.
The suggested implementation plan is to replace the `[SpanInfo]` in `ModInfo` with `HieFile` and then fixing all the type errors.
https://gitlab.haskell.org/ghc/ghc/blob/master/ghc/GHCi/UI/Info.hs#L53
cc/ @wz1000