GitLab

Several things here:

* Re-implement piResultTys so that its substitution has
  the correct in-scope set

  That means paying close attention to performance, since as we
  discovered in Trac #11371, it's a heavily used function and
  is often used on ordinary function types, with no foralls to
  worry about substituting.

* Kill off applyTys, which was just the same as piResultTys.

* Re-engineer MkCore.mkCoreApps so that it calls piResultTys,
  rather than repeatedly calling piResultTy.

No change in functionality here, but greater clarity:

* In FamInstEnv.FlattenEnv, kill off the fi_in_scope field
  We are already maintaining an in-scope set in the fe_subst field,
  so it's silly do to it twice.

  (This isn't strictly connected to the rest of this patch, but
  the nomenclature changes below affect the same code, so I put
  them together.)

* TyCoRep.extendTCVSubst used to take a TyVar or a CoVar and work
  out what to do, but in fact we almost always know which of the
  two we are doing.  So:
    - define extendTvSubst, extendCvSubst
    - and use them

* Similar renamings in TyCoRep:
   - extendTCvSubstList        -->   extendTvSubstList
   - extendTCvSubstBinder      -->   extendTvSubstBinder
   - extendTCvSubstAndInScope  --> extendTvSubstAndInScope

* Add Type.extendTvSubstWithClone, extendCvSubstWithClone

* Similar nomenclature changes in Subst, SimplEnv, Specialise

* Kill off TyCoRep.substTelescope (never used)

When implementing Strict Haskell, the patch 46a03fbe didn't faithfully
implement the semantics given in the manual. In particular there was
an ad-hoc case in mkSelectorBinds for "strict and no binders" that
didn't work.

This patch fixes it, curing Trac #11572.

Howver it forced me to think about banged let-bindings, and I rather
think we do not have quite the right semantics yet, so I've opened
Trac #11601.

RyanGlScott updated the Diff only after I had merged it.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #11590

Currently, `-XDeriveFoldable` and `-XDeriveTraversable` generate
unnecessary `mempty` and `pure` expressions when it traverses of an
argument of a constructor whose type does not mention the last type
parameter. Not only is this inefficient, but it prevents `Traversable`
from being derivable for datatypes with unlifted arguments (see
Trac #11174).

The solution to this problem is to adopt a slight change to the
algorithms for `-XDeriveFoldable` and `-XDeriveTraversable`, which is
described in [this wiki
page](https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DeriveFu
nctor#Proposal:alternativestrategyforderivingFoldableandTraversable).
The wiki page also describes why we don't apply the same changes to the
algorithm for `-XDeriveFunctor`.

This is techincally a breaking change for users of `-XDeriveFoldable`
and `-XDeriveTraversable`, since if someone was using a law-breaking
`Monoid` instance with a derived `Foldable` instance (i.e., one where `x
<> mempty` does not equal `x`) or a law-breaking `Applicative` instance
with a derived `Traversable` instance, then the new generated code could
result in different behavior. I suspect the number of scenarios like
this is very small, and the onus really should be on those users to fix
up their `Monoid`/`Applicative` instances.

Fixes #11174.

Test Plan: ./validate

Reviewers: hvr, simonpj, austin, bgamari

Reviewed By: simonpj, bgamari

Subscribers: thomie

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

GHC Trac Issues: #11174

The Eq and Ord instance were previously hand-written and this change
updates them to be automatically derived by the compiler.  The derived
behavior should be equivalent to the original.

Reviewers: hvr, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

Previously, we looked through synonyms when counting arguments,
but that's a bit silly.

We have to instantiate any invisible arguments to type families
right away. This is now done in tcTyCon in TcHsType.

testcase: typecheck/should_compile/T11246

When renaming a type, now looks for wildcards in bound variables'
kinds.

testcase: dependent/should_compile/T11241

This addresses point (2) from #11513.

Related to the fix to Trac #9611

I discussed it with Richard, but this version is much
simmpler and more efficient.

Since we're not consisently keeping track of which tests should pass
with which compiler versions, there is no point in keeping these
functions.

Update submodules containers, hpc and stm.

We just return an arbitrary value since we are destined to fail due to
the error anyways.

Fixes #11580.

Test Plan: Needs to be tested

Reviewers: austin

Subscribers: thomie

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

GHC Trac Issues: #11580

This flag was supposed to be removed in 7.10. This finally resolves
Trac #8022.

Test Plan: Read it

Reviewers: austin

Reviewed By: austin

Subscribers: thomie

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

GHC Trac Issues: #8022

See Trac #9611. In "No instance..." error message we suggest instances
for other types with the same occ name. It is usefull e.g. when we have
two different versions of the same package installed.

Test Plan: typecheck/should_fail/tcfail224

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #9611

Reviewers: bgamari, austin

Reviewed By: austin

Subscribers: thomie

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

On Linux assign F5 and F6 and D3 through D6 to caller-saved registers.

Fixes #11273

Test Plan: validate on powerpc (I validated on powerpc64)

Reviewers: bgamari, erikd, austin

Reviewed By: erikd, austin

Subscribers: thomie

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

GHC Trac Issues: #11273

Replace `NoDataKinds :: PromotionErr` by `NoDataKindsTC` and
`NoDataKindsDC` (just like there is `NoTypeInTypeTC` and
`NoTypeInTypeDC`). This allows for a correct error message when a kind
signature contains a type constructor and `-XDataKinds` is not
specified.

Apply a small fix to `TcError.hs` where instead of "data constructor" we
should say "pattern synonym".

Reviewers: austin, goldfire, bgamari

Reviewed By: bgamari

Subscribers: goldfire, thomie

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

There is ambiguty between (1) type constructors and (2) data
constructors in export lists, e.g. '%%' can stand for both of them. This
ambiguity is resolved in favor of (2).

If the exported data constructor is not in scope, but type constructor
with the same name is in scope, GHC should suggest adding 'type' keyword
to resolve ambiguity in favor of (1) and enabling 'TypeOperators'
extension.

The patch only extends the error message.

See Trac #11432.

Test Plan: `make test`

Reviewers: simonpj, bgamari, austin

Reviewed By: simonpj

Subscribers: mpickering, thomie, goldfire, kosmikus

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

GHC Trac Issues: #11432

Starting with GHC 8.0 we rely on GHC's native cabal macro generation.

As a side-effect, this limits the packages in scope when compiling
`ghc-cabal` for all bootstrapping GHCs.

Reviewers: ezyang, austin, thomie, bgamari

Reviewed By: thomie, bgamari

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

GHC Trac Issues: #11413

Update submodules stm, hpc and unix.

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

`-dunique-increment` doesn't work inside the file.

Test Plan: I've discovered it doesn't work in D1917.

Reviewers: simonpj, bgamari, austin

Subscribers: thomie, simonmar

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

GHC Trac Issues: #11361

This reproduces the issue that I encountered in #11362.

Test Plan: this testcase

Reviewers: simonpj, bgamari, austin

Reviewed By: simonpj

Subscribers: thomie, simonmar

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

GHC Trac Issues: #11362

This bug was revealed by Trac #11362.  It turns out that in my patch
for Trac #11148 (namely 1160dc51), I failed to turn one occurrence of
tvs' into full_tvs.  Sigh.  This is tricky stuff and it cost me
several hours to page it back in and figure out what was happening.

The result was a CoAxiom whose lhs had rhs had different kinds.  Eeek!

Anyway it's fixed.

I also added an ASSERT, in FamInst.newFamInst, that trips on such
bogus CoAxioms.

TcErrors has a system for suppressing some type errors if a more
serious one occurs.  But there was a crucial missing case, which
sometimes resulted in a cascade of irrelevant errors overwhelming
the actual cause. This was Trac #11541.

The fix is simple.  Worth merging to 8.0