sheaf authored 1 year ago and Marge Bot committed 1 year ago

This extra bit of information was accidentally being discarded after
a refactoring of the way we reported problems when unifying a type
variable with another type. This patch rectifies that.

Simon Peyton Jones authored 2 years ago and Krzysztof Gogolewski committed 1 year ago

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

jeffrey young authored 2 years ago and Marge Bot committed 2 years ago

This MR runs the testsuite for the JS backend. Note that this is a
temporary solution until !9515 is merged.

Key point: The CI runs hadrian on the built cross compiler _but not_ on
the bindist.

Other Highlights:

 - stm submodule gets a bump to mark tests as broken
 - several tests are marked as broken or are fixed by adding more
 - conditions to their test runner instance.

List of working commit messages:

CI: test cross target _and_ emulator

CI: JS: Try run testsuite with hadrian

JS.CI: cleanup and simplify hadrian invocation

use single bracket, print info

JS CI: remove call to test_compiler from hadrian

don't build haddock

JS: mark more tests as broken

Tracked in #22576

JS testsuite: don't skip sum_mod test

Its expected to fail, yet we skipped it which automatically makes it
succeed leading to an unexpected success,

JS testsuite: don't mark T12035j as skip

leads to an unexpected pass

JS testsuite: remove broken on T14075

leads to unexpected pass

JS testsuite: mark more tests as broken

JS testsuite: mark T11760 in base as broken

JS testsuite: mark ManyUnbSums broken

submodules: bump process and hpc for JS tests

Both submodules has needed tests skipped or marked broken for th JS
backend. This commit now adds these changes to GHC.

See:

HPC: hpc/hpc!21

Process: https://github.com/haskell/process/pull/268

remove js_broken on now passing tests

separate wasm and js backend ci

test: T11760: add threaded, non-moving only_ways

test: T10296a add req_c

T13894: skip for JS backend

tests: jspace, T22333: mark as js_broken(22573)

test: T22513i mark as req_th

stm submodule: mark stm055, T16707 broken for JS

tests: js_broken(22374) on unpack_sums_6, T12010

dont run diff on JS CI, cleanup

fixup: More CI cleanup

fix: align text to master

fix: align exceptions submodule to master

CI: Bump DOCKER_REV

Bump to ci-images commit that has a deb11 build with node. Required for
!9552

testsuite: mark T22669 as js_skip

See #22669

This test tests that .o-boot files aren't created when run in using the
interpreter backend. Thus this is not relevant for the JS backend.

testsuite: mark T22671 as broken on JS

See #22835

base.testsuite: mark Chan002 fragile for JS

see #22836

revert: submodule process bump

bump stm submodule

New hash includes skips for the JS backend.

testsuite: mark RnPatternSynonymFail broken on JS

Requires TH:
 - see !9779
 - and #22261

compiler: GHC.hs ifdef import Utils.Panic.Plain

Matthew Pickering authored 2 years ago and Marge Bot committed 2 years ago

This improves the error messages of the exhaustiveness checker when
checking statements which have been moved around with ApplicativeDo.

Before:

Test.hs:2:3: warning: [GHC-62161] [-Wincomplete-uni-patterns]
    Pattern match(es) are non-exhaustive
    In a pattern binding:
        Patterns of type ‘Maybe ()’ not matched: Nothing
  |
2 |   let x = ()
  |   ^^^^^^^^^^

After:

Test.hs:4:3: warning: [GHC-62161] [-Wincomplete-uni-patterns]
    Pattern match(es) are non-exhaustive
    In a pattern binding:
        Patterns of type ‘Maybe ()’ not matched: Nothing
  |
4 |   ~(Just res1) <- seq x (pure $ Nothing @())
  |

Fixes #22483

sheaf authored 2 years ago and Marge Bot committed 2 years ago

The testsuite output now contains diagnostic codes, so many tests need
to be updated at once.
We decided it was best to keep the diagnostic codes in the testsuite
output, so that contributors don't inadvertently make changes to the
diagnostic codes.

Soham Chowdhury authored 2 years ago and Marge Bot committed 2 years ago

This patch improves the uniformity of error message formatting by
printing constraints in quotes, as we do for types.

Fix #21167

Ziyang Liu authored 2 years ago and Marge Bot committed 2 years ago

The following is currently rejected:

```haskell
-- F is an Applicative but not a Monad
x :: F (Int, Int)
x = do
  a <- pure 0
  let b = 1
  pure (a, b)
```

This has bitten me multiple times. This MR contains a simple fix:
only allow a "let only" segment to be merged with the next (and not
the previous) segment. As a result, when the last one or more
statements before pure/return are `LetStmt`s, there will be one
more segment containing only those `LetStmt`s.

Note that if the `let` statement mentions a name bound previously, then
the program is still rejected, for example

```haskell
x = do
  a <- pure 0
  let b = a + 1
  pure (a, b)
```

or the example in #18559. To support this would require a more
complex approach, but this is IME much less common than the
previous case.

Ziyang Liu authored 3 years ago and Marge Bot committed 3 years ago

The doc says that the last statement of an ado-block can be one of
`return E`, `return $ E`, `pure E` and `pure $ E`. But `return`
is not accepted in a few cases such as:

```haskell
-- The ado-block only has one statement
x :: F ()
x = do
  return ()

-- The ado-block only has let-statements besides the `return`
y :: F ()
y = do
  let a = True
  return ()
```

These currently require `Monad` instances. This MR fixes it.
Normally `return` is accepted as the last statement because it is
stripped in constructing an `ApplicativeStmt`, but this cannot be
done in the above cases, so instead we replace `return` by `pure`.

A similar but different issue (when the ado-block contains `BindStmt`
or `BodyStmt`, the second last statement cannot be `LetStmt`, even if
the last statement uses `pure`) is fixed in !6786.

sheaf authored 3 years ago and Marge Bot committed 3 years ago

  When instances overlap, we now include additional information
  about why we weren't able to select an instance: perhaps
  one instance overlapped another but was not strictly more specific,
  so we aren't able to directly choose it.

Fixes #20542

sheaf authored 3 years ago and Marge Bot committed 3 years ago

There were two problems around `mkDictErr`:

  1. An outdated call to `flattenTys` meant that we missed out on some
     instances. As we no longer flatten type-family applications,
     the logic is obsolete and can be removed.

  2. We reported "out of scope" errors in a poly-kinded situation
     because `BoxedRep` and `Lifted` were considered out of scope.
     We fix this by using `pretendNameIsInScope`.

fixes #20465

David Feuer authored 3 years ago and Marge Bot committed 3 years ago

Oleg Grenrus pointed out that `Solo` was missing `Eq`, `Ord`,
`Bounded`, `Enum`, and `Ix` instances, which were all apparently
available for the `OneTuple` type (in the `OneTuple` package).
Though only the first three really seem useful, there's no reason
not to take them all. For `Ix`, `Solo` naturally fills a gap
between `()` and `(,)`.

Matthew Pickering authored 3 years ago and Marge Bot committed 3 years ago

This commit modifies interface files so that *only* direct information
about modules and packages is stored in the interface file.

* Only direct module and direct package dependencies are stored in the
interface files.
* Trusted packages are now stored separately as they need to be checked
  transitively.
* hs-boot files below the compiled module in the home module are stored
  so that eps_is_boot can be calculated in one-shot mode without loading
  all interface files in the home package.
* The transitive closure of signatures is stored separately

This is important for two reasons

* Less recompilation is needed, as motivated by #16885, a lot of
redundant compilation was triggered when adding new imports deep in the
module tree as all the parent interface files had to be redundantly
updated.
* Checking an interface file is cheaper because you don't have to
perform a transitive traversal to check the dependencies are up-to-date.

In the code, places where we would have used the transitive closure, we
instead compute the necessary transitive closure. The closure is not
computed very often, was already happening in checkDependencies, and
was already happening in getLinkDeps.

Fixes #16885

-------------------------
Metric Decrease:
    MultiLayerModules
    T13701
    T13719
-------------------------

Ryan Scott authored 4 years ago and Marge Bot committed 4 years ago

Fixes #18279. Bumps the `text` submodule.

* support detection of slow ghc-bignum backend (to replace the detection
  of integer-simple use). There are still some test cases that the
  native backend doesn't handle efficiently enough.

* remove tests for GMP only functions that have been removed from
  ghc-bignum

* fix test results showing dependent packages (e.g. integer-gmp) or
  showing suggested instances

* fix test using Integer/Natural API or showing internal names

This patch simplifies GHC to use simple subsumption.
  Ticket #17775

Implements GHC proposal #287
   https://github.com/ghc-proposals/ghc-proposals/blob/master/
   proposals/0287-simplify-subsumption.rst

All the motivation is described there; I will not repeat it here.
The implementation payload:
 * tcSubType and friends become noticably simpler, because it no
   longer uses eta-expansion when checking subsumption.
 * No deeplyInstantiate or deeplySkolemise

That in turn means that some tests fail, by design; they can all
be fixed by eta expansion.  There is a list of such changes below.

Implementing the patch led me into a variety of sticky corners, so
the patch includes several othe changes, some quite significant:

* I made String wired-in, so that
    "foo" :: String   rather than
    "foo" :: [Char]
  This improves error messages, and fixes #15679

* The pattern match checker relies on knowing about in-scope equality
  constraints, andd adds them to the desugarer's environment using
  addTyCsDs.  But the co_fn in a FunBind was missed, and for some reason
  simple-subsumption ends up with dictionaries there. So I added a
  call to addTyCsDs.  This is really part of #18049.

* I moved the ic_telescope field out of Implication and into
  ForAllSkol instead.  This is a nice win; just expresses the code
  much better.

* There was a bug in GHC.Tc.TyCl.Instance.tcDataFamInstHeader.
  We called checkDataKindSig inside tc_kind_sig, /before/
  solveEqualities and zonking.  Obviously wrong, easily fixed.

* solveLocalEqualitiesX: there was a whole mess in here, around
  failing fast enough.  I discovered a bad latent bug where we
  could successfully kind-check a type signature, and use it,
  but have unsolved constraints that could fill in coercion
  holes in that signature --  aargh.

  It's all explained in Note [Failure in local type signatures]
  in GHC.Tc.Solver. Much better now.

* I fixed a serious bug in anonymous type holes. IN
    f :: Int -> (forall a. a -> _) -> Int
  that "_" should be a unification variable at the /outer/
  level; it cannot be instantiated to 'a'.  This was plain
  wrong.  New fields mode_lvl and mode_holes in TcTyMode,
  and auxiliary data type GHC.Tc.Gen.HsType.HoleMode.

  This fixes #16292, but makes no progress towards the more
  ambitious #16082

* I got sucked into an enormous refactoring of the reporting of
  equality errors in GHC.Tc.Errors, especially in
      mkEqErr1
      mkTyVarEqErr
      misMatchMsg
      misMatchMsgOrCND
  In particular, the very tricky mkExpectedActualMsg function
  is gone.

  It took me a full day.  But the result is far easier to understand.
  (Still not easy!)  This led to various minor improvements in error
  output, and an enormous number of test-case error wibbles.

  One particular point: for occurs-check errors I now just say
     Can't match 'a' against '[a]'
  rather than using the intimidating language of "occurs check".

* Pretty-printing AbsBinds

Tests review

* Eta expansions
   T11305: one eta expansion
   T12082: one eta expansion (undefined)
   T13585a: one eta expansion
   T3102:  one eta expansion
   T3692:  two eta expansions (tricky)
   T2239:  two eta expansions
   T16473: one eta
   determ004: two eta expansions (undefined)
   annfail06: two eta (undefined)
   T17923: four eta expansions (a strange program indeed!)
   tcrun035: one eta expansion

* Ambiguity check at higher rank.  Now that we have simple
  subsumption, a type like
     f :: (forall a. Eq a => Int) -> Int
  is no longer ambiguous, because we could write
     g :: (forall a. Eq a => Int) -> Int
     g = f
  and it'd typecheck just fine.  But f's type is a bit
  suspicious, and we might want to consider making the
  ambiguity check do a check on each sub-term.  Meanwhile,
  these tests are accepted, whereas they were previously
  rejected as ambiguous:
     T7220a
     T15438
     T10503
     T9222

* Some more interesting error message wibbles
   T13381: Fine: one error (Int ~ Exp Int)
           rather than two (Int ~ Exp Int, Exp Int ~ Int)
   T9834:  Small change in error (improvement)
   T10619: Improved
   T2414:  Small change, due to order of unification, fine
   T2534:  A very simple case in which a change of unification order
           means we get tow unsolved constraints instead of one
   tc211: bizarre impredicative tests; just accept this for now

Updates Cabal and haddock submodules.

Metric Increase:
  T12150
  T12234
  T5837
  haddock.base
Metric Decrease:
  haddock.compiler
  haddock.Cabal
  haddock.base

Merge note: This appears to break the
`UnliftedNewtypesDifficultUnification` test. It has been marked as
broken in the interest of merging.

(cherry picked from commit 66b7b195)

Simon Peyton Jones authored 4 years ago and Marge Bot committed 4 years ago

This patch implements eager instantiation, a small but critical change
to the type inference engine, #17173.  The main change is this:

  When inferring types, always return an instantiated type
  (for now, deeply instantiated; in future shallowly instantiated)

There is more discussion in
https://www.tweag.io/posts/2020-04-02-lazy-eager-instantiation.html

There is quite a bit of refactoring in this patch:

* The ir_inst field of GHC.Tc.Utils.TcType.InferResultk
  has entirely gone.  So tcInferInst and tcInferNoInst have collapsed
  into tcInfer.

* Type inference of applications, via tcInferApp and
  tcInferAppHead, are substantially refactored, preparing
  the way for Quick Look impredicativity.

* New pure function GHC.Tc.Gen.Expr.collectHsArgs and applyHsArgs
  are beatifully dual.  We can see the zipper!

* GHC.Tc.Gen.Expr.tcArgs is now much nicer; no longer needs to return
  a wrapper

* In HsExpr, HsTypeApp now contains the the actual type argument,
  and is used in desugaring, rather than putting it in a mysterious
  wrapper.

* I struggled a bit with good error reporting in
  Unify.matchActualFunTysPart. It's a little bit simpler than before,
  but still not great.

Some smaller things

* Rename tcPolyExpr --> tcCheckExpr
         tcMonoExpr --> tcLExpr
* tcPatSig moves from GHC.Tc.Gen.HsType to GHC.Tc.Gen.Pat

Metric Decrease:
    T9961

Reduction of 1.6% in comiler allocation on T9961, I think.

Josef Svenningsson authored 5 years ago and Ben Gamari committed 5 years ago

A previous fix for #15344 made sure that monadic 'fail' is used properly
when translating ApplicativeDo. However, it didn't properly account
for when a 'fail' will be inserted which resulted in some programs
failing with a type error.

Kirill Elagin authored 5 years ago and Marge Bot committed 5 years ago

* Do not print `join` in ApplictiveStmt, unless ppr-debug
* Print parens around multiple parallel binds

When ApplicativeDo is enabled, the renamer analyses the statements of a
`do` block and in certain cases marks them as needing to be rewritten
using `join`.

For example, if you have:

```
foo = do
  a <- e1
  b <- e2
  doSomething a b
```

it will be desugared into:

```
foo = join (doSomething <$> e1 <*> e2)
```

After renaming but before desugaring the expression is stored
essentially as:

```
foo = do
  [will need join] (a <- e1 | b <- e2)
  [no return] doSomething a b
```

Before this change, the pretty printer would print a call to `join`,
even though it is not needed at this stage at all. The expression will be
actually rewritten into one using join only at desugaring, at which
point a literal call to join will be inserted.

Kirill Elagin authored 5 years ago and Marge Bot committed 5 years ago

After ApplicatveDo strips the last `return` during renaming, the pretty
printer has to restore it. However, if the return was followed by `$`,
the dollar was stripped too and not restored.

For example, the last stamement in:

```
  foo = do
    x <- ...
    ...
    return $ f x
```

would be printed as:

```
    return f x
```

This commit preserved the dolar, so it becomes:

```
    return $ f x
```

We now always show "forall {a}. T" for inferred variables,
previously this was controlled by -fprint-explicit-foralls.

This implements part 1 of https://github.com/ghc-proposals/ghc-proposals/pull/179.

Part of GHC ticket #16320.

Furthermore, when printing a levity restriction error, we now display
the HsWrap of the expression. This lets users see the full elaboration with
-fprint-typechecker-elaboration (see also #17670)

Josef Svenningsson authored 5 years ago and Marge Bot committed 5 years ago

Applicative-do has a bug where it fails to use the monadic fail method
when desugaring patternmatches which can fail. See #15344.

This patch fixes that problem. It required more rewiring than I had expected.
Applicative-do happens mostly in the renamer; that's where decisions about
scheduling are made. This schedule is then carried through the typechecker and
into the desugarer which performs the actual translation. Fixing this bug
required sending information about the fail method from the renamer, through
the type checker and into the desugarer. Previously, the desugarer didn't
have enough information to actually desugar pattern matches correctly.

As a side effect, we also fix #16628, where GHC wouldn't catch missing
MonadFail instances with -XApplicativeDo.

Herbert Valerio Riedel authored 6 years ago and Ben Gamari committed 6 years ago

As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail



Coauthored-by: Ben Gamari <ben@well-typed.com>

Alec Theriault authored 6 years ago and Marge Bot committed 6 years ago

Prevents some tests from failing just due to mismatched version numbers.

These version numbers shouldn't cause tests to fail, especially since
we *expect* them to be regularly incremented. The motivation for this
particular set of changes came from the changes that came along with
the `base` version bump in 8f19ecc9.

This patch makes a number of improvements to the output
generated by -ddump-types

* Prints data constructor separately
* Omits empty chunks of output

I was driven initially by the unhelpful existing output for
data constructors, but ended up doing some refactoring.

Lots of error message wibbles, but nothing significant.
Certainly no change in user behaviour.

(NB: It is just possible that I have failed to cleanly
     separate this patch from the next one, about
     isPredTy and friends.)

Ryan Scott authored 6 years ago and Krzysztof Gogolewski committed 6 years ago

Summary:
Previously, we were using `pprStmtContext` instead, which
led to error messages missing indefinite articles where they were
required.

Test Plan: make test TEST="T13242a T7786 Typeable1"

Reviewers: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15423

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

Add support for built-in Natural literals in Core.

- Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber
  constructor with a LitNumType field
- Support built-in Natural literals
- Add desugar warning for negative literals
- Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency
  reasons

This patch introduces only a few rules for Natural literals (compared
to Integer's rules). Factorization of the built-in rules for numeric
literals will be done in another patch as this one is already big to
review.

Test Plan:
  validate
  test build with integer-simple

Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar

Reviewed By: bgamari

Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton,
thomie

GHC Trac Issues: #14170, #14465

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

Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

unpackClosure#'s behavior and type has changed. This caused a CPP guard
in the new ghc-heap package to fail when bootstrapping with GHC 8.4.

Test Plan: Validate bootstrapping with GHC 8.4

Reviewers: RyanGlScott

Subscribers: rwbarton, thomie, carter

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

Trac #15009 showed that, for Given TyVar/TyVar equalities, we really
want to orient them with the deepest-bound skolem on the left. As it
happens, we also want to do the same for Wanteds, but for a different
reason (more likely to be touchable).  Either way, deepest wins:
see TcUnify Note [Deeper level on the left].

This observation led me to some significant changes:

* A SkolemTv already had a TcLevel, but the level wasn't really being
  used.   Now it is!

* I updated added invariant (SkolInf) to TcType
  Note [TcLevel and untouchable type variables], documenting that
  the level number of all the ic_skols should be the same as the
  ic_tclvl of the implication

* FlatSkolTvs and FlatMetaTvs previously had a dummy level-number of
  zero, which messed the scheme up.   Now they get a level number the
  same way as all other TcTyVars, instead of being a special case.

* To make sure that FlatSkolTvs and FlatMetaTvs are untouchable (which
  was previously done via their magic zero level) isTouchableMetaTyVar
  just tests for those two cases.

* TcUnify.swapOverTyVars is the crucial orientation function; see the
  new Note [TyVar/TyVar orientation].  I completely rewrote this function,
  and it's now much much easier to understand.

I ended up doing some related refactoring, of course

* I noticed that tcImplicitTKBndrsX and tcExplicitTKBndrsX were doing
  a lot of useless work in the case where there are no skolems; I
  added a fast-patch

* Elminate the un-used tcExplicitTKBndrsSig; and thereby get rid of
  the higher-order parameter to tcExpliciTKBndrsX.

* Replace TcHsType.emitTvImplication with TcUnify.checkTvConstraints,
  by analogy with TcUnify.checkConstraints.

* Inline TcUnify.buildImplication into its only call-site in
  TcUnify.checkConstraints

* TcS.buildImplication becomes TcS.CheckConstraintsTcS, with a
  simpler API

* Now that we have NoEvBindsVar we have no need of termEvidenceAllowed;
  nuke the latter, adding Note [No evidence bindings] to TcEvidence.

Sebastian Graf authored 6 years ago and Ben Gamari committed 6 years ago

This is mostly for congruence with 'subWordC#' and '{add,sub}IntC#'.
I found 'plusWord2#' while implementing this, which both lacks
documentation and has a slightly different specification than
'addWordC#', which means the generic implementation is unnecessarily
complex.

While I was at it, I also added lacking meta-information on PrimOps
and refactored 'subWordC#'s generic implementation to be branchless.

Reviewers: bgamari, simonmar, jrtc27, dfeuer

Reviewed By: bgamari, dfeuer

Subscribers: dfeuer, thomie, carter

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

Summary: Bumps several submodules.

Test Plan: ./validate

Reviewers: hvr, bgamari

Reviewed By: bgamari

Subscribers: thomie, carter

GHC Trac Issues: #15018

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

This takes care of bumping the `base` and `integer-gmp`
minor version numbers in anticipation of a GHC 8.4.2 release.

While I was in town, I also filled in a `@since TODO` Haddock
annotation for `powModSecInteger` in `integer-gmp` with
`1.0.2.0`, and updated the changelog accordingly.

Test Plan: ./validate

Reviewers: hvr, goldfire, bgamari

Reviewed By: bgamari

Subscribers: thomie, carter

GHC Trac Issues: #15025

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

Trac #14394 showed that it's possible to get redundant
constraints in the inferred provided constraints of a pattern
synonym.  This patch removes the redundancy with mkMinimalBySCs.

To do this I had to generalise the type of mkMinimalBySCs slightly.
And, to reduce confusing reversal, I made it stable: it now returns
its result in the same order as its input.  That led to a raft of
error message wibbles, mostly for the better.

Summary:
It's simple to treat BodyStmt just like a BindStmt with a wildcard
pattern, which is enough to fix #12143 without going all the way to
using `<*` and `*>` (#10892).

Test Plan:
* new test cases in `ado004.hs`
* validate

Reviewers: niteria, simonpj, bgamari, austin, erikd

Subscribers: rwbarton, thomie

GHC Trac Issues: #12143

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

This is prompted by the addition of `compareByteArrays#` in
e3ba26f8

NOTE: We may switch to synchronise `ghc-prim` with GHC's version at some point

This completes the 2nd phase of the Semigroup=>Monoid Proposal (SMP)
initiated in 8ae263ce.

This updates a couple submodules to address <> naming clashes.

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Bumps numerous submodules.

Reviewers: austin, hvr

Subscribers: rwbarton, thomie

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

The renamer wasn't able to deal with more than a couple strict
patterns in a row with `ApplicativeDo` when using the heuristic
splitter. Update it to work with them properly.

Reviewers: simonmar, austin, bgamari, hvr

Reviewed By: simonmar

Subscribers: RyanGlScott, lippling, rwbarton, thomie

GHC Trac Issues: #14163

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