Opened 10 months ago

Closed 9 months ago

Last modified 9 months ago

#16376 closed bug (fixed)

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

Reported by: RyanGlScott Owned by:
Priority: highest Milestone: 8.10.1
Component: GHCi Version: 8.9
Keywords: Cc: int-index, simonpj
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHC accepts invalid program Test Case: ghci/scripts/T16376
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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’

Change History (6)

comment:1 Changed 10 months ago by int-index

Cc: int-index added

comment:2 Changed 10 months ago by RyanGlScott

Cc: simonpj added

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

comment:3 Changed 9 months ago by 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

comment:4 Changed 9 months ago by simonpj

comment:3 reveals another bug: see #16404

comment:5 Changed 9 months ago by RyanGlScott

Milestone: 8.10.1
Resolution: fixed
Status: newclosed
Test Case: ghci/scripts/T16376

Fixed in 5be7ad78.

comment:6 Changed 9 months ago by 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.
Note: See TracTickets for help on using tickets.