[Git][ghc/ghc][wip/T18304] 13 commits: Simplify bindLHsTyVarBndrs and bindHsQTyVars

Simon Peyton Jones gitlab at gitlab.haskell.org
Wed Jun 10 11:44:47 UTC 2020 


Simon Peyton Jones pushed to branch wip/T18304 at Glasgow Haskell Compiler / GHC


Commits:
2dff8141 by Ryan Scott at 2020-06-05T14:21:24-04:00
Simplify bindLHsTyVarBndrs and bindHsQTyVars

Both `bindLHsTyVarBndrs` and `bindHsQTyVars` take two separate
`Maybe` arguments, which I find terribly confusing. Thankfully, it's
possible to remove one `Maybe` argument from each of these functions,
which this patch accomplishes:

* `bindHsQTyVars` takes a `Maybe SDoc` argument, which is `Just` if
  GHC should warn about any of the quantified type variables going
  unused. However, every call site uses `Nothing` in practice. This
  makes sense, since it doesn't really make sense to warn about
  unused type variables bound by an `LHsQTyVars`. For instance, you
  wouldn't warn about the `a` in `data Proxy a = Proxy` going unused.

  As a result, I simply remove this `Maybe SDoc` argument altogether.
* `bindLHsTyVarBndrs` also takes a `Maybe SDoc` argument for the same
  reasons that `bindHsQTyVars` took one. To make things more
  confusing, however, `bindLHsTyVarBndrs` also takes a separate
  `HsDocContext` argument, which is pretty-printed (to an `SDoc`) in
  warnings and error messages.

  In practice, the `Maybe SDoc` and the `HsDocContext` often contain
  the same text. See the call sites for `bindLHsTyVarBndrs` in
  `rnFamInstEqn` and `rnConDecl`, for instance. There are only a
  handful of call sites where the text differs between the
  `Maybe SDoc` and `HsDocContext` arguments:

  * In `rnHsRuleDecl`, where the `Maybe SDoc` says "`In the rule`"
    and the `HsDocContext` says "`In the transformation rule`".
  * In `rnHsTyKi`/`rn_ty`, where the `Maybe SDoc` says
    "`In the type`" but the `HsDocContext` is inhereted from the
    surrounding context (e.g., if `rnHsTyKi` were called on a
    top-level type signature, the `HsDocContext` would be
    "`In the type signature`" instead)

  In both cases, warnings/error messages arguably _improve_ by
  unifying making the `Maybe SDoc`'s text match that of the
  `HsDocContext`. As a result, I decided to remove the `Maybe SDoc`
  argument to `bindLHsTyVarBndrs` entirely and simply reuse the text
  from the `HsDocContext`. (I decided to change the phrase
  "transformation rule" to "rewrite rule" while I was in the area.)

  The `Maybe SDoc` argument has one other purpose: signaling when to
  emit "`Unused quantified type variable`" warnings. To recover this
  functionality, I replaced the `Maybe SDoc` argument with a
  boolean-like `WarnUnusedForalls` argument. The only
  `bindLHsTyVarBndrs` call site that chooses _not_ to emit these
  warnings in `bindHsQTyVars`.

- - - - -
e372331b by Ben Gamari at 2020-06-07T08:46:41-04:00
hadrian: Add missing deriveConstants dependency on ghcplatform.h

deriveConstants wants to compile C sources which #include PosixSource.h,
which itself #includes ghcplatform.h. Make sure that Hadrian knows
about this dependency.

Fixes #18290.

- - - - -
b022051a by Moritz Angermann at 2020-06-07T08:46:42-04:00
ghc-prim needs to depend on libc and libm

libm is just an empty shell on musl, and all the math functions are contained in
libc.

- - - - -
6dae6548 by Moritz Angermann at 2020-06-07T08:46:42-04:00
Disable DLL loading if without system linker

Some platforms (musl, aarch64) do not have a working dynamic linker
implemented in the libc, even though we might see dlopen.  It will
ultimately just return that this is not supported.  Hence we'll add
a flag to the compiler to flat our disable loading dlls.  This is
needed as we will otherwise try to load the shared library even
if this will subsequently fail.  At that point we have given up
looking for static options though.

- - - - -
4a158ffc by Moritz Angermann at 2020-06-07T08:46:43-04:00
Range is actually +/-2^32, not +/-2^31

See also: https://static.docs.arm.com/ihi0056/g/aaelf64.pdf

- - - - -
f1bfb806 by Ben Gamari at 2020-06-07T10:49:30-04:00
OccurAnal: Avoid exponential behavior due to where clauses

Previously the `Var` case of `occAnalApp` could in some cases (namely
in the case of `runRW#` applications) call `occAnalRhs` two. In the case
of nested `runRW#`s this results in exponential complexity. In some
cases the compilation time that resulted would be very long indeed
(see #18296).

Fixes #18296.

Metric Decrease:
    T9961
    T12150
    T12234

- - - - -
9b607671 by Takenobu Tani at 2020-06-09T08:05:46-04:00
Add link to GHC's wiki in the GHC API header

This adds a URL to point to GHC's wiki in the GHC API header.
Newcomers could easily find more information from the GHC API's
web like [1].

[1]: Current version, https://ghc.gitlab.haskell.org/ghc/doc/libraries/ghc-8.11.0.20200604/index.html

[skip ci]

- - - - -
72c7fe9a by Ryan Scott at 2020-06-09T08:06:24-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:

* A new function, `GHC.Hs.Type.splitLHsGADTPrefixTy`, was introduced.
  This is very much like `splitLHsSigmaTy`, except that it avoids
  splitting apart any parentheses, which can be syntactically
  significant for GADT types. See
  `Note [No nested foralls or contexts in GADT constructors]` in
  `GHC.Hs.Type`.

* `ConDeclGADTPrefixPs`, an extension constructor for `XConDecl`, was
  introduced so that `GHC.Parser.PostProcess.mkGadtDecl` can return
  it when given a prefix GADT constructor. Unlike `ConDeclGADT`,
  `ConDeclGADTPrefixPs` does not split the GADT type into its argument
  and result types, as this cannot be done until after the type is
  renamed (see `Note [GADT abstract syntax]` in `GHC.Hs.Decls` for why
  this is the case).

* `GHC.Renamer.Module.rnConDecl` now has an additional case for
  `ConDeclGADTPrefixPs` that (1) splits apart the full `LHsType` into
  its `forall`s, context, argument types, and result type, and
  (2) checks for nested `forall`s/contexts. Step (2) used to be
  performed the typechecker (in `GHC.Tc.TyCl.badDataConTyCon`) rather
  than the renamer, but now the relevant code from the typechecker
  can simply be deleted.

  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. Bumps the Haddock submodule.

- - - - -
a47e6442 by Ryan Scott at 2020-06-10T03:39:12-04:00
Always use rnImplicitBndrs to bring implicit tyvars into scope

This implements a first step towards #16762 by changing the renamer
to always use `rnImplicitBndrs` to bring implicitly bound type
variables into scope. The main change is in `rnFamInstEqn` and
`bindHsQTyVars`, which previously used _ad hoc_ methods of binding
their implicit tyvars.

There are a number of knock-on consequences:

* One of the reasons that `rnFamInstEqn` used an _ad hoc_ binding
  mechanism was to give more precise source locations in
  `-Wunused-type-patterns` warnings. (See
  https://gitlab.haskell.org/ghc/ghc/issues/16762#note_273343 for an
  example of this.) However, these warnings are actually a little
  _too_ precise, since implicitly bound type variables don't have
  exact binding sites like explicitly bound type variables do.
  A similar problem existed for
  "`Different names for the same type variable`" errors involving
  implicit tyvars bound by `bindHsQTyVars`.
  Therefore, we simply accept the less precise (but more accurate)
  source locations from `rnImplicitBndrs` in `rnFamInstEqn` and
  `bindHsQTyVars`. See
  `Note [Source locations for implicitly bound type variables]` in
  `GHC.Rename.HsType` for the full story.
* In order for `rnImplicitBndrs` to work in `rnFamInstEqn`, it needs
  to be able to look up names from the parent class (in the event
  that we are renaming an associated type family instance). As a
  result, `rnImplicitBndrs` now takes an argument of type
  `Maybe assoc`, which is `Just` in the event that a type family
  instance is associated with a class.
* Previously, GHC kept track of three type synonyms for free type
  variables in the renamer: `FreeKiTyVars`, `FreeKiTyVarsDups`
  (which are allowed to contain duplicates), and
  `FreeKiTyVarsNoDups` (which contain no duplicates). However, making
  is a distinction between `-Dups` and `-NoDups` is now pointless, as
  all code that returns `FreeKiTyVars{,Dups,NoDups}` will eventually
  end up being passed to `rnImplicitBndrs`, which removes duplicates.
  As a result, I decided to just get rid of `FreeKiTyVarsDups` and
  `FreeKiTyVarsNoDups`, leaving only `FreeKiTyVars`.
* The `bindLRdrNames` and `deleteBys` functions are now dead code, so
  I took the liberty of removing them.

- - - - -
24879129 by Takenobu Tani at 2020-06-10T03:39:59-04:00
Clarify leaf module names for new module hierarchy

This updates comments only.

This patch replaces leaf module names according to new module
hierarchy [1][2] as followings:

* Expand leaf names to easily find the module path:
  for instance, `Id.hs` to `GHC.Types.Id`.

* Modify leaf names according to new module hierarchy:
  for instance, `Convert.hs` to `GHC.ThToHs`.

* Fix typo:
  for instance, `GHC.Core.TyCo.Rep.hs` to `GHC.Core.TyCo.Rep`

See also !3375

[1]: https://gitlab.haskell.org/ghc/ghc/-/wikis/Make-GHC-codebase-more-modular
[2]: https://gitlab.haskell.org/ghc/ghc/issues/13009

- - - - -
92de9e25 by Ömer Sinan Ağacan at 2020-06-10T03:41:07-04:00
rts: Remove unused GET_ENTRY closure macro

This macro is not used and got broken in the meantime, as ENTRY_CODE was
deleted.

- - - - -
87102928 by Ömer Sinan Ağacan at 2020-06-10T03:41:50-04:00
Fix -fkeep-cafs flag name in users guide

- - - - -
f0fdf818 by Simon Peyton Jones at 2020-06-10T12:43:58+01:00
Trim the demand for recursive product types

Ticket #18304 showed that we need to be very careful
when exploring the demand (esp usage demand) on recursive
product types.

This patch solves the problem by trimming the demand on such types --
in effect, a form of "widening".

See the Note [Trimming a demand to a type] in DmdAnal, which explains
how I did this by piggy-backing on an existing mechansim for trimming
demands becuase of GADTs.  The significant payload of this patch is
very small indeed:

* Make GHC.Core.Opt.WorkWrap.Utils.typeShape use RecTcChecker to
  avoid looking through recursive types.

But on the way

* I found that ae_rec_tc was entirely inoperative and did nothing.
  So I removed it altogether from DmdAnal.

* I moved some code around in DmdAnal and Demand.
  (There are no actual changes in dmdFix.)

* I changed the API of DmsAnal.dmdAnalRhsLetDown to return
  a StrictSig rather than a decorated Id

* I removed the dead function peelTsFuns from Demand

- - - - -


30 changed files:

- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/Cmm/DebugBlock.hs
- compiler/GHC/Cmm/Node.hs
- compiler/GHC/Cmm/Ppr/Expr.hs
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/CFG.hs
- compiler/GHC/CmmToAsm/Dwarf.hs
- compiler/GHC/CmmToAsm/Monad.hs
- compiler/GHC/CmmToAsm/PPC/Ppr.hs
- compiler/GHC/CmmToAsm/SPARC/Ppr.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/CmmToAsm/X86/Ppr.hs
- compiler/GHC/CmmToLlvm/Base.hs
- compiler/GHC/CmmToLlvm/Data.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Coercion/Axiom.hs
- compiler/GHC/Core/FVs.hs
- compiler/GHC/Core/FamInstEnv.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/CprAnal.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/FloatIn.hs
- compiler/GHC/Core/Opt/OccurAnal.hs
- compiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Opt/Specialise.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/Rules.hs
- compiler/GHC/Core/TyCo/Rep.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/211e8e7cee9a0f32be6d70075b30d060d81a83e4...f0fdf81870da6c742804d5e3224ae38d72f1515d

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/211e8e7cee9a0f32be6d70075b30d060d81a83e4...f0fdf81870da6c742804d5e3224ae38d72f1515d
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/20200610/38bb5564/attachment-0001.html>

More information about the ghc-commits mailing list