1. 21 Dec, 2017 3 commits
    • Gabor Greif's avatar
      Typos in comments · bcb519c5
      Gabor Greif authored
      bcb519c5
    • Simon Peyton Jones's avatar
      Fix floating of equalities · f5cf9d1a
      Simon Peyton Jones authored
      This rather subtle patch fixes Trac #14584.  The problem was
      that we'd allowed a coercion, bound in a nested scope, to escape
      into an outer scope.
      
      The main changes are
      
      * TcSimplify.floatEqualities takes more care when floating
        equalities to make sure we don't float one out that mentions
        a locally-bound coercion.
        See Note [What prevents a constraint from floating]
      
      * TcSimplify.emitResidualConstraints (which emits the residual
        constraints in simplifyInfer) now avoids burying the constraints
        for escaping CoVars inside the implication constraint.
      
      * Since I had do to this stuff with CoVars, I moved the
        fancy footwork about not quantifying over CoVars from
        TcMType.quantifyTyVars to its caller
        TcSimplify.decideQuantifiedTyVars.  I think its other
        callers don't need to worry about all this CoVar stuff.
      
      This turned out to be surprisigly tricky, and took me a solid
      day to get right.  I think the result is reasonably neat, though,
      and well documented with Notes.
      f5cf9d1a
    • Simon Peyton Jones's avatar
      Check for bogus quantified tyvars in partial type sigs · 72938f58
      Simon Peyton Jones authored
      This fixes Trac #14479.  Not difficult.
      
      See Note [Quantification and partial signatures] Wrinkle 4,
      in TcSimplify.
      72938f58
  2. 11 Dec, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix SigTvs at the kind level · 8361b2c5
      Simon Peyton Jones authored
      This patch fixes two bugs in the treatment of SigTvs at the
      kind level:
      
      - We should always generalise them, never default them
        (Trac #14555, #14563)
      
      - We should check if they get unified with each other
        (Trac #11203)
      
      Both are described in TcHsType
         Note [Kind generalisation and SigTvs]
      8361b2c5
  3. 08 Nov, 2017 1 commit
    • Simon Peyton Jones's avatar
      Minimise provided dictionaries in pattern synonyms · 2c2f3cea
      Simon Peyton Jones authored
      Trac #14394 showed that it's possible to get redundant
      constraints in the inferred provided constraints of a pattern
      synonym.  This patch removes the redundancy with mkMinimalBySCs.
      
      To do this I had to generalise the type of mkMinimalBySCs slightly.
      And, to reduce confusing reversal, I made it stable: it now returns
      its result in the same order as its input.  That led to a raft of
      error message wibbles, mostly for the better.
      2c2f3cea
  4. 11 Oct, 2017 1 commit
    • 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
  5. 25 Sep, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix solving of implicit parameter constraints · abed9bf5
      Simon Peyton Jones authored
      Trac #14218 showed that we were not solving implicit-parameter
      constraints correctly.  In particular,
      
      - A tuple constraint could "hide" an implicit-parameter wanted
        constraint, and that in turn could that we solved it from the
        wrong implicit-parameter binding.
      
      - As a special case the HasCallStack constraint (which is just
        short for (IP "callStack" CallStack), was getting mis-solved.
      
      The big change is to arrange that, in TcSMonad.findDict when looking
      for a dictionary, either when looking for a matching inert or solved
      dictionary, we fail for
      
        - Tuples that are hiding implicit parameters
          See Note [Tuples hiding implicit parameters]
      
        - HasCallStack constraints where we have not yet pushed
          on the call-site info
          See Note [Solving CallStack constraints]
      
      I also did a little refactoring
      
      * Move naturallyCoherentClass from Class to TcInteract, its sole
        use site.  Class.hs seems like the wrong place.  (And I also
        do not understand the reason that we need the eq/Coercible/
        Typable stuff in this predicate, but I'll tackle that separately.)
      
      * Move the code that pushes call-site info onto a call stack
        from the "interact" part to the "canonicalise" part of the solver.
      abed9bf5
  6. 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 and Ben Gamari's avatar Ben Gamari committed
      
      
      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
  7. 19 Sep, 2017 2 commits
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored and Ben Gamari's avatar Ben Gamari committed
      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
    • Simon Peyton Jones's avatar
      Fix unused-given-constraint bug · 1db0f4a4
      Simon Peyton Jones authored
      This bug was shown up by Trac #14237.  It turned out
      to be an outright error in TcSimplify.neededEvVars,
      easily fixed.
      
      I improved the comments.
      1db0f4a4
  8. 12 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Use NonEmpty lists to represent lists of duplicate elements · 7d699782
      Ryan Scott authored
      Summary:
      Three functions in `ListSetOps` which compute duplicate elements
      represent lists of duplicates of `[a]`. This is a really bad way to go about
      things, because these lists are guaranteed to always have at least one element
      (the "representative" of the duplicates), and several places in the GHC API
      call `head` (a partial function) on these lists of duplicates to retrieve the
      representative.
      
      This changes the representation of duplicates to `NonEmpty` lists instead,
      which allow for many partial uses of `head` to be made total.
      
      Fixes #13823.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie
      
      GHC Trac Issues: #13823
      
      Differential Revision: https://phabricator.haskell.org/D3823
      7d699782
  9. 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
  10. 27 Jul, 2017 1 commit
    • 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
  11. 05 Jun, 2017 2 commits
    • Alan Zimmerman's avatar
      Udate hsSyn AST to use Trees that Grow · 8e6ec0fa
      Alan Zimmerman authored
      Summary:
      See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
      
      This commit prepares the ground for a full extensible AST, by replacing the type
      parameter for the hsSyn data types with a set of indices into type families,
      
          data GhcPs -- ^ Index for GHC parser output
          data GhcRn -- ^ Index for GHC renamer output
          data GhcTc -- ^ Index for GHC typechecker output
      
      These are now used instead of `RdrName`, `Name` and `Id`/`TcId`/`Var`
      
      Where the original name type is required in a polymorphic context, this is
      accessible via the IdP type family, defined as
      
          type family IdP p
          type instance IdP GhcPs = RdrName
          type instance IdP GhcRn = Name
          type instance IdP GhcTc = Id
      
      These types are declared in the new 'hsSyn/HsExtension.hs' module.
      
      To gain a better understanding of the extension mechanism, it has been applied
      to `HsLit` only, also replacing the `SourceText` fields in them with extension
      types.
      
      To preserve extension generality, a type class is introduced to capture the
      `SourceText` interface, which must be honoured by all of the extension points
      which originally had a `SourceText`.  The class is defined as
      
          class HasSourceText a where
            -- Provide setters to mimic existing constructors
            noSourceText  :: a
            sourceText    :: String -> a
      
            setSourceText :: SourceText -> a
            getSourceText :: a -> SourceText
      
      And the constraint is captured in `SourceTextX`, which is a constraint type
      listing all the extension points that make use of the class.
      
      Updating Haddock submodule to match.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, shayan-najd, goldfire, austin, bgamari
      
      Subscribers: rwbarton, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3609
      8e6ec0fa
    • Simon Peyton Jones's avatar
      Make the MR warning more accurage · a65dfea5
      Simon Peyton Jones authored
      Trac #13785 showed that we were emitting monomorphism warnings
      when we shouldn't.  The fix turned out to be simple.
      
      In fact test T10935 then turned out to be another example of
      the over-noisy warning so I changed the test slightly.
      a65dfea5
  12. 26 May, 2017 2 commits
    • Gabor Greif's avatar
      Typos in comments [ci skip] · 19c4203f
      Gabor Greif authored
      19c4203f
    • Simon Peyton Jones's avatar
      Re-engineer Given flatten-skolems · 8dc6d645
      Simon Peyton Jones authored
      The big change here is to fix an outright bug in flattening of Givens,
      albeit one that is very hard to exhibit.  Suppose we have the constraint
          forall a. (a ~ F b) => ..., (forall c. ....(F b)...) ...
      
      Then
       - we'll flatten the (F) b to a fsk, say  (F b ~ fsk1)
       - we'll rewrite the (F b) inside the inner implication to 'fsk1'
       - when we leave the outer constraint we are suppose to unflatten;
         but that fsk1 will still be there
       - if we re-simplify the entire outer implication, we'll re-flatten
         the Given (F b) to, say, (F b ~ fsk2)
      Now we have two fsks standing for the same thing, and that is very
      wrong.
      
      Solution: make fsks behave more like fmvs:
       - A flatten-skolem is now a MetaTyVar, whose MetaInfo is FlatSkolTv
       - We "fill in" that meta-tyvar when leaving the implication
       - The old FlatSkol form of TcTyVarDetails is gone completely
       - We track the flatten-skolems for the current implication in
         a new field of InertSet, inert_fsks.
      
      See Note [The flattening story] in TcFlatten.
      
      In doing this I found various other things to fix:
      
      * I removed the zonkSimples from TcFlatten.unflattenWanteds; it wasn't
        needed.   But I added one in TcSimplify.floatEqualities, which does
        the zonk precisely when it is needed.
      
      * Trac #13674 showed up a case where we had
           - an insoluble Given,   e.g.  a ~ [a]
           - the same insoluble Wanted   a ~ [a]
        We don't use the Given to rewwrite the Wanted (obviously), but
        we therefore ended up reporting
            Can't deduce (a ~ [a]) from (a ~ [a])
        which is silly.
      
        Conclusion: when reporting errors, make the occurs check "win"
        See Note [Occurs check wins] in TcErrors
      8dc6d645
  13. 19 May, 2017 1 commit
    • Simon Peyton Jones's avatar
      Ensure that insolubles are fully rewritten · 433b80de
      Simon Peyton Jones authored
      I was alerted to this by Trac #12468 and #11325.  We were treating
      insolubles (and "hole" constraints are treated as insoluble)
      inconsistently.  In some places we were carefully rewriting them
      e.g. Note [Make sure that insolubles are fully rewritten] in
      TcCanonical.  But in TcSimplify we weren't feeding them into
      the solver.
      
      As a result, "hole" constraints were not being rewritten, which
      some users found confusing, and I think rightly so.
      
      This patch also fixes a bug in TcSMonad.emitInsoluble, in which two
      different "hole" constriants could be treated (bogusly) as duplicates,
      thereby losing one.
      433b80de
  14. 18 Apr, 2017 1 commit
  15. 13 Apr, 2017 2 commits
    • Simon Peyton Jones's avatar
      Remove dead quantifyTyVars · fbb27d77
      Simon Peyton Jones authored
      This patch
      
      * removes a function TcMType.quantifyTyVars
        that was never called
      
      * renames quantifyZonkedTyVars to quantifyTyVars
      
      Plus a few comments.  No functional change at all
      fbb27d77
    • Simon Peyton Jones's avatar
      Yet more work on TcSimplify.simplifyInfer · 0ae72512
      Simon Peyton Jones authored
      The proximate cause for this patch is Trac #13482, which pointed out
      further subtle interactions between
         - Inferring the most general type of a function
         - A partial type signature for that function
      
      That led me into /further/ changes to the shiny new stuff in
      TcSimplify.simplifyInfer, decideQuantification, decideMonoTyVars,
      and related functions.
      
      Happily, I was able to make some of it quite a bit simpler,
      notably the bit about promoting free tyvars.  I'm happy with
      the result.
      
      Moreover I fixed Trac #13524 at the same time.  Happy days.
      0ae72512
  16. 11 Apr, 2017 1 commit
  17. 06 Apr, 2017 1 commit
    • Simon Peyton Jones's avatar
      Yet another attempt at inferring the right quantification · bac95f9d
      Simon Peyton Jones authored
      TcSimplify.decideQuantification is truly a tricky function!
      Trac #13509 showed that we were being over-eager with defaulting
      of runtime-rep variables (levity polymorphism), which meant that
      a program was wrongly rejected, and with a very odd error message
      (c.f. Trac #13530)
      
      I spent an unreasonably long time figuring out how to fix this
      in a decent way, and ended up with a major refactoring of
      decideQuantification, with a kock-on effect in simplifyInfer.
      
      It is at least a bit more comprehensible now; but I still
      can't say I like it.
      bac95f9d
  18. 17 Mar, 2017 1 commit
    • Richard Eisenberg's avatar
      Remove solveSomeEqualities · 3cfee57a
      Richard Eisenberg authored
      I had thought that it was necessary to solve kind-level equalities
      before validity-checking a type, but I was wrong. This patch simply
      deletes code. Hooray!
      3cfee57a
  19. 14 Mar, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #13337. · e0c433c8
      Richard Eisenberg authored and Ben Gamari's avatar Ben Gamari committed
      The big change is the introduction of solveSomeEqualities. This
      is just like solveEqualities, but it doesn't fail if there are unsolved
      equalities when it's all done. Anything unsolved is re-emitted. This
      is appropriate if we are not kind-generalizing, so this new form
      is used when decideKindGeneralizationPlan says not to.
      
      We initially thought that any use of solveEqualities would be tied
      to kind generalization, but this isn't true. For example, we need
      to solveEqualities a bunch in the "tc" pass in TcTyClsDecls (which
      is really desugaring). These equalities are all surely going to be
      soluble (if they weren't the "kc" pass would fail), but we still
      need to solve them again. Perhaps if the "kc" pass produced type-
      checked output that is then desugared, solveEqualities really would
      be tied only to kind generalization.
      
      Updates haddock submodule.
      
      Test Plan: ./validate, typecheck/should_compile/T13337
      
      Reviewers: simonpj, bgamari, austin
      
      Reviewed By: simonpj
      
      Subscribers: RyanGlScott, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3315
      e0c433c8
  20. 10 Mar, 2017 3 commits
    • Simon Peyton Jones's avatar
      Define TcSimplify.simplifyTopImplic and use it · 2d3cb34a
      Simon Peyton Jones authored
      A very small refactoring
      2d3cb34a
    • Simon Peyton Jones's avatar
      Improve error messages for skolems · 48d1866e
      Simon Peyton Jones authored
      In error messages like this
          • Couldn't match type ‘c’ with ‘f0 (a -> b)’
            ‘c’ is a rigid type variable bound by
              the type signature for:
                f :: ((a -> b) -> b) -> forall c. c -> a
      
      we need to take case both to actually show that 'forall c',
      and to make sure that its name lines with the 'c' in the
      error message.
      
      This has been shaky for some time, and this commit puts it on solid
      ground.  See TcRnTypes: Note [SigSkol SkolemInfo]
      
      The main changes are
      
      * SigSkol gets an extra field that records the way in which the
        type signature was skolemised.
      
      * The type in SigSkol is now the /un/-skolemised version
      
      * pprSkolemInfo uses the info to make the tidy type line up
        nicely
      
      Lots of error message wibbles!
      48d1866e
    • Simon Peyton Jones's avatar
      Fix TcSimplify.decideQuantification for kind variables · 7e96526a
      Simon Peyton Jones authored
      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.
      7e96526a
  21. 01 Mar, 2017 1 commit
    • David Feuer's avatar
      Upgrade UniqSet to a newtype · cbe569a5
      David Feuer authored and David Feuer's avatar David Feuer committed
      The fundamental problem with `type UniqSet = UniqFM` is that `UniqSet`
      has a key invariant `UniqFM` does not. For example, `fmap` over
      `UniqSet` will generally produce nonsense.
      
      * Upgrade `UniqSet` from a type synonym to a newtype.
      
      * Remove unused and shady `extendVarSet_C` and `addOneToUniqSet_C`.
      
      * Use cached unique in `tyConsOfType` by replacing
        `unitNameEnv (tyConName tc) tc` with `unitUniqSet tc`.
      
      Reviewers: austin, hvr, goldfire, simonmar, niteria, bgamari
      
      Reviewed By: niteria
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3146
      cbe569a5
  22. 15 Feb, 2017 1 commit
  23. 14 Feb, 2017 1 commit
    • vivid-synth's avatar
      Allow type defaulting for multi-param type classes with ExtendedDefaultRules · c3bbd1af
      vivid-synth authored and Ben Gamari's avatar Ben Gamari committed
      Expressions like the following will now typecheck:
      
      ```
          data A x = A deriving Show
      
          class ToA a x where
             toA :: a -> A x
      
          instance ToA Integer x where
             toA _ = A
      
          main = print (toA 5 :: A Bool)
      ```
      
      The new defaulting rules are
      
      Find all the unsolved constraints. Then:
      
      * Find those that have exactly one free type variable, and partition
        that subset into groups that share a common type variable `a`.
      * Now default `a` (to one of the types in the default list) if at least
        one of the classes `Ci` is an interactive class
      
      Reviewers: goldfire, bgamari, austin, mpickering, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: mpickering, simonpj, goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2822
      c3bbd1af
  24. 10 Feb, 2017 1 commit
    • Ryan Scott's avatar
      Refactor DeriveAnyClass's instance context inference · 639e702b
      Ryan Scott authored
      Summary:
      Currently, `DeriveAnyClass` has two glaring flaws:
      
      * It only works on classes whose argument is of kind `*` or `* -> *` (#9821).
      * The way it infers constraints makes no sense. It basically co-opts the
        algorithms used to infer contexts for `Eq` (for `*`-kinded arguments) or
        `Functor` (for `(* -> *)`-kinded arguments). This tends to produce overly
        constrained instances, which in extreme cases can lead to legitimate things
        failing to typecheck (#12594). Or even worse, it can trigger GHC panics
        (#12144 and #12423).
      
      This completely reworks the way `DeriveAnyClass` infers constraints to fix
      these two issues. It now uses the type signatures of the derived class's
      methods to infer constraints (and to simplify them). A high-level description
      of how this works is included in the GHC users' guide, and more technical notes
      on what is going on can be found as comments (and a Note) in `TcDerivInfer`.
      
      Fixes #9821, #12144, #12423, #12594.
      
      Test Plan: ./validate
      
      Reviewers: dfeuer, goldfire, simonpj, austin, bgamari
      
      Subscribers: dfeuer, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2961
      639e702b
  25. 09 Feb, 2017 1 commit
  26. 08 Feb, 2017 1 commit
    • Simon Peyton Jones's avatar
      Back-pedal the fix for Trac #8155 · a94b4847
      Simon Peyton Jones authored
      I implemented a rather elaborate fix for #8155 ages ago, which
      which turns out to be
        a) unnecesssary in this particular case
        b) harmful to the defaulting story; see comment:15 of #12923.
      
      So this patch reverts the elaborate bit. The bit I removed is
      described in "Historical note" under Note [approximateWC].
      a94b4847
  27. 23 Jan, 2017 1 commit
  28. 19 Jan, 2017 1 commit
    • Richard Eisenberg's avatar
      Update levity polymorphism · e7985ed2
      Richard Eisenberg authored
      This commit implements the proposal in
      https://github.com/ghc-proposals/ghc-proposals/pull/29 and
      https://github.com/ghc-proposals/ghc-proposals/pull/35.
      
      Here are some of the pieces of that proposal:
      
      * Some of RuntimeRep's constructors have been shortened.
      
      * TupleRep and SumRep are now parameterized over a list of RuntimeReps.
      * This
      means that two types with the same kind surely have the same
      representation.
      Previously, all unboxed tuples had the same kind, and thus the fact
      above was
      false.
      
      * RepType.typePrimRep and friends now return a *list* of PrimReps. These
      functions can now work successfully on unboxed tuples. This change is
      necessary because we allow abstraction over unboxed tuple types and so
      cannot
      always handle unboxed tuples specially as we did before.
      
      * We sometimes have to create an Id from a PrimRep. I thus split PtrRep
      * into
      LiftedRep and UnliftedRep, so that the created Ids have the right
      strictness.
      
      * The RepType.RepType type was removed, as it didn't seem to help with
      * much.
      
      * The RepType.repType function is also removed, in favor of typePrimRep.
      
      * I have waffled a good deal on whether or not to keep VoidRep in
      TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
      represented in RuntimeRep, and typePrimRep will never return a list
      including
      VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
      imagine another design choice where we have a PrimRepV type that is
      PrimRep
      with an extra constructor. That seemed to be a heavier design, though,
      and I'm
      not sure what the benefit would be.
      
      * The last, unused vestiges of # (unliftedTypeKind) have been removed.
      
      * There were several pretty-printing bugs that this change exposed;
      * these are fixed.
      
      * We previously checked for levity polymorphism in the types of binders.
      * But we
      also must exclude levity polymorphism in function arguments. This is
      hard to check
      for, requiring a good deal of care in the desugarer. See Note [Levity
      polymorphism
      checking] in DsMonad.
      
      * In order to efficiently check for levity polymorphism in functions, it
      * was necessary
      to add a new bit of IdInfo. See Note [Levity info] in IdInfo.
      
      * It is now safe for unlifted types to be unsaturated in Core. Core Lint
      * is updated
      accordingly.
      
      * We can only know strictness after zonking, so several checks around
      * strictness
      in the type-checker (checkStrictBinds, the check for unlifted variables
      under a ~
      pattern) have been moved to the desugarer.
      
      * Along the way, I improved the treatment of unlifted vs. banged
      * bindings. See
      Note [Strict binds checks] in DsBinds and #13075.
      
      * Now that we print type-checked source, we must be careful to print
      * ConLikes correctly.
      This is facilitated by a new HsConLikeOut constructor to HsExpr.
      Particularly troublesome
      are unlifted pattern synonyms that get an extra void# argument.
      
      * Includes a submodule update for haddock, getting rid of #.
      
      * New testcases:
        typecheck/should_fail/StrictBinds
        typecheck/should_fail/T12973
        typecheck/should_run/StrictPats
        typecheck/should_run/T12809
        typecheck/should_fail/T13105
        patsyn/should_fail/UnliftedPSBind
        typecheck/should_fail/LevPolyBounded
        typecheck/should_compile/T12987
        typecheck/should_compile/T11736
      
      * Fixed tickets:
        #12809
        #12973
        #11736
        #13075
        #12987
      
      * This also adds a test case for #13105. This test case is
      * "compile_fail" and
      succeeds, because I want the testsuite to monitor the error message.
      When #13105 is fixed, the test case will compile cleanly.
      e7985ed2
  29. 18 Jan, 2017 1 commit
  30. 12 Jan, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix top-level constraint handling (Trac #12921) · f5f6d423
      Simon Peyton Jones authored
      Some out-of-scope errors were not being reported if anyone
      throws an un-caught exception in the TcM monad.  That led to
      
        ghc: panic! (the 'impossible' happened)
      	initTc: unsolved constraints
      
      I fixed this
      
      * Splitting captureConstraints to use an auxilliary
        tryCaptureConstraints (which never fails)
      
      * Define a new TcSimplify.captureTopConstraints (replacing
        the old TcRnMonad.captureTopConstraints), which reports
        any unsolved out-of-scope constraints before propagating
        the exception
      
      That in turn allowed me to do some tidying up of the static-constraint
      machinery, reducing duplication.
      
      Also solves #13106.
      f5f6d423
  31. 12 Dec, 2016 1 commit
    • Simon Peyton Jones's avatar
      Refactor pruning of implication constraints · 818e027e
      Simon Peyton Jones authored
      We try to prune solved implication constraints, but it's a
      bit tricky because of our desire to correctly report unused
      'givens'.  This patch improves matters a bit... in tracig some
      other bug I saw lots of empty constraints lying around!
      818e027e
  32. 25 Nov, 2016 1 commit
    • Simon Peyton Jones's avatar
      Another major constraint-solver refactoring · 1eec1f21
      Simon Peyton Jones authored
      This patch takes further my refactoring of the constraint
      solver, which I've been doing over the last couple of months
      in consultation with Richard.
      
      It fixes a number of tricky bugs that made the constraint
      solver actually go into a loop, including
      
        Trac #12526
        Trac #12444
        Trac #12538
      
      The main changes are these
      
      * Flatten unification variables (fmvs/fuvs) appear on the LHS
        of a tvar/tyvar equality; thus
                 fmv ~ alpha
        and not
                 alpha ~ fmv
      
        See Note [Put flatten unification variables on the left]
        in TcUnify.  This is implemented by TcUnify.swapOverTyVars.
      
      * Don't reduce a "loopy" CFunEqCan where the fsk appears on
        the LHS:
            F t1 .. tn ~ fsk
        where 'fsk' is free in t1..tn.
        See Note [FunEq occurs-check principle] in TcInteract
      
        This neatly stops some infinite loops that people reported;
        and it allows us to delete some crufty code in reduce_top_fun_eq.
        And it appears to be no loss whatsoever.
      
        As well as fixing loops, ContextStack2 and T5837 both terminate
        when they didn't before.
      
      * Previously we generated "derived shadow" constraints from
        Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly
        generate a derived shadow from the same Wanted.
      
        A big change in this patch is to have two kinds of Wanteds:
           [WD] behaves like a pair of a Wanted and a Derived
           [W]  behaves like a Wanted only
        See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh
        field of a Wanted.
      
        This turned out to be a lot simpler.  A [WD] gets split into a
        [W] and a [D] in TcSMonad.maybeEmitShaodow.
      
        See TcSMonad Note [The improvement story and derived shadows]
      
      * Rather than have a separate inert_model in the InertCans, I've
        put the derived equalities back into inert_eqs.  We weren't
        gaining anything from a separate field.
      
      * Previously we had a mode for the constraint solver in which it
        would more aggressively solve Derived constraints; it was used
        for simplifying the context of a 'deriving' clause, or a 'default'
        delcaration, for example.
      
        But the complexity wasn't worth it; now I just make proper Wanted
        constraints.  See TcMType.cloneWC
      
      * Don't generate injectivity improvement for Givens; see
        Note [No FunEq improvement for Givens] in TcInteract
      
      * solveSimpleWanteds leaves the insolubles in-place rather than
        returning them.  Simpler.
      
      I also did lots of work on comments, including fixing Trac #12821.
      1eec1f21