GitLab

These were fixed by faec8d35

test cases: typecheck/should_fail/T14884
            ghci/scripts/T14969

The main job of this commit is to track more accurately the scope
of tyvars introduced by user-written foralls. For example, it would
be to have something like this:

  forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool

In that type, a's kind must be k, but k isn't in scope. We had a
terrible way of doing this before (not worth repeating or describing
here, but see the old tcImplicitTKBndrs and friends), but now
we have a principled approach: make an Implication when kind-checking
a forall. Doing so then hooks into the existing machinery for
preventing skolem-escape, performing floating, etc. This also means
that we bump the TcLevel whenever going into a forall.

The new behavior is done in TcHsType.scopeTyVars, but see also
TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant
rewriting. There are several Notes near there to guide you. Of
particular interest there is that Implication constraints can now
have skolems that are out of order; this situation is reported in
TcErrors.

A major consequence of this is a slightly tweaked process for type-
checking type declarations. The new Note [Use SigTvs in kind-checking
pass] in TcTyClsDecls lays it out.

The error message for dependent/should_fail/TypeSkolEscape has become
noticeably worse. However, this is because the code in TcErrors goes to
some length to preserve pre-8.0 error messages for kind errors. It's time
to rip off that plaster and get rid of much of the kind-error-specific
error messages. I tried this, and doing so led to a lovely error message
for TypeSkolEscape. So: I'm accepting the error message quality regression
for now, but will open up a new ticket to fix it, along with a larger
error-message improvement I've been pondering. This applies also to
dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142.

Other minor changes:
 - isUnliftedTypeKind didn't look for tuples and sums. It does now.

 - check_type used check_arg_type on both sides of an AppTy. But the left
   side of an AppTy isn't an arg, and this was causing a bad error message.
   I've changed it to use check_type on the left-hand side.

 - Some refactoring around when we print (TYPE blah) in error messages.
   The changes decrease the times when we do so, to good effect.
   Of course, this is still all controlled by
   -fprint-explicit-runtime-reps

Fixes #14066 #14749

Test cases: dependent/should_compile/{T14066a,T14749},
            dependent/should_fail/T14066{,c,d,e,f,g,h}

Previously, GHC allowed all of the following:

```lang=haskell
data Foo1 :: Constraint
data family Foo2 :: Constraint
data family Foo3 :: k
data instance Foo3 :: Constraint
```

Yikes! This is because GHC was confusing `Type` with `Constraint`
due to careless use of the `isLiftedTypeKind` function. To respect
this distinction, I swapped `isLiftedTypeKind` out for
`tcIsStarKind`—which does respect this distinction—in the right
places.

Test Plan: make test TEST="T14048a T14048b T14048c"

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: goldfire, rwbarton, thomie, carter

GHC Trac Issues: #14048

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

Print different error message for improper UNPACK and strictness
annotations.  Fix Trac #14761.
Signed-off-by: HE, Tao <sighingnow@gmail.com>

Test Plan: make test TEST="T7210 T14761a T14761b"

Reviewers: goldfire, bgamari, RyanGlScott, simonpj

Reviewed By: RyanGlScott, simonpj

Subscribers: simonpj, goldfire, rwbarton, thomie, carter

GHC Trac Issues: #14761

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

As Trac #14605 showed, we can't defer a type error under a
'forall' (when unifying two forall types).

The fix is simple.

In the presence of -fdefer-type-errors, OptCoercion can
encounter a mal-formed coerercion with type
    T a ~ T a b
and that was causing a subsequent Lint error.

This caused Trac #14607.  Easily fixed by turning an ASSERT
into a guard.

Previously, we were inexplicably not applying an instantiating
substitution to arguments in non-prenex types. It's amazing this
has been around for so long! I guess there aren't a lot of non-prenex
types around.

test case: typecheck/should_fail/T14618

Many industrial users have aligned around the idea that implicit exports
are an anti-pattern. They lead to namespace pollution and byzantine
naming schemes. They also prevent GHC's dead code analysis and create
more obstacles to optimization. This warning allows teams/projects to
warn on or enforce via -Werror explicit export lists.

This warning also serves as a complement to warn-missing-import-lists.

This was originally discussed here:
https://github.com/ghc-proposals/ghc-proposals/pull/93

Test Plan: Three new minimal tests have been added to the type checker.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

GHC was panicking when pretty-printing a heterogeneous
equality type constructor (#14390) because the function which
produced the type constructor, `toIfaceTyCon`, wasn't attaching the
appropriate `IfaceTyConSort` for equality type constructors, which
is `IfaceEqualityTyCon`. This is fixed easily enough.

Test Plan: make test TEST=T14390

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #14390

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

Trac #13450 went bananas if we expand insoluble constraints.
Better just to leave them un-expanded.

I'm not sure in detail about why it goes so badly wrong; but
regardless, the less we mess around with insoluble contraints
the better the error messages will be.

See Note [Given insolubles] in TcRnTypes

Fixes Trac #14325.

Fixes #13929.

Test Plan: Validate

Reviewers: austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #13929

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

test case: typecheck/should_fail/T13929

GHC was complaining about numbers of arguments when the real
problem is impredicativity.

test case: typecheck/should_fail/T13909

Summary:
Currently, whenever you apply a function to too many arguments and
some of those arguments happen to be visible type applications, the error
message that GHC gives is rather confusing. Consider the message you receive
when typechecking `id @Int 1 2`:

```
The function `id` is applied to three arguments,
but its type `Int -> Int` has only one
```

This is baffling, since the two lines treat the visible type argument `@Int`
differently. The top line ("applied to three arguments") includes `@Int`,
whereas the bottom line ("has only one") excludes `@Int` from consideration.

There are multiple ways one could fix this, which I explain in an addendum to
`Note [Herald for matchExpectedFunTys]`. The approach adopted here is to change
the herald of this error message to include visible type arguments, and to
avoid counting them in the "applied to n arguments" part of the error. The end
result is that the new error message for `id @Int 1 2` is now:

```
The expression `id @Int` is applied to two arguments,
but its type `Int -> Int` has only one
```

Test Plan: make test TEST=T13902

Reviewers: goldfire, austin, bgamari

Reviewed By: goldfire

Subscribers: rwbarton, thomie

GHC Trac Issues: #13902

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

Now that `mtl` and `parsec` are boot libraries, there's no need to
qualify various tests in the testsuite with `reqlib('mtl')` or
`reqlib('parsec')`.

Test Plan: make test TEST="T4809 tcfail126 T4355 tc232 tc223 tc220
tc217 tc183 T5303 DoParamM qq005 qq006 galois_raytrace T1074 mod133
T3787 T4316 prog011 drvfail006 drvfail008"

Reviewers: bgamari, austin

Subscribers: rwbarton, thomie

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

Trac #14000 showed up two errors

* In TcRnTypes.dropInsolubles we dropped all implications, which
  might contain the very insolubles we wanted to keep.  This was
  an outright error, and is why the out-of-scope error was actually
  lost altogether in Trac #14000

* In TcSimplify.simplifyInfer, if there are definite (insoluble)
  errors, it's better to suppress the following ambiguity test,
  because the type may be bogus anyway.  See TcSimplify
  Note [Quantification with errors].  This fix seems a bit clunky,
  but it'll do for now.

This is a straightforward fix -- there were just some omitted
checks.

test case: typecheck/should_fail/T11963

The uo_thing field of TypeEqOrigin is used to track the
"thing" (either term or type) that has the type (kind) stored
in the TypeEqOrigin fields. Previously, this was sometimes a
proper Core Type, which needed zonking and tidying. Now, it
is only HsSyn: much simpler, and the error messages now use
the user-written syntax.

But this aspect of uo_thing didn't cause #13819; it was the
sibling field uo_arity that did. uo_arity stored the number
of arguments of uo_thing, useful when reporting something
like "should have written 2 fewer arguments". We wouldn't want
to say that if the thing didn't have two arguments. However,
in practice, GHC was getting this wrong, and this message
didn't seem all that helpful. Furthermore, the calculation
of the number of arguments is what caused #13819 to fall over.
This patch just removes uo_arity. In my opinion, the change
to error messages is a nudge in the right direction.

Test case: typecheck/should_fail/T13819

I believe this was fixed with the fix for #11198.

Previously, when canonicalizing (or unifying, in uType) a
heterogeneous equality, we emitted a kind equality and used the
resulting coercion to cast one side of the heterogeneous equality.

While sound, this led to terrible error messages. (See the bugs
listed below.) The problem is that using the coercion built from
the emitted kind equality is a bit like a wanted rewriting a wanted.
The solution is to keep heterogeneous equalities as irreducible.

See Note [Equalities with incompatible kinds] in TcCanonical.

This commit also removes a highly suspicious switch to FM_SubstOnly
when flattening in the kinds of a type variable. I have no idea
why this was there, other than as a holdover from pre-TypeInType.
I've not left a Note because there is simply no reason I can conceive
of that the FM_SubstOnly should be there.

One challenge with this patch is that the emitted derived equalities
might get emitted several times: when a heterogeneous equality is
in an implication and then gets floated out from the implication,
the Derived is present both in and out of the implication. This
causes a duplicate error message. (Test case:
typecheck/should_fail/T7368) Solution: track the provenance of
Derived constraints and refuse to float out a constraint that has
an insoluble Derived.

Lastly, this labels one test (dependent/should_fail/RAE_T32a)
as expect_broken, because the problem is really #12919. The
different handling of constraints in this patch exposes the error.

This fixes bugs #11198, #12373, #13530, and #13610.

test cases:
typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610}

An error message was referring to a type synonym as a datatype.
Annoyingly, learning that the TyCon over which the error message is
operating is actually a type synonym was previously impossible, since
that code only had access to a TcTyCon, which doesn't retain any
information about what sort of TyCon it is.

To rectify this, I created a new TyConFlavour datatype, intended to
capture roughly what sort of TyCon we're dealing with. I then performing
the necessary plumbing to ensure all TcTyCons have a TyConFlavour, and
propagated this information through to the relevant error message.

Test Plan: ./validate

Reviewers: goldfire, austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie

GHC Trac Issues: #13983

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

Previously, we we only using `tcSplitSigmaTy` when determining if a
function had been applied to too few arguments, so it wouldn't work for
functions with nested `forall`s. Thankfully, this is easily fixed with a
dash of `tcSplitNestedSigmaTys`.

Test Plan: make test TEST=T13311

Reviewers: austin, bgamari, simonpj

Reviewed By: bgamari

Subscribers: goldfire, simonpj, rwbarton, thomie

GHC Trac Issues: #13311

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

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13821

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

Commit ce97b729 (the fix for #12175) also
fixed #12648. Let's add a regression test so that it stays fixed.

Summary:
Commit 0c9d9dec (the fix for #13271) fixed the
programs in #12083. This adds regression tests for them.

Test Plan: make test TEST="T12083a T12083b"

Reviewers: austin, bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #12083

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

Fixes #13677 by parenthesizing equalities in a sufficiently high
pretty-printing context.

Test Plan: make test TEST=T13677

Reviewers: goldfire, austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13677

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

Summary:
Commit b4bdbe49 (the fix for #12156)
wound up being the fix for #12947 and #13640 as well. This adds regression
tests for the latter two tickets to keep them fixed.

Test Plan: make test TEST="T12947 T13640"

Reviewers: bgamari, austin

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #12947, #13640

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

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13320

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

this program should be rejected, but is not (and segfaults).

I'd forgotten to add deferred bindings for user type
errors.  Fixes Trac #13487.

This makes GHC drop derived FunDep errors when they
are come from wanted/wanted interactions.  Much along
the lines of "don't rewrite wanteds with wanteds".

See TcRnTypes Note [Dropping derived constraints]
and the new code in isDroppableDerivedLoc.

Fixes Trac #13506.

I'd got the logic slightly wrong when reporting type errors
for insoluble 'given' equalities.  We suppress insoluble givens
under some circumstances (see Note [Given errors]), but we then
suppressed subsequent 'wanted' errors because the (suppressed)
'given' error "won".  Result: no errors at all :-(.

This patch fixes it and
 - Renames TcType.isTyVarUnderDatatype to the more
   perspicuous TcType.isInsolubleOccursCheck

In doing this I realise that I don't understand why we need
to keep the insolubles partitioned out separately at all...
but that is for another day.

In an effort to report multiple levity polymorphism errors all at
once, the desugarer does not fail when encountering bad levity
polymorphism. But we must be careful not to build the bad applications,
lest they try to satisfy the let/app invariant and call
isUnliftedType on a levity polymorphic type. This protects calls
to mkCoreAppDs appropriately.

test case: typecheck/should_fail/T12709