GitLab

The stderr output is

```
Loading with T9693_initial.hs

T9693_main.hs:4:1:
    Same exact name in multiple name-spaces:
      type constructor or class ‘X’, declared at: T9693_main.hs:4:1
      data constructor ‘X’, declared at: T9693_main.hs:4:1
      Probable cause: you bound a unique Template Haskell name (NameU),
      perhaps via newName, in different name-spaces.
      If that's it, then -ddump-splices might be useful
Reloading with T9693_modified.hs

T9693_main.hs:1:1:
    Data constructor ‘X’ used as a type constructor
```

The strange thing is that the modified version uses (mkName "X"), which should
be fine for simultaneous use in both a data constructor and type constructor.
Indeed, on a fresh load, the modified version works fine. So there is some sort
of state left over from the prior load when (newName "X") was used.

Test Plan: testsuite/tests/th/T9693.script

Reviewers: bgamari, sighingnow, RyanGlScott

Reviewed By: sighingnow, RyanGlScott

Subscribers: RyanGlScott, sighingnow, rwbarton, thomie, carter

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

Test Plan: validate

Reviewers: bgamari, alpmestan

Reviewed By: alpmestan

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15342

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

Reviewers: mpickering

Reviewed By: mpickering

Subscribers: mpickering, rwbarton, thomie, carter

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

Test Plan: Try `./validate`, CircleCI build; make sure core count
detection works in both cases.

Reviewers: alpmestan

Reviewed By: alpmestan

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14470

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

Summary:
I discovered when debugging #15346 that the Core Lint error
message for ill typed casts always mentions types of enclosed
//expressions//, even if the thing being casted is actually a type.
This generalizes `mkCastErr` a bit to allow it to give the proper
labelling for kind coercions.

Test Plan: Run on failing program in #15346, read the Core Lint error

Reviewers: goldfire, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie, carter

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

The stdout produced by test tcrun045 changed in commit
45f44e2c. The change appears to be
benign, so I've decided to accept it.

This was introduced in commit
45f44e2c, but it results in lots of
"check_class ~" messages when validating. I've decided to just
comment it out.

Summary:
`ppr_tc_args` was printing invisible kind arguments even
when `-fprint-explicit-kinds` wasn't enabled. Easily fixed.

Test Plan: make test TEST=T15341

Reviewers: goldfire, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #15341

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

Summary:
Another `-ddump-splices` bug that can be solved with more
judicious use of parentheses.

Test Plan: make test TEST=T15331

Reviewers: goldfire, bgamari, alanz, tdammers

Reviewed By: tdammers

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15331

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

Summary: A simple oversight.

Test Plan: make test TEST=T15324

Reviewers: goldfire, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15324

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

Summary: This was taken from Richard's branch, which in turn was
submitted to Phab by Matthew, which in turn was commandeered by Ryan.

This fixes an issue with newtype instances in which too many
coercions were being applied in the worker. This fixes the issue by
removing the data family instance axiom from the worker and moving
to the wrapper. Moreover, we now require all newtype instances
to have wrappers, for symmetry with data instances.

Reviewers: goldfire, bgamari, simonpj, mpickering

Reviewed By: mpickering

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #15318

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

Summary:
Before, we were using visible type application to apply
impredicative types to `coerce` in
`GeneralizedNewtypeDeriving`-generated bindings. This approach breaks
down when combined with `QuantifiedConstraints` in certain ways,
which #14883 and #15290 provide examples of. See
Note [GND and QuantifiedConstraints] for all the gory details.

To avoid this issue, we instead use an explicit type signature to
instantiate each GND binding, and use that to bind any type variables
that might be bound by a class method's type signature. This reduces
the need to impredicative type applications, and more importantly,
makes the programs from #14883 and #15290 work again.

Test Plan: make test TEST="T15290b T15290c T15290d T14883"

Reviewers: simonpj, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14883, #15290

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

Summary:
There was a buglet in `stripInvisArgs` (which is part of the
pretty-printing pipeline for types) in which only invisble arguments
which came before any visible arguments would be suppressed, but any
invisble arguments that came //after// visible ones would still be
printed, even if `-fprint-explicit-kinds`  wasn't enabled.
The fix is simple: make `stripInvisArgs` recursively process the
remaining types even after a visible argument is encountered.

Test Plan: make test TEST=T15308

Reviewers: goldfire, bgamari

Reviewed By: bgamari

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #15308

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

Summary:
`nlHsFunTy` wasn't parenthesizing its arguments at all,
which led to `-ddump-deriv` producing incorrectly parenthesized
types (since it uses `nlHsFunTy` to construct those types), as
demonstrated in #15307. Fix this by changing `nlHsFunTy` to add
parentheses à la `ppr_ty`: always parenthesizing the argument type
with function precedence, and recursively processing the result type,
adding parentheses for each function type it encounters.

Test Plan: make test TEST=T14578

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15307

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

There are several changes here.

* TcInteract has gotten too big, so I moved all the class-instance
  matching out of TcInteract into a new module ClsInst. It parallels
  the FamInst module.

  The main export of ClsInst is matchGlobalInst.
  This now works in TcM not TcS.

* A big reason to make matchGlobalInst work in TcM is that we can
  then use it from TcValidity.checkSimplifiableClassConstraint.
  That extends checkSimplifiableClassConstraint to work uniformly
  for built-in instances, which means that we now get a warning
  if we have givens (Typeable x, KnownNat n); see Trac #15322.

* This change also made me refactor LookupInstResult, in particular
  by adding the InstanceWhat field.  I also changed the name of the
  type to ClsInstResult.

  Then instead of matchGlobalInst reporting a staging error (which is
  inappropriate for the call from TcValidity), we can do so in
  TcInteract.checkInstanceOK.

* In TcValidity, we now check quantified constraints for termination.
  For example, this signature should be rejected:
     f :: (forall a. Eq (m a) => Eq (m a)) => blah
  as discussed in Trac #15316.   The main change here is that
  TcValidity.check_pred_help now uses classifyPredType, and has a
  case for ForAllPred which it didn't before.

  This had knock-on refactoring effects in TcValidity.

See Note [Typeable for Nat and Symbol] in TcInteract,
which I added after discussion on Trac #15322

This reverts commit 6bb0c5db.

See discussion in D4905.

This is a one line fix (and a note) that fixes four tickets, #15007,
 #15321 and #15202, #15314

The issue was that errors caused by illegal candidates (according to GHC
stage or being internal names) were leaking to the user, causing
bewildering error messages. If a candidate causes the type checker to
error, it is not a valid hole fit, and should be discarded.

As mentioned in #15321, this can cause a pattern of omissions, which
might be hard to discover. A better approach would be to gather the
error messages, and ask users to report them as GHC bugs. This will be
implemented in a subsequent change.

Reviewers: bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #15007, #15321, #15202, #15314

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

`extractSubTerms` (which is extracting pointer and non-pointer fields of a
closure) was computing the alignment incorrectly when aligning a 64-bit value
(e.g. a Double) on i386 by aligning it to 64-bits instead of to word size
(32-bits). This is documented in `mkVirtHeapOffsetsWithPadding`:

> Align the start offset (eg, 2-byte value should be 2-byte aligned).
> But not more than to a word.

Fixes #15061

Test Plan:
Validated on both 32-bit and 64-bit. 32-bit fails with various unrelated stat
failures, but no actual test failures.

Reviewers: hvr, bgamari

Reviewed By: bgamari

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #15061

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

Details are not documented, only the high-level functions

Reviewers: simonpj, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

A GADT declaration surrounded in parens does not det the con_forall
field correctly.

e.g.

data MaybeDefault v where
    TestParens  :: (forall v . (Eq v) => MaybeDefault v)

Closes #15323

It shouldn't be necessary to lock the `MVar` closure on `tryReadMVar`, since it
just reads one field of the structure and doesn't make any modifications. So
let's not.

Reviewers: bgamari, erikd, simonmar, fryguybob, osa1

Reviewed By: osa1

Subscribers: osa1, rwbarton, thomie, carter

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

Reviewers: bgamari

Subscribers: rwbarton, thomie, carter

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

Reviewers: simonmar, bgamari, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

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

Comments only: [ci skip]

Remove unsafeCoerce introduced by a54c94f0

Reviewers: simonmar, bgamari

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

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

Reviewers: simonmar, bgamari

Subscribers: rwbarton, thomie, carter

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

...provoked by Trac #15308

The level numbers we were getting simply didn't obey the
invariant (ImplicInv) in TcType
   Note [TcLevel and untouchable type variables]

That leads to chaos. Easy to fix.  I improved the documentation.

I also added an assertion in TcSimplify that checks that
level numbers go up by 1 as we dive inside implications, so
that we catch the problem at source rather than than through
its obscure consequences.

That in turn showed up that TcRules was also generating
constraints that didn't obey (ImplicInv), so I fixed that too.
I have no idea what consequences were lurking behing that
bug, but anyway now it's fixed.  Hooray.