GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-06-19T01:18:39Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16686HIE file versions are not checked, and they don't have a sensible header2019-06-19T01:18:39ZZubinHIE file versions are not checked, and they don't have a sensible headerEven though we have a `hie_file_version` field in HieFiles, while reading HIE files, we don't
check to see if this matches. This version is also doesn't appear at the start of the file,
but two Word32s after.
A more sensible approach wo...Even though we have a `hie_file_version` field in HieFiles, while reading HIE files, we don't
check to see if this matches. This version is also doesn't appear at the start of the file,
but two Word32s after.
A more sensible approach would be to have a header for .hie files which is immediately recognizable, and
includes the version of the HIE file format, as well as the version of GHC the file was generated with.
The HIE file version should also be generated automatically from the GHC version as is done for interface files
The proposed new header format for HIE files is:
- 3 bytes (0x48,0x49,0x45) corresponding to the capital ASCII letters "HIE"
- 1 Integer for the current HIE file version
- 1 Int for the length of the GHC version
- The raw bytes of the current GHC version
It is important that this is included in the 8.8 release, as 8.8 is the first release in which .hie files appear.8.8.1ZubinZubin2019-05-24https://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/18329HIE files compatibility across different GHC versions2020-07-03T19:04:06ZDmitrii KovanikovHIE files compatibility across different GHC versions## Motivation
When developing Haskell tools, it's desirable to be able to build the binary of your tool in advance and allow users to download the pre-built binary rather than asking them to build the tool from scratch on their machines...## Motivation
When developing Haskell tools, it's desirable to be able to build the binary of your tool in advance and allow users to download the pre-built binary rather than asking them to build the tool from scratch on their machines. Building Haskell packages can take a significant amount of time, so having already built binaries is a much friendlier UX.
Fortunately, it's possible to build Haskell binaries on Linux (even statically linked!), macOS and Windows. However, if the tooling uses GHC API and, specifically, analyses HIE files, it's quite challenging to prepare a single binary that works on a variety of projects that use different GHC versions.
For example, if my tool that reads HIE files is built with GHC-8.8.3 and the library is built with GHC-8.8.2, I see the following error message:
```
stan: stan: panic! (the 'impossible' happened)
(GHC version 8.8.3 for x86_64-unknown-linux):
readHieFile: hie file versions don't match for file: .hie/Relude.hie Expected 8083 but got 8082
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
This is quite unfortunate, and it would be nice if the fact that different GHCs were used to build the tool and a Haskell project wouldn't matter.
## Proposal
Implement backwards compatibility scheme for HIE files.
If some Haskell library was built with the GHC version X, and the tool was built with the GHC version Y, the tool should be able to read HIE files for that library if one of the following criteria satisfies:
1. X < Y
2. X and Y are different minor versions of the same major GHC versionhttps://gitlab.haskell.org/ghc/ghc/-/issues/17222.hie files don't contain template Haskell splices2020-04-03T14:45:16ZOllie Charles.hie files don't contain template Haskell splices## Motivation
I want to use the new `.hie` files to do full-project reachability analysis. Given some roots (e.g., `main` in module `Main`), the program will report any declarations that aren't reachable from those roots, thus identifyi...## Motivation
I want to use the new `.hie` files to do full-project reachability analysis. Given some roots (e.g., `main` in module `Main`), the program will report any declarations that aren't reachable from those roots, thus identifying them as dead code. I do this by traversing `HieAST`s and building a graph of which symbols refer to which. However, Template Haskell splices aren't expanded, so if something is referred to from a splice, it won't cause that node to be correctly represented in the reachability graph.
One example of this is Yesod - we have the splice `mkYesodDispatch "App" resourcesApp`, which creates a `YesodDispatch` instance for `App`:
```
src/AppMain.hs:80:1-34: Splicing declarations
mkYesodDispatch "App" resourcesApp
======>
instance YesodDispatch App where
yesodDispatch env6176_a1vQg req6176_a1vQh
= helper6176_a1vQi (pathInfo req6176_a1vQh)
where
helper6176_a1vQi ((:) "robots.txt" [])
= case requestMethod req6176_a1vQh of
"GET"
-> (((yesodRunner getRobotTxtR) env6176_a1vQg) (Just RobotTxtR))
req6176_a1vQh
_ -> (((yesodRunner (void badMethod)) env6176_a1vQg)
(Just RobotTxtR))
req6176_a1vQh
```
However, the `.hie` file doesn't contain all of this information, it only contains the instance head. `ppHie` reports:
```
Node src/AppMain.hs:80:1-34 [(AbsBinds, HsBindLR),
(ClsInstD, InstDecl), (FunBind, HsBindLR), (HsApp, HsExpr),
(HsAppTy, HsType), (HsConLikeOut, HsExpr), (HsTyVar, HsType),
(HsVar, HsExpr), (HsWrap, HsExpr), (VarBind, HsBindLR)] [53, 58,
55,
66] [(Right C:YesodDispatch,
IdentifierDetails Nothing {Use}),
(Right yesodDispatch,
IdentifierDetails Nothing {ValBind InstanceBind ModuleScope (Just SrcSpanOneLine "src/AppMain.hs" 80 1 35)}),
(Right yesodDispatch,
IdentifierDetails Just 55 {ValBind RegularBind ModuleScope (Just SrcSpanOneLine "src/AppMain.hs" 80 1 35)}),
(Right $cyesodDispatch,
IdentifierDetails Just 55 {Use}),
(Right $cp1YesodDispatch,
IdentifierDetails Just 53 {Use})]
```
and that's it. Thus the symbols referred to in the definition of `yesodDispatch` aren't visible to me.
## Proposal
The full instance declaration is visible.