[GHC] #13393: GHC panic: No skolem info

[GHC]

#13393: GHC panic: No skolem info
-------------------------------------+-------------------------------------
        Reporter:  sheyll            |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.2
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86_64
 Type of failure:  Compile-time      |  (amd64)
  crash or panic                     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Simon Peyton Jones <simonpj@…>):

 In [changeset:"7e96526ac2ef5987ecb03217d3d616b6281c1441/ghc" 7e96526/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="7e96526ac2ef5987ecb03217d3d616b6281c1441"
 Fix TcSimplify.decideQuantification for kind variables

 TcSimplify.decideQuantification was doing the Wrong Thing when
 "growing" the type variables to quantify over. We were trying to do
 this on a tyvar set where we'd split off the dependent type varaibles;
 and we just got it wrong.  A kind variable wasn't being generalised
 properly, with confusing knock on consequences.

 All this led to Trac #13371 and Trac #13393.

 This commit tidies it all up:

 * The type TcDepVars is renamed as CandidateQTvs;
   and splitDepVarsOfType to candidateQTyVarsOfType

 * The code in TcSimplify.decideQuantification is simpler.
   It no longer does the tricky "grow" stuff over TcDepVars.
   Instead it use ordinary VarSets (thereby eliminating the
   nasty growThetaTyVarsDSet) and uses that to filter the
   result of candidateQTyVarsOfType.

 * I documented that candidateQTyVarsOfType returns the type
   variables in a good order in which to quantify, and rewrote
   it to use an accumulator pattern, so that we would predicatably
   get left-to-right ordering.

 In doing all this I also made UniqDFM behave a little more nicely:

 * When inserting an element that is there already, keep the old tag,
   while still overwriting with the new value.

 * This means that when doing udfmToList we get back elements in the
   order they were originally inserted, rather than in reverse order.

 It's not a big deal, but in a subsequent commit I use it to improve
 the order of type variables in inferred types.

 All this led to a lot of error message wibbles:
  - changing the order of quantified variables
  - changing the order in which instances are listed in GHCi
  - changing the tidying of variables in typechecker erors

 There's a submodule update for 'array' because one of its tests
 has an error-message change.

 I may not have associated all of them with the correct commit.
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13393#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler