Opened 21 months ago

Closed 19 months ago

Last modified 18 months ago

#11456 closed bug (fixed)

Type application and :set +c command cause panic

Reported by: Iceland_jack Owned by:
Priority: normal Milestone: 8.0.1
Component: Compiler Version: 8.1
Keywords: TypeApplications GHCi Cc: goldfire
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: ghci/scripts/T11456
Blocked By: Blocking:
Related Tickets: #11329 Differential Rev(s):
Wiki Page:

Description

Type applications and the :set +c command don't play nice

{-# LANGUAGE TypeApplications #-}
a = show @Int
% ghci -ignore-dot-ghci 
GHCi, version 8.1.20160117: http://www.haskell.org/ghc/  :? for help
Prelude> :set +c
Prelude> :load Panic.hs 
[1 of 1] Compiling Main             ( Panic.hs, interpreted )
Ok, modules loaded: Main.
Collecting type info for 1 module(s) ... 
Error while getting type info from Main: ghc: panic! (the 'impossible' happened)
  (GHC version 8.1.20160117 for x86_64-unknown-linux):
        dsExpr:HsTypeOut

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

*Main>

Attachments (1)

Error2.hs (180 bytes) - added by Iceland_jack 18 months ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 21 months ago by Iceland_jack

Doesn't happen with id @Int

comment:2 Changed 20 months ago by rwbarton

It does actually, assuming you mean replacing show by id in the ticket.

GHCi.UI.Info.processAllTypeCheckedModule is trying to desugar all the spans in the typechecked program individually to find out their types. One of those spans is @Int, which can't be desugared outside of the context show @Int. We should skip such subexpressions: any HsTypeOut constructor.

Since this code is written in Generics-ese, I don't feel like trying to fix it myself.

(Also, surely there is a more sensible way to collect this data then desugaring every span to find out its type, when we have already type checked the whole module?)

comment:3 Changed 20 months ago by rwbarton

Cc: goldfire added

In general, though, this is a trap for GHC API users, who might expect every HsExpr to be, well, an expression. Richard, did you consider representing explicit type applications with a separate constructor HsTypeApp?

comment:4 Changed 20 months ago by rwbarton

Specifically, leave Parser.y unchanged, but at the end of parsing, convert all HsApp e (HsType t) to HsTypeApp e t (modulo locations, etc.) Then there are no invariants of the form "HsType can appear only within HsApp", just ones of the form "the output of [stage X] cannot contain [constructor Y]".

comment:5 Changed 20 months ago by goldfire

No, I didn't consider HsTypeApp. That would probably be an improvement. My choice of abstract syntax was inspired by Core, which just has App :: CoreExpr -> CoreExpr -> CoreExpr and Type :: Type -> CoreExpr.

I'll look into this refactoring. It could actually simplify quite a bit. (For example, see the awful tcSeq and tcTagToEnum in TcExpr.) Thanks for the suggestion.

comment:6 Changed 19 months ago by goldfire

I have this refactoring done locally and will push in (short) due course.

comment:7 Changed 19 months ago by Richard Eisenberg <eir@…>

In 972730c/ghc:

Refactor visible type application.

This replaces the old HsType and HsTypeOut constructors
with HsAppType and HsAppTypeOut, leading to some simplification.
(This refactoring addresses #11329.)

This also fixes #11456, which stumbled over HsType (which is
not an expression).

test case: ghci/scripts/T11456

[skip ci]

comment:8 Changed 19 months ago by goldfire

Status: newmerge
Test Case: ghci/scripts/T11456

comment:9 Changed 19 months ago by bgamari

Milestone: 8.0.1
Resolution: fixed
Status: mergeclosed

Changed 18 months ago by Iceland_jack

Attachment: Error2.hs added

comment:10 Changed 18 months ago by Iceland_jack

Error2.hs fails, seems like same problem and can be added to the test suite:

$ ghci -ignore-dot-ghci 
GHCi, version 8.1.20160117: http://www.haskell.org/ghc/  :? for help
Prelude> :set +c
Prelude> :load /tmp/Error2.hs 
[1 of 1] Compiling Main             ( /tmp/Error2.hs, interpreted )
Ok, modules loaded: Main.
Collecting type info for 1 module(s) ... 
Error while getting type info from Main: ghc: panic! (the 'impossible' happened)
  (GHC version 8.1.20160117 for x86_64-unknown-linux):
        dsExpr:HsTypeOut

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

*Main> 

comment:11 Changed 18 months ago by goldfire

Error2 seems to have the same mechanism (:set +c with a type application) as the original error, which is already in the testsuite. I personally don't think another test is warranted. Thanks for posting however -- if someone stumbles over this problem in the future, they will find your second case.

Note: See TracTickets for help on using tickets.