GitLab

1. The offset was a full word, but it should actually be a 32-bit
offset on 64-bit platforms.
2. The con_desc string was allocated separately, which meant that it
might be out of range for a 32-bit offset.

These bugs meant that +RTS -Di (interpreter debugging) would sometimes
crash on 64-bit.

This is introduced in aa479953
and would cause indeterministic testsuite failures in `sigof02dmt`

Niklas Hambüchen suggested that we add the dual of `subsequences`,
isSubsequenceOf (like `isPrefixOf` to `inits` & `isSuffixOf` to `tails`).
It was a simple and noncontroversial proposal which passed unanimously.

For more details see the original proposal discussion at
https://www.haskell.org/pipermail/libraries/2014-November/024063.html

Differential Revision: https://phabricator.haskell.org/D435Signed-off-by: Alexander Berntsen <alexander@plaimi.net>

This mostly cleans up irregularities introduced in
68255588 (re D352) as well as making
sure Haddock is able to resolve all references.

New `Foldable` methods accidentally had `Foldable` contexts, which led
to type roles being assigned incorrectly and preventing GND from
deriving `Foldable` instances. Removing those fixes #9761.

Moreover, this patch takes advantage of this fix by deriving
`Foldable` (and `Eq`) for `UniqFM`.

Differential Revision: https://phabricator.haskell.org/D425

This disables T3064 temporarily as it puts a strain on buildbots
during validation exhausting all available memory.

Plus adding comments.

The most substantive change is that PendingTcSplice becomes a proper
data type rather than a pair; and PendingRnSplice uses it

Those manual descriptions in Haddock strings have become redundant since
Haddock gained the ability to print the minimal complete definition as
specified via `{-# MINIMAL #-}` annotation (or otherwise inferred by
GHC).

Moreover, this commit moves all `{-# MINIMAL #-}` annotations in `base`
to the start of the respective `class` definitions, as this is more
readable and matches more closely the way Haddock renders that
information.

The driving change is this:

* The canonical CFunEqCan constraints now have the form
       [G] F xis ~ fsk
       [W] F xis ~ fmv
  where fsk is a flatten-skolem, and fmv is a flatten-meta-variable
  Think of them as the name of the type-function application

See Note [The flattening story] in TcFlatten.  A flatten-meta-variable
is distinguishable by its MetaInfo of FlatMetaTv

This in turn led to an enormous cascade of other changes, which simplify
and modularise the constraint solver.  In particular:

* Basic data types
    * I got rid of inert_solved_funeqs altogether. It serves no useful
      role that inert_flat_cache does not solve.

    * I added wl_implics to the WorkList, as a convenient place to
      accumulate newly-emitted implications; see Note [Residual
      implications] in TcSMonad.

    * I eliminated tcs_ty_binds altogether. These were the bindings
      for unification variables that we have now solved by
      unification.  We kept them in a finite map and did the
      side-effecting unification later.  But in cannonicalisation we
      had to look up in the side-effected mutable tyvars anyway, so
      nothing was being gained.

      Our original idea was that the solver would be pure, and would
      be a no-op if you discarded its results, but this was already
      not-true for implications since we update their evidence
      bindings in an imperative way.  So rather than the uneasy
      compromise, it's now clearly imperative!

* I split out the flatten/unflatten code into a new module, TcFlatten

* I simplified and articulated explicitly the (rather hazy) invariants
  for the inert substitution inert_eqs.  See Note [eqCanRewrite] and
  See Note [Applying the inert substitution] in TcFlatten

* Unflattening is now done (by TcFlatten.unflatten) after solveFlats,
  before solving nested implications.  This turned out to simplify a
  lot of code. Previously, unflattening was done as part of zonking, at
  the very very end.

    * Eager unflattening allowed me to remove the unpleasant ic_fsks
      field of an Implication (hurrah)

    * Eager unflattening made the TcSimplify.floatEqualities function
      much simpler (just float equalities looking like a ~ ty, where a
      is an untouchable meta-tyvar).

    * Likewise the idea of "pushing wanteds in as givens" could be
      completely eliminated.

* I radically simplified the code that determines when there are
  'given' equalities, and hence whether we can float 'wanted' equalies
  out.  See TcSMonad.getNoGivenEqs, and Note [When does an implication
  have given equalities?].

  This allowed me to get rid of the unpleasant inert_no_eqs flag in InertCans.

* As part of this given-equality stuff, I fixed Trac #9211. See Note
  [Let-bound skolems] in TcSMonad

* Orientation of tyvar/tyvar equalities (a ~ b) was partly done during
  canonicalisation, but then repeated in the spontaneous-solve stage
  (trySpontaneousSolveTwoWay). Now it is done exclusively during
  canonicalisation, which keeps all the code in one place.  See
  Note [Canonical orientation for tyvar/tyvar equality constraints]
  in TcCanonical

This is a deliberate choice, to simplify code, invariants, and I think
performance in typical cases.  The "loopy givens" case is situations like

   [G]  a ~ TF (a, Int)

where TF is a type function with TF (a,b) = (TF a, TF b).

See Note [An alternative story for the inert substitution] in TcFlatten.

There were two unrelated functions, and the `-ddump-rule-firings` output
was coming in a non-deterministic order as a result. So now there is just
one function.

We were falling into an infinite loop when doing the ambiguity
check on a class method, even though we had previously detected
a superclass cycle.  There was code to deal with this, but it
wasn't right.

This just simplifies the error message in cases where there are no useful
equalities in the context

that binds a variable mentioned in the wanted

There is really no point in reporting ones further out; they can't be useful

With the new constraint solver, we don't guarantee to fully-normalise
all constraints (if doing so is not necessary to solve them). So we
may end up with an inferred type like
      f :: [F Int] -> Bool
which could be simplifed to
      f :: [Char] -> Bool
if there is a suitable family instance declaration.  This patch
does this normalisation, in TcBinds.mkExport

Previously we could get constraints in which the untouchables-level did not
strictly increase, which is one of the main invariants!

This patch also simplifies and modularises the tricky case of generalising
an inferred let-binding

Previously the univerally-quantified variables of the DFun were also (bizarrely)
used as the lexically-scoped variables of the instance declaration.  So, for example,
the DFun's type could not be alpha-renamed.  This was an odd restriction, which has
bitten me several times.

This patch does the Right Thing, by adding an ib_tyvars field to the
InstBindings record, which captures the lexically scoped variables.
Easy, robust, nice.  (I think this record probably didn't exist originally,
hence the hack.)

This makes newClsInst (was mkInstance) look more like newFamInst, and simplifies
the plumbing of the overlap flag, and ensures that freshening (required by
the InstEnv stuff) happens in one place.

On the way I also tided up the rather ragged family of tcInstSkolTyVars and
friends.  The result at least has more uniform naming.

This change is just for naming uniformity with the existing downgradeRole