GitLab

This change makes the matchable-given check apply uniformly to
     - constraint tuples
     - natural numbers
     - Typeable
as well as to vanilla class constraints.

See Note [Instance and Given overlap] in TcInteract

Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
    class (c1, c2) => (c2, c2)

This change was provoked by

  #10359  inability to re-use a given tuple
          constraint as a whole

  #9858   confusion between term tuples
          and constraint tuples

but it's generally a very nice simplification. We get rid of
 -  In Type, the TuplePred constructor of PredTree,
    and all the code that dealt with TuplePreds
 -  In TcEvidence, the constructors EvTupleMk, EvTupleSel

See Note [How tuples work] in TysWiredIn.

Of course, nothing is ever entirely simple. This one
proved quite fiddly.

- I did quite a bit of renaming, which makes this patch
  touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.

- I made constraint tuples known-key rather than wired-in.
  This is different to boxed/unboxed tuples, but it proved
  awkward to have all the superclass selectors wired-in.
  Easier just to use the standard mechanims.

- While I was fiddling with known-key names, I split the TH Name
  definitions out of DsMeta into a new module THNames.  That meant
  that the known-key names can all be gathered in PrelInfo, without
  causing module loops.

- I found that the parser was parsing an import item like
      T( .. )
  as a *data constructor* T, and then using setRdrNameSpace to
  fix it.  Stupid!  So I changed the parser to parse a *type
  constructor* T, which means less use of setRdrNameSpace.

  I also improved setRdrNameSpace to behave better on Exact Names.
  Largely on priciple; I don't think it matters a lot.

- When compiling a data type declaration for a wired-in thing like
  tuples (,), or lists, we don't really need to look at the
  declaration.  We have the wired-in thing!  And not doing so avoids
  having to line up the uniques for data constructor workers etc.
  See Note [Declarations for wired-in things]

- I found that FunDeps.oclose wasn't taking superclasses into
  account; easily fixed.

- Some error message refactoring for invalid constraints in TcValidity

- Haddock needs to absorb the change too; so there is a submodule update

Previously, the hash function used to cut down the number of block
comparisons did not take local registers into account, causing far too
many similar, but different bocks to be considered candidates for the
(expensive!) comparision.

Adding register to the hash takes CmmCommonBlockElim's share of the
runtime of the example in #10397 from 17% to 2.5%, and eliminates all
unwanted hash collisions.

This patch also replaces the fancy trie by a plain Data.Map. It turned
out to be not performance critical, so this simplifies the code.

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

When working on #10397, I noticed that "reorder" in
nativeCodeGen/seqBlocks took more than 60% of the time. With this
refactoring, it does not even show up in the profile any more. This
fixes #10422.

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

This is an attempt to improve the situation described in #10397, where
the linear scan of possible candidates for commoning up is far too
expensive. There is (ever) more room for improvement, but this is a
start.

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

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Do not check dir perms when .ghci doesn't exist, otherwise GHCi will
print some confusing and useless warnings in some cases (e.g. in travis).
This will fix test T8333 and T10408A in travis.

T10408A will be a test case to cover this. And T8333 is changed to be
not affected by this.

Test Plan:
  chmod o+w ~/.ghc
  make TESTS="T8333 T10408A T10408B"
  chmod o-w ~/.ghc

Reviewers: austin, nomeata

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

This reverts multiple commits from Simon:

  - 04a484ea Test Trac #10359
  - a9ccd37a Test Trac #10403
  - c0aae6f6 Test Trac #10248
  - eb6ca851 Make the "matchable-given" check happen first
  - ca173aa3 Add a case to checkValidTyCon
  - 51cbad15 Update haddock submodule
  - 6e1174da Separate transCloVarSet from fixVarSet
  - a8493e03 Fix imports in HscMain (stage2)
  - a154944b Two wibbles to fix the build
  - 5910a1bc Change in capitalisation of error msg
  - 130e93aa Refactor tuple constraints
  - 8da785d5 Delete commented-out line

These break the build by causing Haddock to fail mysteriously when
trying to examine GHC.Prim it seems.

This change makes the matchable-given check apply uniformly to
     - constraint tuples
     - natural numbers
     - Typeable
as well as to vanilla class constraints.

See Note [Instance and Given overlap] in TcInteract

Apparently when Haddock'ing, we check GHC.Prim.
So checkValidTyCon must not crash when dealing with
PrimTyCons; and it was doing so in dataConStupidTheta.

The fix is easy, but I'm puzzled about why Haddock needs to
typecheck GHC.Prim.

The location of setRdrNameSpace has changed in GHC.

(Sadly, the build still fails with a tyConStupidTheta failure in
a haddock invocation; I have no idea why.  But at least Haddock
itself builds.)

I wasn't clear about the distinction before, and that led to a bug
when I refactored FunDeps.oclose to use transCloVarSet; it should
use fixVarSet.

...following the constraint-tuple patch.

* There was interaction with the recent Safe Haskell change
* Haddock comoplained about constraint tuples defined but not used

  -outofmem.exe: Out of memory
  +outofmem.exe: out of memory

Make tuple constraints be handled by a perfectly ordinary
type class, with the component constraints being the
superclasses:
    class (c1, c2) => (c2, c2)

This change was provoked by

  #10359  inability to re-use a given tuple
          constraint as a whole

  #9858   confusion between term tuples
          and constraint tuples

but it's generally a very nice simplification. We get rid of
 -  In Type, the TuplePred constructor of PredTree,
    and all the code that dealt with TuplePreds
 -  In TcEvidence, the constructors EvTupleMk, EvTupleSel

See Note [How tuples work] in TysWiredIn.

Of course, nothing is ever entirely simple. This one
proved quite fiddly.

- I did quite a bit of renaming, which makes this patch
  touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.

- I made constraint tuples known-key rather than wired-in.
  This is different to boxed/unboxed tuples, but it proved
  awkward to have all the superclass selectors wired-in.
  Easier just to use the standard mechanims.

- While I was fiddling with known-key names, I split the TH Name
  definitions out of DsMeta into a new module THNames.  That meant
  that the known-key names can all be gathered in PrelInfo, without
  causing module loops.

- I found that the parser was parsing an import item like
      T( .. )
  as a *data constructor* T, and then using setRdrNameSpace to
  fix it.  Stupid!  So I changed the parser to parse a *type
  constructor* T, which means less use of setRdrNameSpace.

  I also improved setRdrNameSpace to behave better on Exact Names.
  Largely on priciple; I don't think it matters a lot.

- When compiling a data type declaration for a wired-in thing like
  tuples (,), or lists, we don't really need to look at the
  declaration.  We have the wired-in thing!  And not doing so avoids
  having to line up the uniques for data constructor workers etc.
  See Note [Declarations for wired-in things]

- I found that FunDeps.oclose wasn't taking superclasses into
  account; easily fixed.

- Some error message refactoring for invalid constraints in TcValidity

This caused print007 to fail, so I guess I botched this more than I
thought. This is a combination of reverting:

  "Fix build breakage from 9736c042", commit f35d621d.
  "compiler: make sure we reject -O + HscInterpreted", commit 9736c042.

Fix fragile tests according to comment 13 of #9579 (by @bherzog)

Done by capturing stderr and replace `xx bytes` with `NUM bytes`
(literal).

Some numbers like `(1 MB)` would still remain, but I think
it's safe to assume the actual difference in bytes (on different
architectures) is too small to have an effect on the rounded megabyte
value.

Test Plan: validate

Reviewers: erikd, austin

Reviewed By: erikd, austin

Subscribers: erikd, bgamari, thomie, bherzog

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

GHC Trac Issues: #9579

Biggest change is to document new overlapping instances behavior. We
also add back in the explanation of GND being restricted, and improve
the docs across the board.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Summary:
There is a problem where harbourmaster builds complain about a bad
boolFormula.stderr

    ghc-api/annotations boolFormula [bad stderr] (normal)

The problem does not occur for a local build on my box

This patch turns off warnings for this test, to get rid of the stderr
issue.

Test Plan: ./validate

Reviewers: hvr, austin

Reviewed By: austin

Subscribers: bgamari, thomie, hvr

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

 * Make `-ghci-script` be executed in the order they are specified;
 * Make `-ignore-dot-ghci` only ignores the default .ghci files but
   still execute the scripts passed by `-ghci-script`.

Reviewed By: simonmar, austin

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

GHC Trac Issues: #10408

Otherwise the test sometimes fails.

The <$> operator is only available in the standard Prelude in
ghc 7.10 and later.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>

Test Plan: build with ghc-7.6

Reviewers: dterei, ezyang, austin

Subscribers: bgamari, thomie

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

GHC Trac Issues: #10407

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate on 7.6

Reviewers: austin, goldfire

Subscribers: bgamari, thomie

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

We do much better now due to the newish per-instance flags. Rather than
mark any module that uses `-XOverlappingInstances`,
`-XIncoherentInstances` or the new `OVERLAP*` pragmas as unsafe, we
regard them all as safe and defer the check until an overlap occurs.

An type-class method call that involves overlapping instances is
considered _unsafe_ when:

1) The most specific instance, Ix, is from a module marked `-XSafe`
2) Ix is an orphan instance or a MPTC
3) At least one instance that Ix overlaps, Iy, is:
   a) from a different module than Ix
   AND
   b) Iy is not marked `OVERLAPPABLE`

This check is only enforced in modules compiled with `-XSafe` or
`-XTrustworthy`.

This fixes Safe Haskell to work with the latest overlapping instance
pragmas, and also brings consistent behavior. Previously, Safe Inferred
modules behaved differently than `-XSafe` modules.

Instances in Safe Inferred modules weren't marked being marked as coming
from a Safe module.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>