GHCi HEAD silently accepts ill-kinded visible type applications with :type

[RyanGlScott]

If you try something nonsensical like id @Maybe in GHCi 8.6.3, it will be properly rejected:

$ ghci -XTypeApplications
GHCi, version 8.6.3: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> :t id @Maybe

<interactive>:1:5: error:
    • Expecting one more argument to ‘Maybe’
      Expected a type, but ‘Maybe’ has kind ‘* -> *’
    • In the type ‘Maybe’
      In the expression: id @Maybe

On GHC HEAD, however, this is seemingly accepted!

$ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive -XTypeApplications
GHCi, version 8.9.20190224: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> :t id @Maybe
λ>

No error message, just... a newline. Quite bizarre. Even more bizarrely, this phenomenon doesn't appear to happen with :kind:

λ> :set -XDataKinds -XPolyKinds 
λ> type Id (a :: k) = a
λ> :k Id @Maybe

<interactive>:1:5: error:
    • Expecting one more argument to ‘Maybe’
      Expected a type, but ‘Maybe’ has kind ‘* -> *’
    • In the first argument of ‘Id’, namely ‘Maybe’
      In the type ‘Id @Maybe’

[RyanGlScott]

This regression was introduced in commit ​5c1f268e2744fab2d36e64c163858995451d7095 (Fail fast in solveLocalEqualities).

[RyanGlScott]

Combining this with -fdefer-type-errors leads to a panic:

GHCi, version 8.9.20190227: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> :set -XTypeApplications -fdefer-type-errors 
λ> f = id @Maybe

<interactive>:2:9: warning: [-Wdeferred-type-errors]
    • Expecting one more argument to ‘Maybe’
      Expected a type, but ‘Maybe’ has kind ‘* -> *’
    • In the type ‘Maybe’
      In the expression: id @Maybe
      In an equation for ‘f’: f = id @Maybe
ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 8.9.20190227 for x86_64-unknown-linux):
        nameModule
  internal f_a1BS
  Call stack:
      CallStack (from HasCallStack):
        callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable
        pprPanic, called at compiler/basicTypes/Name.hs:249:3 in ghc:Name

[simonpj]

comment:3 reveals another bug: see #16404

[RyanGlScott]

Fixed in ​5be7ad78.

[Marge Bot <ben+marge-bot@…>]

In 5be7ad78/ghc:

Use captureTopConstraints in TcRnDriver calls

Trac #16376 showed the danger of failing to report an error
that exists only in the unsolved constraints, if an exception
is raised (via failM).

Well, the commit 5c1f268e (Fail fast in solveLocalEqualities)
did just that -- i.e. it found errors in the constraints, and
called failM to avoid a misleading cascade.

So we need to be sure to call captureTopConstraints to report
those insolubles.  This was wrong in TcRnDriver.tcRnExpr and
in TcRnDriver.tcRnType.

As a result the error messages from test T13466 improved slightly,
a happy outcome.