1. 05 Oct, 2019 1 commit
  2. 20 Sep, 2019 1 commit
  3. 19 Sep, 2019 2 commits
    • Richard Eisenberg's avatar
      Use level numbers for generalisation · f594a68a
      Richard Eisenberg authored
      This fixes #15809, and is covered in
      Note [Use level numbers for quantification] in TcMType.
      
      This patch removes the "global tyvars" from the
      environment, a nice little win.
      f594a68a
    • Richard Eisenberg's avatar
      Refactor kindGeneralize and friends · d9c6b86e
      Richard Eisenberg authored
      This commit should have no change in behavior.(*)
      
      The observation was that Note [Recipe for checking a signature]
      says that every metavariable in a type-checked type must either
        (A) be generalized
        (B) be promoted
        (C) be zapped.
      Yet the code paths for doing these were all somewhat separate.
      This led to some steps being skipped. This commit shores this
      all up. The key innovation is TcHsType.kindGeneralizeSome, with
      appropriate commentary.
      
      This commit also sets the stage for #15809, by turning the
      WARNing about bad level-numbers in generalisation into an
      ASSERTion. The actual fix for #15809 will be in a separate
      commit.
      
      Other changes:
       * zonkPromoteType is now replaced by kindGeneralizeNone.
         This might have a small performance degradation, because
         zonkPromoteType zonked and promoted all at once. The new
         code path promotes first, and then zonks.
      
       * A call to kindGeneralizeNone was added in tcHsPartialSigType.
         I think this was a lurking bug, because it did not follow
         Note [Recipe for checking a signature]. I did not try to
         come up with an example showing the bug. This is the (*)
         above.
      
         Because of this change, there is an error message regression
         in partial-sigs/should_fail/T14040a. This problem isn't really
         a direct result of this refactoring, but is a symptom of
         something deeper. See #16775, which addresses the deeper
         problem.
      
       * I added a short-cut to quantifyTyVars, in case there's
         nothing to quantify.
      
       * There was a horribly-outdated Note that wasn't referred
         to. Gone now.
      
       * While poking around with T14040a, I discovered a small
         mistake in the Coercion.simplifyArgsWorker. Easy to fix,
         happily.
      
       * See new Note [Free vars in coercion hole] in TcMType.
         Previously, we were doing the wrong thing when looking
         at a coercion hole in the gather-candidates algorithm.
         Fixed now, with lengthy explanation.
      
      Metric Decrease:
        T14683
      d9c6b86e
  4. 19 Aug, 2019 1 commit
  5. 09 Jul, 2019 1 commit
    • Ryan Scott's avatar
      Use an empty data type in TTG extension constructors (#15247) · 6a03d77b
      Ryan Scott authored
      To avoid having to `panic` any time a TTG extension constructor is
      consumed, this MR introduces an uninhabited 'NoExtCon' type and uses
      that in every extension constructor's type family instance where it
      is appropriate. This also introduces a 'noExtCon' function which
      eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates
      a 'Void'.
      
      I also renamed the existing `NoExt` type to `NoExtField` to better
      distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of
      code churn resulting from this.
      
      Bumps the Haddock submodule. Fixes #15247.
      6a03d77b
  6. 05 Jul, 2019 1 commit
    • Vladislav Zavialov's avatar
      Produce all DerivInfo in tcTyAndClassDecls · 679427f8
      Vladislav Zavialov authored
      Before this refactoring:
      
      * DerivInfo for data family instances was returned from tcTyAndClassDecls
      * DerivInfo for data declarations was generated with mkDerivInfos and added at a
        later stage of the pipeline in tcInstDeclsDeriv
      
      After this refactoring:
      
      * DerivInfo for both data family instances and data declarations is returned from
        tcTyAndClassDecls in a single list.
      
      This uniform treatment results in a more convenient arrangement to fix #16731.
      679427f8
  7. 21 Jun, 2019 1 commit
    • Matthías Páll Gissurarson's avatar
      Add HoleFitPlugins and RawHoleFits · c311277b
      Matthías Páll Gissurarson authored
      This patch adds a new kind of plugin, Hole fit plugins. These plugins
      can change what candidates are considered when looking for valid hole
      fits, and add hole fits of their own. The type of a plugin is relatively
      simple,
      
      ```
      type FitPlugin = TypedHole -> [HoleFit] -> TcM [HoleFit]
      type CandPlugin = TypedHole -> [HoleFitCandidate] -> TcM [HoleFitCandidate]
      data HoleFitPlugin = HoleFitPlugin { candPlugin :: CandPlugin
                                         , fitPlugin :: FitPlugin }
      
      data TypedHole = TyH { tyHRelevantCts :: Cts
                             -- ^ Any relevant Cts to the hole
                           , tyHImplics :: [Implication]
                             -- ^ The nested implications of the hole with the
                             --   innermost implication first.
                           , tyHCt :: Maybe Ct
                             -- ^ The hole constraint itself, if available.
                           }
      
      This allows users and plugin writers to interact with the candidates and
      fits as th...
      c311277b
  8. 20 Jun, 2019 2 commits
    • Simon Peyton Jones's avatar
      Fix typechecking of partial type signatures · 48fb3482
      Simon Peyton Jones authored
      Partial type sigs had grown hair.  tcHsParialSigType was
      doing lots of unnecessary work, and tcInstSig was cloning it
      unnecessarily -- and the result didn't even work: #16728.
      
      This patch cleans it all up, described by TcHsType
        Note [Checking parital type signatures]
      
      I basically just deleted code... but very carefully!
      
      Some refactoring along the way
      
      * Distinguish more explicintly between "anonymous" wildcards "_"
        and "named" wildcards "_a".  I changed the names of a number
        of functions to make this distinction much more apparent.
      
      The patch also revealed that the code in `TcExpr`
      that implements the special typing rule for `($)` was wrong.
      It called `getRuntimeRep` in a situation where where was no
      particular reason to suppose that the thing had kind `TYPE r`.
      
      This caused a crash in typecheck/should_run/T10846.
      
      The fix was easy, and actually simplifies the code in `TcExpr`
      quite a bit.  Hooray.
      48fb3482
    • Ömer Sinan Ağacan's avatar
      Properly trim IdInfos of DFunIds and PatSyns in TidyPgm · 9d58554f
      Ömer Sinan Ağacan authored
      Not doing this right caused #16608. We now properly trim IdInfos of
      DFunIds and PatSyns.
      
      Some further refactoring done by SPJ.
      
      Two regression tests T16608_1 and T16608_2 added.
      
      Fixes #16608
      9d58554f
  9. 09 Jun, 2019 1 commit
    • Richard Eisenberg's avatar
      Fix #16517 by bumping the TcLevel for method sigs · a22e51ea
      Richard Eisenberg authored
      There were actually two bugs fixed here:
      
      1. candidateQTyVarsOfType needs to be careful that it does not
         try to zap metavariables from an outer scope as "naughty"
         quantification candidates. This commit adds a simple check
         to avoid doing so.
      
      2. We weren't bumping the TcLevel in kcHsKindSig, which was used
         only for class method sigs. This mistake led to the acceptance
         of
      
           class C a where
             meth :: forall k. Proxy (a :: k) -> ()
      
         Note that k is *locally* quantified. This patch fixes the
         problem by using tcClassSigType, which correctly bumps the
         level. It's a bit inefficient because tcClassSigType does other
         work, too, but it would be tedious to repeat much of the code
         there with only a few changes. This version works well and is
         simple.
      
      And, while updating comments, etc., I noticed that tcRnType was
      missing a pushTcLevel, leading to #16767, which this patch also
      fixes, by bumping the level. In the refactoring here, I also
      use solveEqualities. This initially failed ghci/scripts/T15415,
      but that was fixed by teaching solveEqualities to respect
      -XPartialTypeSignatures.
      
      This patch also cleans up some Notes around error generation that
      came up in conversation.
      
      Test case: typecheck/should_fail/T16517, ghci/scripts/T16767
      a22e51ea
  10. 04 Jun, 2019 1 commit
    • xldenis's avatar
      Add GHCi :instances command · 002594b7
      xldenis authored
      This commit adds the `:instances` command to ghci following proosal
      number 41.
      
      This makes it possible to query which instances are available to a given
      type.
      
      The output of this command is all the possible instances with type
      variables and constraints instantiated.
      002594b7
  11. 08 May, 2019 1 commit
  12. 25 Mar, 2019 1 commit
    • Takenobu Tani's avatar
      Update Wiki URLs to point to GitLab · 3769e3a8
      Takenobu Tani authored
      This moves all URL references to Trac Wiki to their corresponding
      GitLab counterparts.
      
      This substitution is classified as follows:
      
      1. Automated substitution using sed with Ben's mapping rule [1]
          Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...
          New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...
      
      2. Manual substitution for URLs containing `#` index
          Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz
          New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz
      
      3. Manual substitution for strings starting with `Commentary`
          Old: Commentary/XxxYyy...
          New: commentary/xxx-yyy...
      
      See also !539
      
      [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
      3769e3a8
  13. 15 Mar, 2019 1 commit
  14. 08 Mar, 2019 1 commit
    • Simon Peyton Jones's avatar
      Use captureTopConstraints in TcRnDriver calls · 5be7ad78
      Simon Peyton Jones authored
      Trac #16376 showed the danger of failing to report an error
      that exists only in the unsolved constraints, if an exception
      is raised (via failM).
      
      Well, the commit 5c1f268e (Fail fast in solveLocalEqualities)
      did just that -- i.e. it found errors in the constraints, and
      called failM to avoid a misleading cascade.
      
      So we need to be sure to call captureTopConstraints to report
      those insolubles.  This was wrong in TcRnDriver.tcRnExpr and
      in TcRnDriver.tcRnType.
      
      As a result the error messages from test T13466 improved slightly,
      a happy outcome.
      5be7ad78
  15. 01 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Visible dependent quantification · c26d299d
      Ryan Scott authored
      This implements GHC proposal 35
      (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst)
      by adding the ability to write kinds with
      visible dependent quantification (VDQ).
      
      Most of the work for supporting VDQ was actually done _before_ this
      patch. That is, GHC has been able to reason about kinds with VDQ for
      some time, but it lacked the ability to let programmers directly
      write these kinds in the source syntax. This patch is primarly about
      exposing this ability, by:
      
      * Changing `HsForAllTy` to add an additional field of type
        `ForallVisFlag` to distinguish between invisible `forall`s (i.e,
        with dots) and visible `forall`s (i.e., with arrows)
      * Changing `Parser.y` accordingly
      
      The rest of the patch mostly concerns adding validity checking to
      ensure that VDQ is never used in the type of a term (as permitting
      this would require full-spectrum dependent types). This is
      accomplished by:
      
      * Adding a `vdqAllowed` predicate to `TcValidity`.
      * I...
      c26d299d
  16. 24 Feb, 2019 1 commit
    • Simon Peyton Jones's avatar
      Add AnonArgFlag to FunTy · 6cce36f8
      Simon Peyton Jones authored
      The big payload of this patch is:
      
        Add an AnonArgFlag to the FunTy constructor
        of Type, so that
          (FunTy VisArg   t1 t2) means (t1 -> t2)
          (FunTy InvisArg t1 t2) means (t1 => t2)
      
      The big payoff is that we have a simple, local test to make
      when decomposing a type, leading to many fewer calls to
      isPredTy. To me the code seems a lot tidier, and probably
      more efficient (isPredTy has to take the kind of the type).
      
      See Note [Function types] in TyCoRep.
      
      There are lots of consequences
      
      * I made FunTy into a record, so that it'll be easier
        when we add a linearity field, something that is coming
        down the road.
      
      * Lots of code gets touched in a routine way, simply because it
        pattern matches on FunTy.
      
      * I wanted to make a pattern synonym for (FunTy2 arg res), which
        picks out just the argument and result type from the record. But
        alas the pattern-match overlap checker has a heart attack, and
        either reports false positives, or takes too long.  In the end
        I gave up on pattern synonyms.
      
        There's some commented-out code in TyCoRep that shows what I
        wanted to do.
      
      * Much more clarity about predicate types, constraint types
        and (in particular) equality constraints in kinds.  See TyCoRep
        Note [Types for coercions, predicates, and evidence]
        and Note [Constraints in kinds].
      
        This made me realise that we need an AnonArgFlag on
        AnonTCB in a TyConBinder, something that was really plain
        wrong before. See TyCon Note [AnonTCB InivsArg]
      
      * When building function types we must know whether we
        need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy).
        This turned out to be pretty easy in practice.
      
      * Pretty-printing of types, esp in IfaceType, gets
        tidier, because we were already recording the (->)
        vs (=>) distinction in an ad-hoc way.  Death to
        IfaceFunTy.
      
      * mkLamType needs to keep track of whether it is building
        (t1 -> t2) or (t1 => t2).  See Type
        Note [mkLamType: dictionary arguments]
      
      Other minor stuff
      
      * Some tidy-up in validity checking involving constraints;
        Trac #16263
      6cce36f8
  17. 04 Feb, 2019 1 commit
  18. 11 Jan, 2019 1 commit
    • Matthew Pickering's avatar
      Run typed splices in the zonker · c2455e64
      Matthew Pickering authored
      Summary:
      This fixes #15471
      
      In the typechecker we check that the splice has the right type but we
      crucially don't zonk the generated expression. This is because we might
      end up unifying type variables from outer scopes later on.
      
      Reviewers: simonpj, goldfire, bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15471
      
      Differential Revision: https://phabricator.haskell.org/D5286
      c2455e64
  19. 08 Jan, 2019 1 commit
    • Ryan Scott's avatar
      Be pickier about unsaturated synonyms in :kind · 6b70cf61
      Ryan Scott authored
      Summary:
      We currently permit any and all uses of unsaturated type
      synonyms and type families in GHCi's `:kind` command, which allows
      strange interactions like this one:
      
      ```
      > :set -XTypeFamilies -XPolyKinds
      > type family Id (a :: k)
      > type instance Id a = a
      > type Foo x = Maybe
      > :kind! Id Foo
      ```
      
      This is probably a stretch too far, so this patch moves to disallow
      unsaturated synonyms that aren't at the top level (we still want to
      allow `:kind Id`, for instance). We do this by augmenting `GhciCtxt`
      with an additional `Bool` field to indicate if we are at the
      outermost level of the type being passed to `:kind` or not. See
      `Note [Unsaturated type synonyms in GHCi]` in `TcValidity` for the
      full story.
      
      Test Plan: make test TEST=T16013
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: simonpj, goldfire, rwbarton, carter
      
      GHC Trac Issues: #16013
      
      Differential Revision: https://phabricator.haskell.org/D5471
      6b70cf61
  20. 21 Dec, 2018 2 commits
    • Ben Gamari's avatar
      TcRnDriver: Fix haddock-like comment · 348cb218
      Ben Gamari authored
      348cb218
    • Simon Peyton Jones's avatar
      Fix treatment of hi-boot files and dfuns · a57d5c4d
      Simon Peyton Jones authored
      Trac #16038 exposed the fact that TcRnDriver.checkHiBootIface
      was creating a binding, in the module being compiled, for
         $fxBlah = $fBlah
      
       but $fxBlah was a /GlobalId/. But all bindings should be for
       /LocalIds/ else dependency analysis goes down the tubes.
      
      * I added a CoreLint check that an occurrence of a GlobalId
        is not bound by an binding of a LocalId.  (There is already
        a binding-site check that no binding binds a GlobalId.)
      
      * I refactored (and actually signficantly simplified) the
        tricky code for dfuns in checkHiBootIface to ensure that
        we get LocalIds for those boot-dfuns.
      
      Alas, I then got "duplicate instance" messages when compiling
      HsExpr. It turns out that this is a long-standing, but extremely
      delicate, bug: even before this patch, if you compile HsExpr
      with -ddump-tc-trace, you get "duplicate instance". Without
      -ddump-tc-trace, it's OK.  What a mess!
      
      The reason for the duplicate-instance is now explained in
      Note [Loading your own hi-boot ...
      a57d5c4d
  21. 11 Dec, 2018 1 commit
  22. 07 Dec, 2018 1 commit
    • Simon Peyton Jones's avatar
      Wibble to Taming the Kind Inference Monster · 5b7ca039
      Simon Peyton Jones authored
      I had allowed rename/should_fail/T15828 (Trac #15828) to regress a bit.
      The main payload of this patch is to fix that problem, at the cost of
      more contortions in checkConsistentFamInst.  Oh well, at least they are
      highly localised.
      
      I also update the -ddump-types code in TcRnDriver to print out some
      more expicit information about each type constructor, thus instead of
      
         DF{3} :: forall k. * -> k -> *
      
      we get
      
         data family DF{3} :: forall k. * -> k -> *
      
      Remember, this is debug-printing only.  This change is the reason
      that so many .stderr files change.
      5b7ca039
  23. 03 Dec, 2018 1 commit
    • Simon Peyton Jones's avatar
      Introduce tcTypeKind, and use it · 03d48526
      Simon Peyton Jones authored
      In the type checker Constraint and * are distinct; and the function
      that takes the kind of a type should respect that distinction
      (Trac #15971).
      
      This patch implements the change:
      
      * Introduce Type.tcTypeKind, and use it throughout the type
        inference engine
      
      * Add new Note [Kinding rules for types] for the kinding
        rules, especially for foralls.
      
      * Redefine
          isPredTy ty = tcIsConstraintKind (tcTypeKind ty)
        (it had a much more complicated definition before)
      
      Some miscellaneous refactoring
      
      * Get rid of TyCoRep.isTYPE, Kind.isTYPEApp,
        in favour of TyCoRep.kindRep, kindRep_maybe
      
      * Rename Type.getRuntimeRepFromKind_maybe
        to getRuntimeRep_maybe
      
      I did some spot-checks on compiler perf, and it really doesn't
      budge (as expected).
      03d48526
  24. 29 Nov, 2018 2 commits
    • Chaitanya Koparkar's avatar
      Fix #15953 by consistently using dumpIfSet_dyn to print debug output · dcf1f926
      Chaitanya Koparkar authored
      Summary:
      In some modules we directly dump the debugging output to STDOUT
      via 'putLogMsg', 'printInfoForUser' etc. However, if `-ddump-to-file`
      is enabled, that output should be written to a file. Easily fixed.
      
      Certain tests (T3017, Roles3, T12763 etc.) expect part of the
      output generated by `-ddump-types` to be in 'PprUser' style. However,
      generally we want all other debugging output to use 'PprDump'
      style. `traceTcRn` and `traceTcRnForUser` help us accomplish this.
      
      This patch also documents some missing flags in the users guide.
      
      Reviewers: RyanGlScott, bgamari, hvr
      
      Reviewed By: RyanGlScott
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15953
      
      Differential Revision: https://phabricator.haskell.org/D5382
      dcf1f926
    • Simon Peyton Jones's avatar
      Taming the Kind Inference Monster · 2257a86d
      Simon Peyton Jones authored
      My original goal was (Trac #15809) to move towards using level numbers
      as the basis for deciding which type variables to generalise, rather
      than searching for the free varaibles of the environment.  However
      it has turned into a truly major refactoring of the kind inference
      engine.
      
      Let's deal with the level-numbers part first:
      
      * Augment quantifyTyVars to calculate the type variables to
        quantify using level numbers, and compare the result with
        the existing approach.  That is; no change in behaviour,
        just a WARNing if the two approaches give different answers.
      
      * To do this I had to get the level number right when calling
        quantifyTyVars, and this entailed a bit of care, especially
        in the code for kind-checking type declarations.
      
      * However, on the way I was able to eliminate or simplify
        a number of calls to solveEqualities.
      
      This work is incomplete: I'm not /using/ level numbers yet.
      When I subsequently get rid of any remaining WARNings in
      quantifyTyVars, that ...
      2257a86d
  25. 24 Nov, 2018 1 commit
  26. 17 Nov, 2018 1 commit
  27. 11 Nov, 2018 1 commit
  28. 29 Oct, 2018 2 commits
  29. 28 Oct, 2018 2 commits
    • Ben Gamari's avatar
      Plugins: Add documentation and missing exports · 49f5c6c3
      Ben Gamari authored
      Summary:
      Previously the TcPlugin and CorePlugin type synonyms were not exporting,
      resulting in much confusion.
      
      Reviewers: mpickering
      
      Reviewed By: mpickering
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5237
      49f5c6c3
    • Ningning Xie's avatar
      Fix `:k` command: add validity checking · c4a876d5
      Ningning Xie authored
      Summary:
      This patch fixes #15806, where we found that the `:k` command in GHCi
      misses a validity checking for the type.
      
      Missing validity checking causes `:k` to accept types that are not validated.
      For example, `:k (Maybe (forall a. a -> a))` (incorrectly) returns `*`, while
      impredictivity of type instantiation shouldn't be allowed.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15806
      
      Differential Revision: https://phabricator.haskell.org/D5265
      c4a876d5
  30. 27 Oct, 2018 1 commit
    • mayac's avatar
      More explicit foralls (GHC Proposal 0007) · 512eeb9b
      mayac authored
      Allow the user to explicitly bind type/kind variables in type and data
      family instances (including associated instances), closed type family
      equations, and RULES pragmas. Follows the specification of GHC
      Proposal 0007, also fixes #2600. Advised by Richard Eisenberg.
      
      This modifies the Template Haskell AST -- old code may break!
      
      Other Changes:
      - convert HsRule to a record
      - make rnHsSigWcType more general
      - add repMaybe to DsMeta
      
      Includes submodule update for Haddock.
      
      Test Plan: validate
      
      Reviewers: goldfire, bgamari, alanz
      
      Subscribers: simonpj, RyanGlScott, goldfire, rwbarton,
                   thomie, mpickering, carter
      
      GHC Trac Issues: #2600, #14268
      
      Differential Revision: https://phabricator.haskell.org/D4894
      512eeb9b
  31. 25 Oct, 2018 1 commit
  32. 24 Oct, 2018 1 commit
    • Simon Peyton Jones's avatar
      Improve output from -ddump-types · 321bc1a6
      Simon Peyton Jones authored
      This patch makes a number of improvements to the output
      generated by -ddump-types
      
      * Prints data constructor separately
      * Omits empty chunks of output
      
      I was driven initially by the unhelpful existing output for
      data constructors, but ended up doing some refactoring.
      
      Lots of error message wibbles, but nothing significant.
      Certainly no change in user behaviour.
      
      (NB: It is just possible that I have failed to cleanly
           separate this patch from the next one, about
           isPredTy and friends.)
      321bc1a6
  33. 05 Oct, 2018 1 commit
  34. 04 Oct, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fail fast on pattern synonyms · 9ebfa03d
      Simon Peyton Jones authored
      We were recovering too eagerly from errors in pattern-synonym
      type inference, leading to a cascade of confusing follow up errors
      (Trac #15685, #15692).
      
      The underlying issue is that a pattern synonym should have a closed,
      fixed type, with no unification variables in it.  But it wasn't!
      
      Fixing this made me change the interface to simplifyInfer slightly.
      Instead of /emitting/ a residual implication constraint, it
      now /returns/ it, so that the caller can decide what to do.
      9ebfa03d