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/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/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/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/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.https://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/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/ @wz1000https://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/15320Save the types in the typechecked syntax tree2020-08-12T17:06:22ZnboldiSave the types in the typechecked syntax treeWhen working on development tools that use the GHC API as a backend, it is useful to have information on the types (or kinds) of the elements of the syntax tree (expressions, patterns, types).
I found that the lack of this semantic info...When working on development tools that use the GHC API as a backend, it is useful to have information on the types (or kinds) of the elements of the syntax tree (expressions, patterns, types).
I found that the lack of this semantic information is limiting in some cases of refactoring transformations (for example to generate the type signature or extract a subexpression to a binding with type signature), and is necessary for tools that try to fix common programmer errors. But there should be other kind of tools that this little change may help.
The type is currently saved for some expressions and most patterns but it would be useful if it would be available uniformly.
It could be implemented nicely by adding type information to the `X* GhcTc` type families.
I plan to implement these changes, I'm just asking the opinion of the developers about a change in this direction.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Save the types in the typechecked syntax tree","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"When working on development tools that use the GHC API as a backend, it is useful to have information on the types (or kinds) of the elements of the syntax tree (expressions, patterns, types).\r\n\r\nI found that the lack of this semantic information is limiting in some cases of refactoring transformations (for example to generate the type signature or extract a subexpression to a binding with type signature), and is necessary for tools that try to fix common programmer errors. But there should be other kind of tools that this little change may help.\r\n\r\nThe type is currently saved for some expressions and most patterns but it would be useful if it would be available uniformly.\r\n\r\nIt could be implemented nicely by adding type information to the `X* GhcTc` type families.\r\n\r\nI plan to implement these changes, I'm just asking the opinion of the developers about a change in this direction.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->