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/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/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/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/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/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/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/16975Document how to update HIE2020-04-22T18:28:18ZRichard Eisenbergrae@richarde.devDocument how to update HIEGHC now has support for generating *HIE files*. This is a relatively new feature that furthers our goal of supporting better user-facing tooling. However, there is not much current info in the source tree for what a GHC dev should do to ...GHC now has support for generating *HIE files*. This is a relatively new feature that furthers our goal of supporting better user-facing tooling. However, there is not much current info in the source tree for what a GHC dev should do to maintain this structure. For example, if the surface syntax changes, how should the HIE support change accordingly?
Zubin Duggal has [kindly offered](https://mail.haskell.org/pipermail/ghc-devs/2019-July/017956.html) to write this up; this ticket is to track progress.https://gitlab.haskell.org/ghc/ghc/-/issues/16317HIE files don't include module import/export information2019-07-07T18:00:32ZMatthew PickeringHIE files don't include module import/export informationHIE files don't record information about import/exports.
This blocks implementing LSIF files which need to know about imports/exports.
Export information can be read from `tcg_exports`.
Import information can be got from the `HscEnv` ...HIE files don't record information about import/exports.
This blocks implementing LSIF files which need to know about imports/exports.
Export information can be read from `tcg_exports`.
Import information can be got from the `HscEnv` and looked up using `findImportedModule` I think.
Would be good to target this for 8.8 if there is any time remaining.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"HIE files don't include module import/export information","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"HIE files don't record information about import/exports. \r\n\r\nThis blocks implementing LSIF files which need to know about imports/exports.\r\n\r\nExport information can be read from `tcg_exports`.\r\n\r\nImport information can be got from the `HscEnv` and looked up using `findImportedModule` I think.\r\n\r\n\r\nWould be good to target this for 8.8 if there is any time remaining.","type_of_failure":"OtherFailure","blocking":[]} -->