[Git][ghc/ghc][wip/T18191] 4 commits: Add info about typeclass evidence to .hie files

Tue May 26 10:53:08 UTC 2020

Ryan Scott pushed to branch wip/T18191 at Glasgow Haskell Compiler / GHC

Commits:
53814a64 by Zubin Duggal at 2020-05-26T03:03:24-04:00
Add info about typeclass evidence to .hie files

See `testsuite/tests/hiefile/should_run/HieQueries.hs` and
`testsuite/tests/hiefile/should_run/HieQueries.stdout` for an example of this

We add two new fields, `EvidenceVarBind` and `EvidenceVarUse` to the
`ContextInfo` associated with an Identifier. These are associated with the
appropriate identifiers for the evidence variables collected when we come across
`HsWrappers`, `TcEvBinds` and `IPBinds` while traversing the AST.

Instance dictionary and superclass selector dictionaries from `tcg_insts` and
classes defined in `tcg_tcs` are also recorded in the AST as originating from
their definition span

This allows us to save a complete picture of the evidence constructed by the
constraint solver, and will let us report this to the user, enabling features
like going to the instance definition from the invocation of a class method(or
any other method taking a constraint) and finding all usages of a particular
instance.

Additionally,

- Mark NodeInfo with an origin so we can differentiate between bindings
  origininating in the source vs those in ghc
- Along with typeclass evidence info, also include information on Implicit
  Parameters
- Add a few utility functions to HieUtils in order to query the new info

Updates haddock submodule

- - - - -
6604906c by Sebastian Graf at 2020-05-26T03:04:04-04:00
Make WorkWrap.Lib.isWorkerSmallEnough aware of the old arity

We should allow a wrapper with up to 82 parameters when the original
function had 82 parameters to begin with.

I verified that this made no difference on NoFib, but then again
it doesn't use huge records...

Fixes #18122.

- - - - -
cf772f19 by Sylvain Henry at 2020-05-26T03:04:45-04:00
Enhance Note [About units] for Backpack

- - - - -
ec02f82f by Ryan Scott at 2020-05-26T06:50:27-04:00
Make GADT constructors adhere to the forall-or-nothing rule properly

Issue #18191 revealed that the types of GADT constructors don't quite
adhere to the `forall`-or-nothing rule. This patch serves to clean up
this sad state of affairs somewhat. The main change is not in the
code itself, but in the documentation, as this patch introduces two
sections to the GHC User's Guide:

* A "Formal syntax for GADTs" section that presents a BNF-style
  grammar for what is and isn't allowed in GADT constructor types.
  This mostly exists to codify GHC's existing behavior, but it also
  imposes a new restriction that addresses #18191: the outermost
  `forall` and/or context in a GADT constructor is not allowed to be
  surrounded by parentheses. Doing so would make these
  `forall`s/contexts nested, and GADTs do not support nested
  `forall`s/contexts at present.

* A "`forall`-or-nothing rule" section that describes exactly what
  the `forall`-or-nothing rule is all about. Surprisingly, there was
  no mention of this anywhere in the User's Guide up until now!

To adhere the new specification in the "Formal syntax for GADTs"
section of the User's Guide, the following code changes were made:

* `GHC.Parser.PostProcess.mkGadtDecl` no longer strips away
  parentheses from the outermost `forall` and context. Instead, these
  parentheses are preserved so that the renamer can check for nested
  `forall`s/contexts later. See
  `Note [No nested foralls or contexts in GADT constructors]` in
  `GHC.Parser.PostProcess` for more details.

  One nice side effect of this change is that we can get rid of the
  explicit `AddAnn` tracking in `mkGadtDecl`, as we no longer need to
  remember the `AddAnn`s for stripped-away parentheses.

* `GHC.Renamer.Module.rnConDecl` now checks for nested
  `forall`s/contexts, rather than checking for this in the typechcker
  (in `GHC.Tc.TyCl.badDataConTyCon`). For the most part, this code
  was ported directly from `badDataConTyCon`, but designed to work
  over `HsType`s instead of `Type`s.

  One nice side effect of this change is that we are able to give a
  more accurate error message for GADT constructors that use visible
  dependent quantification (e.g., `MkFoo :: forall a -> a -> Foo a`),
  which improves the stderr in the `T16326_Fail6` test case.

Fixes #18191.

- - - - -

30 changed files:

- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/Rules.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Iface/Ext/Binary.hs
- compiler/GHC/Iface/Ext/Debug.hs
- compiler/GHC/Iface/Ext/Types.hs
- compiler/GHC/Iface/Ext/Utils.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/Module.hs
- compiler/GHC/Tc/TyCl.hs
- compiler/GHC/ThToHs.hs
- compiler/GHC/Unit.hs
- docs/users_guide/8.12.1-notes.rst
- docs/users_guide/exts/explicit_forall.rst
- docs/users_guide/exts/gadt_syntax.rst
- docs/users_guide/using-optimisation.rst
- testsuite/tests/dependent/should_fail/T16326_Fail6.stderr
- testsuite/tests/gadt/T12087.stderr
- testsuite/tests/gadt/T14320.hs
- + testsuite/tests/gadt/T14320.stderr
- testsuite/tests/gadt/T16427.stderr
- + testsuite/tests/gadt/T18191.hs
- + testsuite/tests/gadt/T18191.stderr
- testsuite/tests/gadt/all.T
- testsuite/tests/ghc-api/annotations/T10399.stdout
- testsuite/tests/ghc-api/annotations/Test10399.hs
- testsuite/tests/hiefile/should_compile/Scopes.hs

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5d753721f9642a67d90c0a5e273b788a14163054...ec02f82f1ec46f57bbb5887cbec62c4fc8671f9f

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5d753721f9642a67d90c0a5e273b788a14163054...ec02f82f1ec46f57bbb5887cbec62c4fc8671f9f
You're receiving this email because of your account on gitlab.haskell.org.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20200526/62c54682/attachment-0001.html>