1. 02 Mar, 2018 1 commit
    • shlevy's avatar
      Make cost centre symbol names deterministic. · d8e47a2e
      shlevy authored
      Previously, non-CAF cost centre symbol names contained a unique,
      leading to non-deterministic object files which, among other issues,
      can lead to an inconsistency causing linking failure when using cached
      builds sourced from multiple machines, such as with nix. Now, each
      cost centre symbol is annotated with the type of cost centre it
      is (CAF, expression annotation, declaration annotation, or HPC) and,
      when a single module has multiple cost centres with the same name and
      type, a 0-based index.
      
      Reviewers: bgamari, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: niteria, simonmar, RyanGlScott, osa1, rwbarton, thomie, carter
      
      GHC Trac Issues: #4012, #12935
      
      Differential Revision: https://phabricator.haskell.org/D4388
      d8e47a2e
  2. 18 Feb, 2018 1 commit
    • Matthías Páll Gissurarson's avatar
      Add valid refinement substitution suggestions for typed holes · 918c0b39
      Matthías Páll Gissurarson authored
      This adds valid refinement substitution suggestions for typed holes and
      documentation thereof.
      
      Inspired by Agda's refinement facilities, this extends the typed holes
      feature to be able to search for valid refinement substitutions, which
      are substitutions that have one or more holes in them.
      
      When the flag `-frefinement-level-substitutions=n` where `n > 0` is
      passed, we also look for valid refinement substitutions, i.e.
      substitutions that are valid, but adds more holes. Consider the
      following:
      
        f :: [Integer] -> Integer
        f = _
      
      Here the valid substitutions suggested will be (with the new
      `-funclutter-valid-substitutions` flag for less verbosity set):
      
      ```
        Valid substitutions include
          f :: [Integer] -> Integer
          product :: forall (t :: * -> *).
                    Foldable t => forall a. Num a => t a -> a
          sum :: forall (t :: * -> *).
                Foldable t => forall a. Num a => t a -> a
          maximum :: forall (t :: * -> *).
                    Foldable t => forall a. Ord a => t a -> a
          minimum :: forall (t :: * -> *).
                    Foldable t => forall a. Ord a => t a -> a
          head :: forall a. [a] -> a
          (Some substitutions suppressed; use -fmax-valid-substitutions=N or
      -fno-max-valid-substitutions)
      ```
      
      When the `-frefinement-level-substitutions=1` flag is given, we
      additionally compute and report valid refinement substitutions:
      
      ```
        Valid refinement substitutions include
          foldl1 _ :: forall (t :: * -> *).
                      Foldable t => forall a. (a -> a -> a) -> t a -> a
          foldr1 _ :: forall (t :: * -> *).
                      Foldable t => forall a. (a -> a -> a) -> t a -> a
          head _ :: forall a. [a] -> a
          last _ :: forall a. [a] -> a
          error _ :: forall (a :: TYPE r).
                      GHC.Stack.Types.HasCallStack => [Char] -> a
          errorWithoutStackTrace _ :: forall (a :: TYPE r). [Char] -> a
          (Some refinement substitutions suppressed; use
      -fmax-refinement-substitutions=N or -fno-max-refinement-substitutions)
      ```
      
      Which are substitutions with holes in them. This allows e.g. beginners
      to discover the fold functions and similar.
      
      We find these refinement suggestions by considering substitutions that
      don't fit the type of the hole, but ones that would fit if given an
      additional argument. We do this by creating a new type variable with
      newOpenFlexiTyVarTy (e.g. `t_a1/m[tau:1]`), and then considering
      substitutions of the type `t_a1/m[tau:1] -> v` where `v` is the type of
      the hole. Since the simplifier is free to unify this new type variable
      with any type (and it is cloned before each check to avoid
      side-effects), we can now discover any identifiers that would fit if
      given another identifier of a suitable type. This is then generalized
      so that we can consider any number of additional arguments by setting
      the `-frefinement-level-substitutions` flag to any number, and then
      considering substitutions like e.g. `foldl _ _` with two additional
      arguments.
      
      This can e.g. help beginners discover the `fold` functions.
      This could also help more advanced users figure out which morphisms
      they can use when arrow chasing.
      Then you could write `m = _ . m2 . m3` where `m2` and `m3` are some
      morphisms, and not only get exact fits, but also help in finding
      morphisms that might get you a little bit closer to where you want to
      go in the diagram.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4357
      918c0b39
  3. 08 Feb, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix isDroppableCt (Trac #14763) · 6edafe3b
      Simon Peyton Jones authored
      When finishing up an implication constraint, it's a bit tricky to
      decide which Derived constraints to retain (for error reporting) and
      which to discard.  I got this wrong in commit
         f20cf982
         (Remove wc_insol from WantedConstraints)
      
      The particular problem in Trac #14763 was that we were reporting as an
      error a fundep-generated constraint
        (ex ~ T)
      where 'ex' is an existentially-bound variable in a pattern match.
      But this isn't really an error at all.
      
      This patch fixes the problem. Indeed, since I had to understand
      this rather tricky code, I took the opportunity to clean it up
      and document better.  See
        isDroppableCt :: Ct -> Bool
      and Note [Dropping derived constraints]
      
      I also removed wl_deriv altogether from the WorkList data type.  It
      was there in the hope of gaining efficiency by not even processing
      lots of derived constraints, but it has turned out that most derived
      constraints (notably equalities) must be processed anyway; see
      Note [Prioritise equalities] in TcSMonad.
      
      The two are coupled because to decide which constraints to put in
      wl_deriv I was using another variant of isDroppableCt.  Now it's much
      simpler -- and perhaps even more efficient too.
      6edafe3b
  4. 31 Jan, 2018 1 commit
  5. 26 Jan, 2018 1 commit
    • Joachim Breitner's avatar
      Turn EvTerm (almost) into CoreExpr (#14691) · 0e022e56
      Joachim Breitner authored
      Ideally, I'd like to do
      
          type EvTerm = CoreExpr
      
      and the type checker builds the evidence terms as it goes. This failed,
      becuase the evidence for `Typeable` refers to local identifiers that are
      added *after* the typechecker solves constraints. Therefore, `EvTerm`
      stays a data type with two constructors: `EvExpr` for `CoreExpr`
      evidence, and `EvTypeable` for the others.
      
      Delted `Note [Memoising typeOf]`, its reference (and presumably
      relevance) was removed in 8fa4bf9a.
      
      Differential Revision: https://phabricator.haskell.org/D4341
      0e022e56
  6. 23 Jan, 2018 1 commit
    • niteria's avatar
      Allocate less in plus_mod_dep · f00ddea9
      niteria authored
      This gives a 10% allocation improvement on MultiLayerModules.
      The idea is to reuse existing tuples, instead of constantly
      constructing new ones.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: rwbarton, thomie, simonmar, carter
      
      Differential Revision: https://phabricator.haskell.org/D4332
      f00ddea9
  7. 22 Jan, 2018 1 commit
  8. 18 Jan, 2018 1 commit
    • Matthías Páll Gissurarson's avatar
      Inform hole substitutions of typeclass constraints (fixes #14273). · 1e14fd3e
      Matthías Páll Gissurarson authored
      This implements SPJ's suggestion on the ticket (#14273). We find the
      relevant constraints (ones that whose free unification variables are all
      mentioned in the type of the hole), and then clone the free unification
      variables of the hole and the relevant constraints. We then add a
      subsumption constraints and run the simplifier, and then check whether
      all the constraints were solved.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: RyanGlScott, rwbarton, thomie, carter
      
      GHC Trac Issues: #14273
      
      Differential Revision: https://phabricator.haskell.org/D4315
      1e14fd3e
  9. 04 Jan, 2018 1 commit
    • Simon Peyton Jones's avatar
      Drop dead Given bindings in setImplicationStatus · 954cbc7c
      Simon Peyton Jones authored
      Trac #13032 pointed out that we sometimes generate unused
      bindings for Givens, and (worse still) we can't always discard
      them later (we don't drop a case binding unless we can prove
      that the scrutinee is non-bottom.
      
      It looks as if this may be a major reason for the performace
      problems in #14338 (see comment:29).
      
      This patch fixes the problem at source, by pruning away all the
      dead Givens.  See Note [Delete dead Given evidence bindings]
      
      Remarkably, compiler allocation falls by 23% in
      perf/compiler/T12227!
      
      I have not confirmed whether this change actualy helps with
      954cbc7c
  10. 21 Dec, 2017 1 commit
    • Simon Peyton Jones's avatar
      Refactor coercion holes · a492af06
      Simon Peyton Jones authored
      In fixing Trac #14584 I found that it would be /much/ more
      convenient if a "hole" in a coercion (much like a unification
      variable in a type) acutally had a CoVar associated with it
      rather than just a Unique.  Then I can ask what the free variables
      of a coercion is, and get a set of CoVars including those
      as-yet-un-filled in holes.
      
      Once that is done, it makes no sense to stuff coercion holes
      inside UnivCo.  They were there before so we could know the
      kind and role of a "hole" coercion, but once there is a CoVar
      we can get that info from the CoVar.  So I removed HoleProv
      from UnivCoProvenance and added HoleCo to Coercion.
      
      In summary:
      
      * Add HoleCo to Coercion and remove HoleProv from UnivCoProvanance
      
      * Similarly in IfaceCoercion
      
      * Make CoercionHole have a CoVar in it, not a Unique
      
      * Make tyCoVarsOfCo return the free coercion-hole variables
        as well as the ordinary free CoVars.  Similarly, remember
        to zonk the CoVar in a CoercionHole
      
      We could go further, and remove CoercionHole as a distinct type
      altogther, just collapsing it into HoleCo.  But I have not done
      that yet.
      a492af06
  11. 18 Dec, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix scoping of pattern-synonym existentials · f1fe5b4a
      Simon Peyton Jones authored
      This patch fixes Trac #14998, where we eventually decided that
      the existential type variables of the signature of a pattern
      synonym should not scope over the pattern synonym.
      
      See Note [Pattern synonym existentials do not scope] in TcPatSyn.
      f1fe5b4a
  12. 01 Dec, 2017 1 commit
    • Edward Z. Yang's avatar
      Make use of boot TyThings during typechecking. · 69987720
      Edward Z. Yang authored
      Summary:
      Suppose that you are typechecking A.hs, which transitively imports,
      via B.hs, A.hs-boot.  When we poke on B.hs and discover that it
      has a reference to a type from A, what TyThing should we wire
      it up with?  Clearly, if we have already typechecked A, we
      should use the most up-to-date TyThing: the one we freshly
      generated when we typechecked A.  But what if we haven't typechecked
      it yet?
      
      For the longest time, GHC adopted the policy that this was
      *an error condition*; that you MUST NEVER poke on B.hs's reference
      to a thing defined in A.hs until A.hs has gotten around to checking
      this.  However, actually ensuring this is the case has proven
      to be a bug farm.  The problem was especially poignant with
      type family consistency checks, which eagerly happen before
      any typechecking takes place.
      
      This patch takes a different strategy: if we ever try to access
      an entity from A which doesn't exist, we just fall back on the
      definition of A from the hs-boot file.  This means that you may
      end up with a mix of A.hs and A.hs-boot TyThings during the
      course of typechecking.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@fb.com>
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari, austin, goldfire
      
      Subscribers: thomie, rwbarton
      
      GHC Trac Issues: #14396
      
      Differential Revision: https://phabricator.haskell.org/D4154
      69987720
  13. 21 Nov, 2017 1 commit
    • Ben Gamari's avatar
      Revert "trees that grow" work · 314bc314
      Ben Gamari authored
      As documented in #14490, the Data instances currently blow up
      compilation time by too much to stomach. Alan will continue working on
      this in a branch and we will perhaps merge to 8.2 before 8.2.1 to avoid
      having to perform painful cherry-picks in 8.2 minor releases.
      
      Reverts haddock submodule.
      
      This reverts commit 47ad6578.
      This reverts commit e3ec2e7a.
      This reverts commit 438dd1cb.
      This reverts commit 0ff152c9.
      314bc314
  14. 15 Nov, 2017 1 commit
  15. 11 Nov, 2017 1 commit
  16. 30 Oct, 2017 1 commit
  17. 20 Oct, 2017 1 commit
    • Simon Peyton Jones's avatar
      Improve kick-out in the constraint solver · 3acd6164
      Simon Peyton Jones authored
      This patch was provoked by Trac #14363.  Turned out that we were
      kicking out too many constraints in TcSMonad.kickOutRewritable, and
      that mean that the work-list never became empty: infinite loop!
      
      That in turn made me look harder at the Main Theorem in
      Note [Extending the inert equalities].
      
      Main changes
      
      * Replace TcType.isTyVarExposed by TcType.isTyVarHead.  The
        over-agressive isTyVarExposed is what caused Trac #14363.
        See Note [K3: completeness of solving] in TcSMonad.
      
      * TcType.Make anyRewriteableTyVar role-aware.  In particular,
            a ~R ty
        cannot rewrite
            b ~R f a
        See Note [anyRewriteableTyVar must be role-aware].  That means
        it has to be given a role argument, which forces a little
        refactoring.
      
        I think this change is fixing a bug that hasn't yet been reported.
        The actual reported bug is handled by the previous bullet.  But
        this change is definitely the Right Thing
      
      The main changes are in TcSMonad.kick_out_rewritable, and in TcType
      (isTyVarExposed ---> isTyVarHead).
      
      I did a little unforced refactoring:
      
       * Use the cc_eq_rel field of a CTyEqCan when it is available, rather
         than recomputing it.
      
       * Define eqCanRewrite :: EqRel -> EqRel -> EqRel, and use it, instead
         of duplicating its logic
      3acd6164
  18. 11 Oct, 2017 2 commits
    • Simon Peyton Jones's avatar
      Remove wc_insol from WantedConstraints · f20cf982
      Simon Peyton Jones authored
      This patch is a pure refactoring, which I've wanted to do for
      some time.  The main payload is
      
      * Remove the wc_insol field from WantedConstraints;
        instead put all the insolubles in wc_simple
      
      * Remove inert_insols from InertCans
        Instead put all the insolubles in inert_irreds
      
      * Add a cc_insol flag to CIrredCan, to record that
        the constraint is definitely insoluble
      
      Reasons
      
      * Quite a bit of code gets slightly simpler
      * Fewer concepts to keep separate
      * Insolubles don't happen at all in production code that is
        just being recompiled, so previously there was a lot of
        moving-about of empty sets
      
      A couple of error messages acutally improved.
      f20cf982
    • Simon Peyton Jones's avatar
      Fix over-eager error suppression in TcErrors · c81f66cc
      Simon Peyton Jones authored
      See Note [Given insolubles] in TcRnTypes
      
      Fixes Trac #14325.
      c81f66cc
  19. 27 Sep, 2017 1 commit
  20. 26 Sep, 2017 1 commit
  21. 25 Sep, 2017 1 commit
    • Simon Peyton Jones's avatar
      Improve type-error reporting · 1b476ab5
      Simon Peyton Jones authored
      This patch does two things:
      
      * When reporting a hole, we now include its kind if the
        kind is not just '*'.  This addresses Trac #14265
      
      * When reporting things like "'a' is a rigid type varaible
        bound by ...", this patch arranges to group the type variables
        together, so we don't repeat the "bound by..." stuff endlessly
      1b476ab5
  22. 22 Sep, 2017 1 commit
    • Facundo Domínguez's avatar
      Implement TH addCorePlugin. · 17558690
      Facundo Domínguez authored
      This allows template-haskell code to add plugins to the compilation
      pipeline. Otherwise, the user would have to pass -fplugin=... to ghc.
      
      For now, plugin modules in the current package can't be used. This is
      because when TH runs, it is too late to let GHC know that the plugin
      modules needed to be compiled first.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari, austin, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: angerman, rwbarton, mboes, thomie
      
      GHC Trac Issues: #13608
      
      Differential Revision: https://phabricator.haskell.org/D3821
      17558690
  23. 21 Sep, 2017 1 commit
    • Matthías Páll Gissurarson's avatar
      Also show types that subsume a hole as valid substitutions for that hole. · 1c920832
      Matthías Páll Gissurarson authored
      This builds on the previous "Valid substitutions include..." functionality,
      but add subsumption checking as well, so that the suggested valid substitutions
      show not only exact matches, but also identifiers that fit the hole by virtue of
      subsuming the type of the hole (i.e. being more general than the type of the
      hole).
      
      Building on the previous example, in the given program
      
      ```
      ps :: String -> IO ()
      ps = putStrLn
      
      ps2 :: a -> IO ()
      ps2 _ = putStrLn "hello, world"
      
      main :: IO ()
      main = _ "hello, world"
      ```
      
      The results would be something like
      
      ```
          • Found hole: _ :: [Char] -> IO ()
          • In the expression: _
            In the expression: _ "hello, world"
            In an equation for ‘main’: main = _ "hello, world"
          • Relevant bindings include main :: IO () (bound at t1.hs:8:1)
            Valid substitutions include
              ps :: String -> IO () (defined at t1.hs:2:1)
              ps2 :: forall a. a -> IO () (defined at t1.hs:5:1)
              putStrLn :: String -> IO ()
                (imported from ‘Prelude’ at t1.hs:1:1
                 (and originally defined in ‘System.IO’))
              fail :: forall (m :: * -> *). Monad m => forall a. String -> m a
                (imported from ‘Prelude’ at t1.hs:1:1
                 (and originally defined in ‘GHC.Base’))
              mempty :: forall a. Monoid a => a
                (imported from ‘Prelude’ at t1.hs:1:1
                 (and originally defined in ‘GHC.Base’))
              print :: forall a. Show a => a -> IO ()
                (imported from ‘Prelude’ at t1.hs:1:1
                 (and originally defined in ‘System.IO’))
              (Some substitutions suppressed;
               use -fmax-valid-substitutions=N or -fno-max-valid-substitutions)
      ```
      Signed-off-by: Matthías Páll Gissurarson's avatarMatthías Páll Gissurarson <mpg@mpg.is>
      
      Modified according to suggestions from Simon PJ
      
      Accept tests that match the expectations, still a few to look better at
      
      Swithced to using tcLookup, after sit down with SPJ at ICFP. Implications are WIP.
      
      Now works with polymorphism and constraints!
      
      We still need to merge the latest master, before we can make a patch.
      
      Wrap the type of the hole, instead of implication shenanigans,
      
      As per SPJs suggestion, this is simpler and feels closer to
      what we actually want to do.
      
      Updated tests with the new implementation
      
      Remove debugging trace and update documentation
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: RyanGlScott, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3930
      1c920832
  24. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  25. 14 Sep, 2017 1 commit
    • Simon Peyton Jones's avatar
      Tidying could cause ill-kinded types · 8bf865d3
      Simon Peyton Jones authored
      I found (Trac #14175) that the tidying we do when reporting
      type error messages could cause a well-kinded type to become
      ill-kinded. Reason: we initialised the tidy-env with a
      completely un-zonked TidyEnv accumulated in the TcLclEnv
      as we come across lexical type-varialbe bindings.
      
      Solution: zonk them.
      
      But I ended up refactoring a bit:
      
      * Get rid of tcl_tidy :: TidyEnv altogether
      
      * Instead use tcl_bndrs :: TcBinderStack
        This used to contain only Ids, but now I've added those
        lexically scoped TyVars too.
      
      * Change names:
           TcIdBinderStack -> TcBinderStack
           TcIdBinder      -> TcBinder
           extendTcIdBndrs -> extendTcBinderStack
      
      * Now tcInitTidyEnv can grab those TyVars from the
        tcl_bndrs, zonk, and tidy them.
      
      The only annoyance is that I had to add TcEnv.hs-boot, to
      break the recursion between the zonking code and the
      TrRnMonad functions like addErrTc that call tcInitTidyEnv.
      Tiresome, but in fact that file existed already.
      8bf865d3
  26. 09 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Canonicalise MonoidFail instances in GHC · 346e562a
      Herbert Valerio Riedel authored
      IOW, code compiles -Wnoncanonical-monoidfail-instances clean now
      
      This is easy now since we require GHC 8.0/base-4.9 or later
      for bootstrapping.
      
      Note that we can easily enable `MonadFail` via
      
        default-extensions: MonadFailDesugaring
      
      in compiler/ghc.cabal.in
      
      which currently would point out that NatM doesn't have
      a proper `fail` method, even though failable patterns
      are made use of:
      
        compiler/nativeGen/SPARC/CodeGen.hs:425:25: error:
          * No instance for (Control.Monad.Fail.MonadFail NatM)
              arising from a do statement
              with the failable pattern ‘(dyn_c, [dyn_r])’
      346e562a
  27. 05 Sep, 2017 1 commit
  28. 31 Aug, 2017 1 commit
    • Simon Peyton Jones's avatar
      Add debugPprType · 805b29bb
      Simon Peyton Jones authored
      We pretty-print a type by converting it to an IfaceType and
      pretty-printing that.  But
       (a) that's a bit indirect, and
       (b) delibrately loses information about (e.g.) the kind
            on the /occurrences/ of a type variable
      
      So this patch implements debugPprType, which pretty prints
      the type directly, with no fancy formatting.  It's just used
      for debugging.
      
      I took the opportunity to refactor the debug-pretty-printing
      machinery a little.  In particular, define these functions
      and use them:
      
        ifPprDeubug :: SDoc -> SDOc -> SDoc
          -- Says what to do with and without -dppr-debug
        whenPprDebug :: SDoc -> SDoc
          -- Says what to do with  -dppr-debug; without is empty
        getPprDebug :: (Bool -> SDoc) -> SDoc
      
      getPprDebug used to be called sdocPprDebugWith
      whenPprDebug used to be called ifPprDebug
      
      So a lot of files get touched in a very mechanical way
      805b29bb
  29. 25 Aug, 2017 1 commit
  30. 24 Aug, 2017 1 commit
  31. 01 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Drop GHC 7.10 compatibility · c13720c8
      Ryan Scott authored
      GHC 8.2.1 is out, so now GHC's support window only extends back to GHC
      8.0. This means we can delete gobs of code that was only used for GHC
      7.10 support. Hooray!
      
      Test Plan: ./validate
      
      Reviewers: hvr, bgamari, austin, goldfire, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: Phyx, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3781
      c13720c8
  32. 28 Jul, 2017 1 commit
    • Simon Peyton Jones's avatar
      Do not discard insolubles in implications · 452755de
      Simon Peyton Jones authored
      Trac #14000 showed up two errors
      
      * In TcRnTypes.dropInsolubles we dropped all implications, which
        might contain the very insolubles we wanted to keep.  This was
        an outright error, and is why the out-of-scope error was actually
        lost altogether in Trac #14000
      
      * In TcSimplify.simplifyInfer, if there are definite (insoluble)
        errors, it's better to suppress the following ambiguity test,
        because the type may be bogus anyway.  See TcSimplify
        Note [Quantification with errors].  This fix seems a bit clunky,
        but it'll do for now.
      452755de
  33. 27 Jul, 2017 3 commits
    • Richard Eisenberg's avatar
      Track visibility in TypeEqOrigin · fb752133
      Richard Eisenberg authored
      A type equality error can arise from a mismatch between
      *invisible* arguments just as easily as from visible arguments.
      But we should really prefer printing out errors from visible
      arguments over invisible ones. Suppose we have a mismatch between
      `Proxy Int` and `Proxy Maybe`. Would you rather get an error
      between `Int` and `Maybe`? Or between `*` and `* -> *`? I thought
      so, too.
      
      There is a fair amount of plumbing with this one, but I think
      it's worth it.
      
      This commit introduces a performance regression in test
      perf/compiler/T5631. The cause of the regression is not the
      new visibility stuff, directly: it's due to a change from
      zipWithM to zipWith3M in TcUnify. To my surprise, zipWithM
      is nicely optimized (it fuses away), but zipWith3M is not.
      There are other examples of functions that could be made faster,
      so I've posted a separate ticket, #14037, to track these
      improvements. For now, I've accepted the small (6.6%) regression.
      fb752133
    • Richard Eisenberg's avatar
      Fix #13819 by refactoring TypeEqOrigin.uo_thing · c2417b87
      Richard Eisenberg authored
      The uo_thing field of TypeEqOrigin is used to track the
      "thing" (either term or type) that has the type (kind) stored
      in the TypeEqOrigin fields. Previously, this was sometimes a
      proper Core Type, which needed zonking and tidying. Now, it
      is only HsSyn: much simpler, and the error messages now use
      the user-written syntax.
      
      But this aspect of uo_thing didn't cause #13819; it was the
      sibling field uo_arity that did. uo_arity stored the number
      of arguments of uo_thing, useful when reporting something
      like "should have written 2 fewer arguments". We wouldn't want
      to say that if the thing didn't have two arguments. However,
      in practice, GHC was getting this wrong, and this message
      didn't seem all that helpful. Furthermore, the calculation
      of the number of arguments is what caused #13819 to fall over.
      This patch just removes uo_arity. In my opinion, the change
      to error messages is a nudge in the right direction.
      
      Test case: typecheck/should_fail/T13819
      c2417b87
    • Richard Eisenberg's avatar
      Improve error messages around kind mismatches. · 8e15e3d3
      Richard Eisenberg authored
      Previously, when canonicalizing (or unifying, in uType) a
      heterogeneous equality, we emitted a kind equality and used the
      resulting coercion to cast one side of the heterogeneous equality.
      
      While sound, this led to terrible error messages. (See the bugs
      listed below.) The problem is that using the coercion built from
      the emitted kind equality is a bit like a wanted rewriting a wanted.
      The solution is to keep heterogeneous equalities as irreducible.
      
      See Note [Equalities with incompatible kinds] in TcCanonical.
      
      This commit also removes a highly suspicious switch to FM_SubstOnly
      when flattening in the kinds of a type variable. I have no idea
      why this was there, other than as a holdover from pre-TypeInType.
      I've not left a Note because there is simply no reason I can conceive
      of that the FM_SubstOnly should be there.
      
      One challenge with this patch is that the emitted derived equalities
      might get emitted several times: when a heterogeneous equality is
      in an implication and then gets floated out from the implication,
      the Derived is present both in and out of the implication. This
      causes a duplicate error message. (Test case:
      typecheck/should_fail/T7368) Solution: track the provenance of
      Derived constraints and refuse to float out a constraint that has
      an insoluble Derived.
      
      Lastly, this labels one test (dependent/should_fail/RAE_T32a)
      as expect_broken, because the problem is really #12919. The
      different handling of constraints in this patch exposes the error.
      
      This fixes bugs #11198, #12373, #13530, and #13610.
      
      test cases:
      typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610}
      8e15e3d3
  34. 26 Jul, 2017 1 commit
  35. 20 Jul, 2017 1 commit
  36. 28 Jun, 2017 1 commit
  37. 16 Jun, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix the treatment of 'closed' definitions · dc8e6861
      Simon Peyton Jones authored
      The IdBindingInfo field of ATcId serves two purposes
      
      - to control generalisation when we have -XMonoLocalBinds
      - to check for floatability when dealing with (static e)
      
      These are related, but not the same, and they'd becomme confused.
      Trac #13804 showed this up via an example like this:
      
        f periph = let sr :: forall a. [a] -> [a]
                       sr = if periph then reverse else id
      
                       sr2 = sr
                       -- The question: is sr2 generalised?
                       -- It should be, because sr has a type sig
                       -- even though it has periph free
                   in
                   (sr2 [True], sr2 "c")
      
      Here sr2 should be generalised, despite the free var 'periph'
      in 'sr' because 'sr' has a closed type signature.
      
      I documented all this very carefully this time, in TcRnTypes:
        Note [Meaning of IdBindingInfo]
        Note [Bindings with closed types: ClosedTypeId]
      dc8e6861