[Git][ghc/ghc][wip/T22194-flags] 6 commits: rts: Don't rely on EXTERN_INLINE for slop-zeroing logic

Tue Mar 28 17:37:44 UTC 2023

Simon Peyton Jones pushed to branch wip/T22194-flags at Glasgow Haskell Compiler / GHC

Commits:
c6ec4cd1 by Ben Gamari at 2023-03-25T20:23:47-04:00
rts: Don't rely on EXTERN_INLINE for slop-zeroing logic

Previously we relied on calling EXTERN_INLINE functions defined in
ClosureMacros.h from Cmm to zero slop. However, as far as I can tell,
this is no longer safe to do in C99 as EXTERN_INLINE definitions may be emitted
in each compilation unit.

Fix this by explicitly declaring a new set of non-inline functions in
ZeroSlop.c which can be called from Cmm and marking the ClosureMacros.h
definitions as INLINE_HEADER.

In the future we should try to eliminate EXTERN_INLINE.

- - - - -
c32abd4b by Ben Gamari at 2023-03-25T20:23:48-04:00
rts: Fix capability-count check in zeroSlop

Previously `zeroSlop` examined `RtsFlags` to determine whether the
program was single-threaded. This is wrong; a program may be started
with `+RTS -N1` yet the process may later increase the capability count
with `setNumCapabilities`. This lead to quite subtle and rare crashes.

Fixes #23088.

- - - - -
656d4cb3 by Ryan Scott at 2023-03-25T20:24:23-04:00
Add Eq/Ord instances for SSymbol, SChar, and SNat

This implements [CLC proposal #148](https://github.com/haskell/core-libraries-committee/issues/148).

- - - - -
4f93de88 by David Feuer at 2023-03-26T15:33:02-04:00
Update and expand atomic modification Haddocks

* The documentation for `atomicModifyIORef` and `atomicModifyIORef'`
  were incomplete, and the documentation for `atomicModifyIORef` was
  out of date. Update and expand.

* Remove a useless lazy pattern match in the definition of
  `atomicModifyIORef`. The pair it claims to match lazily
  was already forced by `atomicModifyIORef2`.

- - - - -
e1fb56b2 by David Feuer at 2023-03-26T15:33:41-04:00
Document the constructor name for lists

Derived `Data` instances use raw infix constructor names when applicable.
The `Data.Data [a]` instance, if derived, would have a constructor name
of `":"`. However, it actually uses constructor name `"(:)"`. Document this
peculiarity.

See https://github.com/haskell/core-libraries-committee/issues/147

- - - - -
f5ee03fb by Simon Peyton Jones at 2023-03-28T14:47:46+01: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`.

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

- - - - -

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/Tc/Errors.hs
- compiler/GHC/Tc/Errors/Ppr.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/Types/Constraint.hs
- compiler/GHC/Tc/Utils/Concrete.hs
- compiler/GHC/Tc/Utils/TcMType.hs
- compiler/GHC/Tc/Utils/TcType.hs

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b1c87de83cfbff51557e7d544f78cfe71f7e812f...f5ee03fbf03dba720bf67cfc87bac1c73839d4c5

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b1c87de83cfbff51557e7d544f78cfe71f7e812f...f5ee03fbf03dba720bf67cfc87bac1c73839d4c5
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/20230328/6c729980/attachment.html>