[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 8 commits: rts: improve memory ordering and add some comments in the StablePtr implementation

Marge Bot (@marge-bot) gitlab at gitlab.haskell.org
Sat Apr 15 00:26:34 UTC 2023 


Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC


Commits:
a34aa8da by Adam Sandberg Ericsson at 2023-04-14T04:17:52-04:00
rts: improve memory ordering and add some comments in the StablePtr implementation

- - - - -
d7a768a4 by Matthew Pickering at 2023-04-14T04:18:28-04:00
docs: Generate docs/index.html with version number

* Generate docs/index.html to include the version of the ghc library

* This also fixes the packageVersions interpolations which were
  - Missing an interpolation for `LIBRARY_ghc_VERSION`
  - Double quoting the version so that "9.7" was being inserted.

Fixes #23121

- - - - -
d48fbfea by Simon Peyton Jones at 2023-04-14T04:19:05-04:00
Stop if type constructors have kind errors

Otherwise we get knock-on errors, such as #23252.

This makes GHC fail a bit sooner, and I have not attempted to add
recovery code, to add a fake TyCon place of the erroneous one,
in an attempt to get more type errors in one pass.  We could
do that (perhaps) if there was a call for it.

- - - - -
2371d6b2 by Simon Peyton Jones at 2023-04-14T20:01:02+02:00
Major refactor in the handling of equality constraints

This MR substantially refactors the way in which the constraint
solver deals with equality constraints.  The big thing is:

* Intead of a pipeline in which we /first/ canonicalise and /then/
  interact (the latter including performing unification) the two steps
  are more closely integreated into one.  That avoids the current
  rather indirect communication between the two steps.

The proximate cause for this refactoring is fixing #22194, which involve
solving   [W] alpha[2] ~ Maybe (F beta[4])
by doing this:
          alpha[2] := Maybe delta[2]
          [W] delta[2] ~ F beta[4]
That is, we don't promote beta[4]!  This is very like introducing a cycle
breaker, and was very awkward to do before, but now it is all nice.
See GHC.Tc.Utils.Unify Note [Promotion and level-checking] and
Note [Family applications in canonical constraints].

The big change is this:

* Several canonicalisation checks (occurs-check, cycle-breaking,
  checking for concreteness) are combined into one new function:
     GHC.Tc.Utils.Unify.checkTyEqRhs

  This function is controlled by `TyEqFlags`, which says what to do
  for foralls, type families etc.

* `canEqCanLHSFinish` now sees if unification is possible, and if so,
  actually does it: see `canEqCanLHSFinish_try_unification`.

There are loads of smaller changes:

* The on-the-fly unifier `GHC.Tc.Utils.Unify.unifyType` has a
  cheap-and-cheerful version of `checkTyEqRhs`, called
  `simpleUnifyCheck`.  If `simpleUnifyCheck` succeeds, it can unify,
  otherwise it defers by emitting a constraint. This is simpler than
  before.

* I simplified the swapping code in `GHC.Tc.Solver.Equality.canEqCanLHS`.
  Especially the nasty stuff involving `swap_for_occurs` and
  `canEqTyVarFunEq`.  Much nicer now.  See
      Note [Orienting TyVarLHS/TyFamLHS]
      Note [Orienting TyFamLHS/TyFamLHS]

* Added `cteSkolemOccurs`, `cteConcrete`, and `cteCoercionHole` to the
  problems that can be discovered by `checkTyEqRhs`.

* I fixed #23199 `pickQuantifiablePreds`, which actually allows GHC to
  to accept both cases in #22194 rather than rejecting both.

Yet smaller:

* Added a `synIsConcrete` flag to `SynonymTyCon` (alongside `synIsFamFree`)
  to reduce the need for synonym expansion when checking concreteness.
  Use it in `isConcreteType`.

* Renamed `isConcrete` to `isConcreteType`

* Defined `GHC.Core.TyCo.FVs.isInjectiveInType` as a more efficient
  way to find if a particular type variable is used injectively than
  finding all the injective variables.  It is called in
  `GHC.Tc.Utils.Unify.definitely_poly`, which in turn is used quite a
  lot.

* Moved `rewriterView` to `GHC.Core.Type`, so we can use it from the
  constraint solver.

Fixes #22194, #23199

Compile times decrease by an average of 0.1%; but there is a 7.4%
drop in compiler allocation on T15703.

Metric Decrease:
    T15703

- - - - -
99b2734b by Simon Peyton Jones at 2023-04-14T20:01:02+02:00
Add some documentation about redundant constraints

- - - - -
3f2d0eb8 by Simon Peyton Jones at 2023-04-14T20:01:02+02:00
Improve partial signatures

This MR fixes #23223. The changes are in two places:

* GHC.Tc.Bind.checkMonomorphismRestriction
  See the new `Note [When the MR applies]`
  We now no longer stupidly attempt to apply the MR when the user
  specifies a context, e.g.   f :: Eq a => _ -> _

* GHC.Tc.Solver.decideQuantification
  See rewritten `Note [Constraints in partial type signatures]`

Fixing this bug apparently breaks three tests:

* partial-sigs/should_compile/T11192
* partial-sigs/should_fail/Defaulting1MROff
* partial-sigs/should_fail/T11122

However they are all symptoms of #23232, so I'm marking them as
expect_broken(23232).

I feel happy about this MR. Nice.

- - - - -
23e2a8a0 by Simon Peyton Jones at 2023-04-14T20:01:02+02:00
Make approximateWC a bit cleverer

This MR fixes #23224: making approximateWC more clever

See the long `Note [ApproximateWC]` in GHC.Tc.Solver

All this is delicate and ad-hoc -- but it /has/ to be: we are
talking about inferring a type for a binding in the presence of
GADTs, type families and whatnot: known difficult territory.
We just try as hard as we can.

- - - - -
d6fd7f46 by Matthew Pickering at 2023-04-14T20:26:30-04:00
docs: Update template-haskell docs to use Code Q a rather than Q (TExp a)

Since GHC Proposal #195, the type of [|| ... ||] has been Code Q a
rather than Q (TExp a). The documentation in the `template-haskell`
library wasn't updated to reflect this change.

Fixes #23148

- - - - -


18 changed files:

- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/TyCo/FVs.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Type.hs-boot
- compiler/GHC/Data/Bag.hs
- compiler/GHC/Data/Maybe.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Tc/Errors.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Gen/Bind.hs
- compiler/GHC/Tc/Gen/Sig.hs
- compiler/GHC/Tc/Solver.hs
- compiler/GHC/Tc/Solver/Equality.hs
- compiler/GHC/Tc/Solver/InertSet.hs
- compiler/GHC/Tc/Solver/Monad.hs
- compiler/GHC/Tc/TyCl.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/7a1b9b016a86a5a31b9c01e29060973c348fab07...d6fd7f46f92337c4a48062d0890d617ca06b3c32

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/7a1b9b016a86a5a31b9c01e29060973c348fab07...d6fd7f46f92337c4a48062d0890d617ca06b3c32
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/20230414/21194662/attachment-0001.html>

More information about the ghc-commits mailing list