1. 04 Nov, 2014 5 commits
  2. 26 Sep, 2014 2 commits
  3. 19 Sep, 2014 1 commit
    • Simon Peyton Jones's avatar
      Clean up Coercible handling, and interaction of data families with newtypes · 0aaf812e
      Simon Peyton Jones authored
      This patch fixes Trac #9580, in which the Coercible machinery succeeded
      even though the relevant data constructor was not in scope.
      
      As usual I got dragged into a raft of refactoring changes,
      all for the better.
      
      * Delete TcEvidence.coercionToTcCoercion (now unused)
      
      * Move instNewTyConTF_maybe, instNewTyCon_maybe to FamInst,
        and rename them to tcInstNewTyConTF_maybe, tcInstNewTyCon
        (They both return TcCoercions.)
      
      * tcInstNewTyConTF_maybe also gets more convenient type,
        which improves TcInteract.getCoercibleInst
      
      * Define FamInst.tcLookupDataFamInst, and use it in TcDeriv,
        (as well as in tcInstNewTyConTF_maybe)
      
      * Improve error report for Coercible errors, when data familes
        are involved  Another use of tcLookupDataFamInst
      
      * In TcExpr.tcTagToEnum, use tcLookupDataFamInst to replace
        local hacky code
      
      * Fix Coercion.instNewTyCon_maybe and Type.newTyConInstRhs to deal
        with eta-reduced newtypes, using
        (new) Type.unwrapNewTyConEtad_maybe and (new) Type.applyTysX
      
      Some small refactoring of TcSMonad.matchFam.
      0aaf812e
  4. 21 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Rename PackageId to PackageKey, distinguishing it from Cabal's PackageId. · 4bebab25
      Edward Z. Yang authored
      
      
      Summary:
      Previously, both Cabal and GHC defined the type PackageId, and we expected
      them to be roughly equivalent (but represented differently).  This refactoring
      separates these two notions.
      
      A package ID is a user-visible identifier; it's the thing you write in a
      Cabal file, e.g. containers-0.9.  The components of this ID are semantically
      meaningful, and decompose into a package name and a package vrsion.
      
      A package key is an opaque identifier used by GHC to generate linking symbols.
      Presently, it just consists of a package name and a package version, but
      pursuant to #9265 we are planning to extend it to record other information.
      Within a single executable, it uniquely identifies a package.  It is *not* an
      InstalledPackageId, as the choice of a package key affects the ABI of a package
      (whereas an InstalledPackageId is computed after compilation.)  Cabal computes
      a package key for the package and passes it to GHC using -package-name (now
      *extremely* misnamed).
      
      As an added bonus, we don't have to worry about shadowing anymore.
      
      As a follow on, we should introduce -current-package-key having the same role as
      -package-name, and deprecate the old flag.  This commit is just renaming.
      
      The haddock submodule needed to be updated.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D79
      
      Conflicts:
      	compiler/main/HscTypes.lhs
      	compiler/main/Packages.lhs
      	utils/haddock
      4bebab25
  5. 24 Jun, 2014 1 commit
  6. 09 Jun, 2014 1 commit
  7. 28 May, 2014 1 commit
    • Simon Peyton Jones's avatar
      Use mkTcEqPred rather than mkEqPred in the type checker · 8668c549
      Simon Peyton Jones authored
      Type.mkEqPred has an assertion warning for kind compatibility.  But
      during type checking we may form equality predicates with incompatible
      kinds; hence TcType.mkTcEqPred, which does not check.  We were calling
      the former instead of the latter in a couple of places, leading to
      spurious debug warnings.
      8668c549
  8. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  9. 14 Apr, 2014 1 commit
  10. 08 Apr, 2014 1 commit
    • Simon Peyton Jones's avatar
      Improve error reporting for untouchable type variables · 50bfd421
      Simon Peyton Jones authored
      This change adds a suggestion
          Possible fix: add a type signature for ‘f’
      when we have a GADT-style definition with a
      type we can't figure out.
      
      See Note [Suggest adding a type signature] in TcErrors.
      
      This initially came up in the discussion of Trac #8968.
      50bfd421
  11. 14 Mar, 2014 1 commit
  12. 13 Feb, 2014 1 commit
  13. 09 Jan, 2014 1 commit
  14. 04 Dec, 2013 1 commit
  15. 03 Dec, 2013 1 commit
  16. 02 Dec, 2013 1 commit
  17. 22 Nov, 2013 6 commits
  18. 20 Nov, 2013 1 commit
    • Joachim Breitner's avatar
      Make Coercible higher-kinded · 976a1087
      Joachim Breitner authored
      This implements #8541. The changes are fully straight forward and work
      nicely for the examples from the ticket; this is mostly due to the
      existing code not checking for saturation and kindness.
      976a1087
  19. 06 Nov, 2013 2 commits
    • Simon Peyton Jones's avatar
      Improve printing of errors when the tycons look the same · 2403fa10
      Simon Peyton Jones authored
      See Trac #8278.  Example new message:
      
          Couldn't match expected type ‛T8278a.Maybe’
                      with actual type ‛Maybe a0’
          NB: ‛T8278a.Maybe’ is defined in ‛T8278a’
              ‛Maybe’ is defined in ‛Data.Maybe’ in package ‛base’
          In the first argument of ‛f’, namely ‛Nothing’
      
      The "NB" is the new bit
      2403fa10
    • Simon Peyton Jones's avatar
      Refactor the constraint solver (again!) · 06aac68d
      Simon Peyton Jones authored
      There are three core changes here:
      
      a) In the constraint-solver pipeline.
         Given a work-item 'wi', the old scheme was:
            let relevant = getRelevantInerts wi
            interact 'wi' with each constraint in 'relevant'
         Bu now we have a single step
            interact 'wi' with the inert-set
      
         This turns out to avoid duplication, between getRelevantInerts
         (which needs to know which are relevant) and the interact step.
         Simpler, cleaner.
      
         This in turn made it sensible to combine the 'spontaneous solve'
         stage into the 'interact with inerts' stage.
      
      b) Wanteds are no longer used to rewrite wanteds.  See Trac #8450.
         This in turn means that the inert set may have
           - many CFunEqCans with the same LHS
           - many CTyEqCans  with the same LHS
         Hence the EqualCtList in teh domain of inert_eqs and inert_funeqs
      
      c) Some refactoring of the representation of the inert set,
         Notably inert_dicts and inert_funeqs are indexed by Class and TyCon
         respectively, so we can easily get all the constraints relevant to
         that class or tycon
      
      There are many knock on effects!  This started as a small job but I
      ended up doing qite a lot.  Some error messages in the test suite
      really did improve as a result of (b)
      06aac68d
  20. 01 Oct, 2013 1 commit
  21. 14 Sep, 2013 1 commit
  22. 13 Sep, 2013 1 commit
  23. 10 Sep, 2013 1 commit
    • Simon Peyton Jones's avatar
      Improve error reporting for "relevant bindings" again (Trac #8233) · 9039108b
      Simon Peyton Jones authored
      This patch makes a number of related improvements:
      
      * Displays relevant bindings in innermost-first order.
        The inner ones are closer to the error.
      
      * Does not display syntactically top-level bindings,
        unless you say -fno-max-relevant-bindings.
        This is what Trac #8233 was mainly about
      
      * Makes the TopLevelFlag in a TcIdBinder really mean
        "syntactically top level".  It was a bit vague before.
      
      There was some associated simplification, because we no longer
      need to pas a TopLevelFlag to tcMonoBinds and friends.
      9039108b
  24. 29 Aug, 2013 1 commit
  25. 23 Apr, 2013 1 commit
  26. 22 Apr, 2013 1 commit
    • Simon Peyton Jones's avatar
      Further wibbbling to type error message reporting · 2a7f4de3
      Simon Peyton Jones authored
      * We now never report derived-constraint type errors, even
        in the "insolubles".  See Note [Insoluble derived constraints]
        in TcRnTypes.
      
      * The cec_suppress mechanism in TcErrors is refactored a bit so that:
         - We suppress *all* errors in unreachable code (they can be jolly
           confusing)
         - We no longer suppress *all* non-insoluble errors if there are *any
           insolubles anywhere.  Instead we are a bit more refined.
        See Note [Suppressing error messages] in TcErrors
      2a7f4de3
  27. 21 Apr, 2013 1 commit
  28. 14 Feb, 2013 1 commit
  29. 30 Jan, 2013 1 commit