1. 02 Nov, 2016 3 commits
    • Simon Peyton Jones's avatar
      Simplify the API for TcHsType.kcHsTyVarBndrs · 7a509660
      Simon Peyton Jones authored
      Pass in a Bool rather than return a funcion!
      
      No change in behaviour.
      7a509660
    • Simon Peyton Jones's avatar
      Get rid of TcTyVars more assiduously · 99689492
      Simon Peyton Jones authored
      * I found a bug in 'generalize' in TcTyClsDecls.kcTyClGroup, where
        the kind variables weren't being turned into proper TyVars, so
        we got (skolem) TcTyVars in TyCons, which shouldn't happen.  Fix
        was easy.
      
      * Similarly TcHsType.kindGeneralizeType wasn't turning the forall'd
        TcTyVars into TyVars.  To achieve this I defined TcHsTyn.zonkSigType.
      
      * All this allowed me to remove awkward and ill-explained bit of
        footwork on DFunIds in Inst.newClsInst
      
      This is just refactoring, but it does make the printout from
      -ddump-deriv make a bit more sense by not grautuitiously cloning
      type variables.  In the display I was seeing
      
         instance C [a_df4] where
            f x = ...a_dx5...
      
      where actually the d_df4 and a_dx5 were the same.
      99689492
    • Simon Peyton Jones's avatar
      Tiny refactor · 79fb6e66
      Simon Peyton Jones authored
      Swap order of calls in genInst just to make
      the two cases the same
      
      Plus some alpha-renaming
      79fb6e66
  2. 31 Oct, 2016 1 commit
  3. 28 Oct, 2016 1 commit
  4. 27 Oct, 2016 2 commits
  5. 26 Oct, 2016 3 commits
  6. 24 Oct, 2016 3 commits
  7. 21 Oct, 2016 8 commits
    • Simon Peyton Jones's avatar
      Improve TcCanonical.unifyWanted and unifyDerived · 6ddba642
      Simon Peyton Jones authored
      When debugging something else I noticed that these functions
      were emitting constraints like
         [W] a ~ a
      which is plain stupid.  So I fixed it not to do that.  Should
      result in fewer constraints getting generated.
      6ddba642
    • Simon Peyton Jones's avatar
      Define emitNewWantedEq, and use it · e1fc5a33
      Simon Peyton Jones authored
      This is just a minor refactoring
      e1fc5a33
    • Simon Peyton Jones's avatar
      Refactor occurrence-check logic · 9417e579
      Simon Peyton Jones authored
      This patch does two related things
      
      * Combines the occurrence-check logic in the on-the-fly unifier with
        that in the constraint solver.  They are both doing the same job,
        after all.  The resulting code is now in TcUnify:
           metaTyVarUpdateOK
           occCheckExpand
           occCheckForErrors (called in TcErrors)
      
      * In doing this I disovered checking for family-free-ness and foralls
        can be unnecessarily inefficient, because it expands type synonyms.
        It's easy just to cache this info in the type syononym TyCon, which
        I am now doing.
      9417e579
    • Simon Peyton Jones's avatar
      A collection of type-inference refactorings. · 3f5673f3
      Simon Peyton Jones authored
      This patch does a raft of useful tidy-ups in the type checker.
      I've been meaning to do this for some time, and finally made
      time to do it en route to ICFP.
      
      1. Modify TcType.ExpType to make a distinct data type,
         InferResult for the Infer case, and consequential
         refactoring.
      
      2. Define a new function TcUnify.fillInferResult, to fill in
         an InferResult. It uses TcMType.promoteTcType to promote
         the type to the level of the InferResult.
         See TcMType Note [Promoting a type]
         This refactoring is in preparation for an improvement
         to typechecking pattern bindings, coming next.
      
         I flirted with an elaborate scheme to give better
         higher rank inference, but it was just too complicated.
         See TcMType Note [Promotion and higher rank types]
      
      3. Add to InferResult a new field ir_inst :: Bool to say
         whether or not the type used to fill in the
         InferResult should be deeply instantiated.  See
         TcUnify Note [Deep instantiation of InferResult].
      
      4. A...
      3f5673f3
    • Simon Peyton Jones's avatar
      Make TcLevel increase by 1 not 2 · d61c7e8d
      Simon Peyton Jones authored
      Make the TcLevel of a flatten-meta-var be always zero.
      See TcType.fmvTcLevel.
      
      This allows the levels of implication constraints to to
      up by 1 each time instead of 2, which is less confusing.
      
      This change has no effect on type checking.
      d61c7e8d
    • Simon Peyton Jones's avatar
      Comments and trivial refactoring · 82efad78
      Simon Peyton Jones authored
      82efad78
    • Simon Peyton Jones's avatar
      Refactor typechecking of pattern bindings · 45bfd1a6
      Simon Peyton Jones authored
      This patch fixes a regression introduced, post 8.0.1, by
      this major commit:
      
           commit 15b9bf4b
           Author: Simon Peyton Jones <simonpj@microsoft.com>
           Date:   Sat Jun 11 23:49:27 2016 +0100
      
               Improve typechecking of let-bindings
      
               This major commit was initially triggered by #11339, but it
               spiraled into a major review of the way in which type
               signatures for bindings are handled, especially partial type
               signatures.
      
      I didn't get the typechecking of pattern bindings right, leading
      to Trac #12427.
      
      In fixing this I found that this program doesn't work:
      
        data T where
          T :: a -> ((forall b. [b]->[b]) -> Int) -> T
      
        h1 y = case y of T _ v -> v
      
      Works in 7.10, but not in 8.0.1.
      
      There's a happy ending. I found a way to fix this, and improve
      pattern bindings too.  Not only does this fix #12427, but it also
      allows
      
      In particular,we now can accept
      
        data T where MkT :: a -> Int -> T
      
        ... let { MkT _ q = t } in ...
      
      Previously this elicited "my head exploded" but it's really
      fine since q::Int.
      
      The approach is described in detail in TcBinds
         Note [Typechecking pattern bindings]
      Super cool.  And not even a big patch!
      45bfd1a6
    • Gabor Greif's avatar
      Typos in comments · ff225b49
      Gabor Greif authored
      ff225b49
  8. 20 Oct, 2016 4 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Only delete instances when merging when there is an exact match. · 9df4ce4f
      Edward Z. Yang authored
      
      
      Summary:
      Previously, we deleted if the heads matched, which meant that
      we effectively were picking an arbitrary instance if there
      were incompatible instances.  The new behavior makes more sense,
      although without incoherent instances you are unlikely to
      be able to do anything useful with the instances.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2596
      9df4ce4f
    • Edward Z. Yang's avatar
      Support constraint synonym implementations of abstract classes. · 7e77c4b2
      Edward Z. Yang authored
      Summary:
      
      Test Plan: validate
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2595
      
      GHC Trac Issues: #12679
      7e77c4b2
    • Edward Z. Yang's avatar
      New story for abstract data types in hsig files. · 518f2895
      Edward Z. Yang authored
      Summary:
      In the old implementation of hsig files, we directly
      reused the implementation of abstract data types from
      hs-boot files.  However, this was WRONG.  Consider the
      following program (an abridged version of bkpfail24):
      
          {-# LANGUAGE GADTs #-}
          unit p where
              signature H1 where
                  data T
              signature H2 where
                  data T
              module M where
                  import qualified H1
                  import qualified H2
      
                  f :: H1.T ~ H2.T => a -> b
                  f x = x
      
      Prior to this patch, M was accepted, because the type
      inference engine concluded that H1.T ~ H2.T does not
      hold (indeed, *presently*, it does not).  However, if
      we subsequently instantiate p with the same module for
      H1 and H2, H1.T ~ H2.T does hold!  Unsound.
      
      The key is that abstract types from signatures need to
      be treated like *skolem variables*, since you can interpret
      a Backpack unit as a record which is universally quantified
      over all of its abstract types, as such (with some fake
      syntax for structural records):
      
          p :: forall t1 t2. { f :: t1 ~ t2 => a -> b }
          p = { f = \x -> x } -- ill-typed
      
      Clearly t1 ~ t2 is not solvable inside p, and also clearly
      it could be true at some point in the future, so we better
      not treat the lambda expression after f as inaccessible.
      
      The fix seems to be simple: do NOT eagerly fail when trying
      to simplify the given constraints.  Instead, treat H1.T ~ H2.T
      as an irreducible constraint (rather than an insoluble
      one); this causes GHC to treat f as accessible--now we will
      typecheck the rest of the function (and correctly fail).
      Per the OutsideIn(X) paper, it's always sound to fail less
      when simplifying givens.
      
      We do NOT apply this fix to hs-boot files, where abstract
      data is also guaranteed to be nominally distinct (since
      it can't be implemented via a reexport or a type synonym.)
      This is a somewhat unnatural state of affairs (there's
      no way to really interpret this in Haskell land) but
      no reason to change behavior.
      
      I deleted "representationally distinct abstract data",
      which is never used anywhere in GHC.
      
      In the process of constructing this fix, I also realized
      our implementation of type synonym matching against abstract
      data was not sufficiently restrictive.  In order for
      a type synonym T to be well-formed type, it must be a
      nullary synonym (i.e., type T :: * -> *, not type T a = ...).
      Furthermore, since we use abstract data when defining
      instances, they must not have any type family applications.
      
      More details in #12680
      
      .  This probably deserves some sort
      of short paper report.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2594
      518f2895
  9. 19 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Test for newtype with unboxed argument · 1f09c16c
      Simon Peyton Jones authored
      Newtypes cannot (currently) have an unboxed argument type.
      But Trac #12729 showed that this was only being checked for
      newtypes in H98 syntax; in GADT snytax they were let through.
      
      This patch moves the test to checkValidDataCon, where it properly
      belongs.
      1f09c16c
  10. 18 Oct, 2016 1 commit
  11. 17 Oct, 2016 7 commits
  12. 15 Oct, 2016 2 commits
  13. 14 Oct, 2016 2 commits
    • Ryan Scott's avatar
      Make error when deriving an instance for a typeclass less misleading · d5a4e49d
      Ryan Scott authored
      Before, when you attempted to derive an instance for a typeclass,
      e.g.,
      
      ```
      class C1 (a :: Constraint) where
      class C2 where
      
      deriving instance C1 C2
      ```
      
      GHC would complain that `C2`'s data constructors aren't in scope. But
      that
      makes no sense, since typeclasses don't have constructors! By refining
      the
      checks that GHC performs when deriving, we can make the error message a
      little more sensible.
      
      This also cleans up a related `DeriveAnyClass` infelicity. Before, you
      wouldn't have been able to compile code like this:
      
      ```
      import System.IO (Handle)
      class C a
      deriving instance C Handle
      ```
      
      Since GHC was requiring that all data constructors of `Handle` be in
      scope. But `DeriveAnyClass` doesn't even generate code that mentions
      any data constructors, so this requirement is silly!
      
      Fixes #11509.
      
      Test Plan: make test TEST=T11509
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D2558
      
      GHC Trac Issues: #11509
      d5a4e49d
    • Ben Gamari's avatar
      Clean up handling of known-key Names in interface files · 34d933d6
      Ben Gamari authored
      Previously BinIface had some dedicated logic for handling tuple names in
      the symbol table. As it turns out, this logic was essentially dead code
      as it was superceded by the special handling of known-key things. Here
      we cull the tuple code-path and use the known-key codepath for all
      tuple-ish things.
      
      This had a surprising number of knock-on effects,
      
       * constraint tuple datacons had to be made known-key (previously they
         were not)
      
       * IfaceTopBndr was changed from being a synonym of OccName to a
         synonym of Name (since we now need to be able to deserialize Names
         directly from interface files)
      
       * the change to IfaceTopBndr complicated fingerprinting, since we need
         to ensure that we don't go looking for the fingerprint of the thing
         we are currently fingerprinting in the fingerprint environment (see
         notes in MkIface). Handling this required distinguishing between
         binding and non-binding Name occurrences in the Binary serializers.
      
       * the original name cache logic which previously lived in IfaceEnv has
         been moved to a new NameCache module
      
       * I ripped tuples and sums out of knownKeyNames since they introduce a
         very large number of entries. During interface file deserialization
         we use static functions (defined in the new KnownUniques module) to
         map from a Unique to a known-key Name (the Unique better correspond
         to a known-key name!) When we need to do an original name cache
         lookup we rely on the parser implemented in isBuiltInOcc_maybe.
      
       * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames.
      
       * Lots of comments were sprinkled about describing the new scheme.
      
      Updates haddock submodule.
      
      Test Plan: Validate
      
      Reviewers: niteria, simonpj, austin, hvr
      
      Reviewed By: simonpj
      
      Subscribers: simonmar, niteria, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2467
      
      GHC Trac Issues: #12532, #12415
      34d933d6
  14. 13 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Further improve error handling in TcRn monad · 2fdf21bf
      Simon Peyton Jones authored
      This patch builds on the one for Trac #12124, by dealing properly
      with out-of-scope "hole" errors.
      
      This fixes Trac #12529. The hard error coming from visible type application
      is still there, but the out-of-scope error is no longer suppressed.
      
      (Arguably the VTA message should be suppressed somehow, but that's a
      battle for another day.)
      2fdf21bf
  15. 12 Oct, 2016 1 commit