GitLab

Now we use Array to store branches. This makes sense because we often
have to do random access (once inference is done). This also vastly
simplifies the awkward BranchList type.

This fixes #10837 and updates submodule utils/haddock.

For details see #6018, Phab:D202 and the wiki page:

https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies

This patch also wires-in Maybe data type and updates haddock submodule.

Test Plan: ./validate

Reviewers: simonpj, goldfire, austin, bgamari

Subscribers: mpickering, bgamari, alanz, thomie, goldfire, simonmar,
             carter

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

GHC Trac Issues: #6018

When doing strictness analysis, we need to look inside products.
To avoid unpacking infinitely, we must be careful about
infinite types.  That in turn is controlled by TyCon.checkRecTc.

For data families like
   data instance T (a,b) = MkT a (T b)
we want to unpack the thing recursively for types like
  T (Int, (Int, (Int, Int)))

This patch elaborates the checkRecTc mechanism in TyCon, to
maintain a *count* of how many times a TyCon has shown up,
rather than just a boolean.

A simple change, and a useful one.  Fixes Trac #10482.

This adds the significant Note [Decomposing equalities] to
TcCanonical, trying to sort out the various cases involved.

The only functional change this commit should make is a different
treatment of data families, which were wrong before (they could
be decomposed at role R, which is wrong).

During this commit, I tested to make sure that CoreLint actually
catches the Core error if the typechecker doesn't.

Test case: typecheck/should_fail/T10285

Whether to re-export the `<$>` non-method operator from `Prelude` wasn't
explicitly covered in the original AMP proposal[1], but it turns out that
not doing so forces most code that makes use of applicatives to import
`Data.Functor` or `Control.Applicative` just to get that operator into
scope.  To this end, it was proposed to add `<$>` to Prelude as well[2].

The down-side is that this increases the amount of redundant-import
warnings triggered, as well as the relatively minor issue of stealing
the `<$>` operator from the default namespace for good (although at this
point `<$>` is supposed to be ubiquitous anyway due to `Applicative`
being implicitly required into the next Haskell Report)

 [1]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal
 [2]: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161

Reviewed By: austin, ekmett

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

This is minor stuff triggered by Trac #10103.

* Fix outdated comments on tcView/coreView (we should really combine
  them with a new name, but I'll leave that slightly-disruptive change
  for now)

* Combine tcExpandTyCon_maybe and coreExpandTyCon_maybe (which were identical)
  into expandSynTyCon_maybe

* A few more comment fixups

Summary: It looks like during .lhs -> .hs switch the comments were not updated. So doing exactly that.

Reviewers: austin, jstolarek, hvr, goldfire

Reviewed By: austin, jstolarek

Subscribers: thomie, goldfire

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

GHC Trac Issues: #9986

Universal coercions allow casting between arbitrary types, so it is a
good idea to keep track where they came from, which now we can do by
using the provenance field in `UnivCo`.

This is also handy for type-checker plugins that provide functionality
beyond what's expressible by GHC's standard coercions:  such plugins
can generate universal coercions, but they should still tag them,
so that if something goes wrong we can link the casts to the plugin.

Summary:
This is a rewrite of the algorithm to solve for Coercible "instances".

A preliminary form of these ideas is at
https://ghc.haskell.org/trac/ghc/wiki/Design/NewCoercibleSolver

The basic idea here is that the `EqPred` constructor of `PredTree`
now is parameterised by a new type `EqRel` (where
`data EqRel = NomEq | ReprEq`). Thus, every equality constraint can
now talk about nominal equality (the usual case) or representational
equality (the `Coercible` case).

This is a change from the previous
behavior where `Coercible` was just considered a regular class with
a special case in `matchClassInst`.

Because of this change, representational equalities are now
canonicalized just like nominal ones, allowing more equalities
to be solved -- in particular, the case at the top of #9117.

A knock-on effect is that the flattener must be aware of the
choice of equality relation, because the inert set now stores
both representational inert equalities alongside the nominal
inert equalities. Of course, we can use representational equalities
to rewrite only within another representational equality --
thus the parameterization of the flattener.

A nice side effect of this change is that I've introduced a new
type `CtFlavour`, which tracks G vs. W vs. D, removing some ugliness
in the flattener.

This commit includes some refactoring as discussed on D546.
It also removes the ability of Deriveds to rewrite Deriveds.

This fixes bugs #9117 and #8984.

Reviewers: simonpj, austin, nomeata

Subscribers: carter, thomie

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

GHC Trac Issues: #9117, #8984

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

This change is just for naming uniformity with the existing downgradeRole

This finally exposes also the methods of these 3 classes in the Prelude
in order to allow to define basic class instances w/o needing imports.

This almost completes the primary goal of #9586

NOTE: `fold`, `foldl'`, `foldr'`, and `toList` are not exposed yet,
      as they require upstream fixes for at least `containers` and
      `bytestring`, and are not required for defining basic instances.

Reviewed By: ekmett, austin

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

This patch fixes Trac #9580, in which the Coercible machinery succeeded
even though the relevant data constructor was not in scope.

As usual I got dragged into a raft of refactoring changes,
all for the better.

* Delete TcEvidence.coercionToTcCoercion (now unused)

* Move instNewTyConTF_maybe, instNewTyCon_maybe to FamInst,
  and rename them to tcInstNewTyConTF_maybe, tcInstNewTyCon
  (They both return TcCoercions.)

* tcInstNewTyConTF_maybe also gets more convenient type,
  which improves TcInteract.getCoercibleInst

* Define FamInst.tcLookupDataFamInst, and use it in TcDeriv,
  (as well as in tcInstNewTyConTF_maybe)

* Improve error report for Coercible errors, when data familes
  are involved  Another use of tcLookupDataFamInst

* In TcExpr.tcTagToEnum, use tcLookupDataFamInst to replace
  local hacky code

* Fix Coercion.instNewTyCon_maybe and Type.newTyConInstRhs to deal
  with eta-reduced newtypes, using
  (new) Type.unwrapNewTyConEtad_maybe and (new) Type.applyTysX

Some small refactoring of TcSMonad.matchFam.

Call sites are much easier to understand than before

Haddock complains if a comment looks like a misplaced Haddock-comment.
In this case, the comment line starting with `-- *kind* and` looked like a
section-heading to Haddock and caused the following error:

    parse error on input ‘-- *kind* and role of its argument. Luckily, laziness should’

This commit just rewraps the line so that no `*` appear at the start of the
non-Haddock comment lines.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

Summary:
coercionRole is now much more efficient, computing both the coercion's
kind and role together. The previous version calculated them separately,
leading to quite possibly exponential behavior.

This is still too slow, but it's a big improvement.

Test Plan: Evaluate by running the "minimized" test from the Trac ticket.

Reviewers: simonpj, austin

Subscribers: simonmar, relrod, carter

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

In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
reorganized, while following the convention, to

- place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
  any `{-# OPTIONS_GHC #-}`-lines.

- Moreover, if the list of language extensions fit into a single
  `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
  line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
  individual language extension. In both cases, try to keep the
  enumeration alphabetically ordered.
  (The latter layout is preferable as it's more diff-friendly)

While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
occurences by `{-# OPTIONS_GHC ... #-}` pragmas.

mkAppCoFlexible was breaking the invariant that the head of a TyConAppCo cannot
be a type synonym.  This small patch fixes it.

This patch implements a simpler, and nicer, desugaring for
lazy pattern matching, fixing Trac #9098

See TypeRep.pprUserForAll.  This just makes forall-printing a bit more
consistent.  In particular, I wasn't seeing the kind foralls when
displaying a CoAxiom or CoAxBranch

The output on T7939 is just possible a bit too verbose now, but even if so
that's an error in the right direction.

This commit also makes better names for several of these functions,
and removes one that went unused.

This is the result of an email conversation (off list) with
Conal Elliott, who needed a stronger unSubCo_maybe. This
commit adds cases to upgrade the role of a coercion when
recursion is necessary to do say (for example, for a use of
TransCo). As a side effect, more coercion optimizations are
now possible.

This was not done previously because unSubCo_maybe was used
only during coercion optimization, and the recursive cases
looked to be unlikely. However, adding them can cause no harm.

unSubCo_maybe is now also exported from Coercion, for use
cases like Conal's.

by passing the FamInstEnvs all the way down. This closes #7619.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Previously, TcCoercion were only used to represent boxed Nominal
coercions. In order to also talk about boxed Representational coercions
in the type checker, we add Roles to TcCoercion. Again, we closely
mirror Coercion.

The roles are verified by a few assertions, and at the latest after
conversion to Coercion. I have put my trust in the comprehensiveness of
the testsuite here, but any role error after desugaring popping up now
might be caused by this refactoring.

A bit of a mess had accumulated, with unclear invariants.

* Remove splitNewTypeRepCo_maybe, in favour of topNormaliseNewType_maybe
  (which had the same signature but behaved subtly differently).

* Make topNormaliseNewType_maybe guaranteed to return a non-newtype
  if it says (Just ty).  This is what was causing the loop in #8467

* Apply similar tidying up to FamInstEnv.topNormaliseType

Now, instead of looking at a class's roles, the GND check looks
at all of the methods in the class individually. This has the
advantage that sometimes, we can use information about the
derivation requested during the safety check. For example,
we can now derive (IArray UArray), whereas the previous check
prevented this.

This fixes bugs #8185, #8234, and #8246. The new syntax is explained
in the comments to #8185, appears in the "Roles" subsection of the
manual, and on the [wiki:Roles] wiki page.

This change also removes the ability for a role annotation on type
synonyms, as noted in #8234.