1. 27 Aug, 2018 1 commit
  2. 24 Aug, 2018 2 commits
    • Simon Peyton Jones's avatar
      Better error reporting for inaccessible code · ff29fc84
      Simon Peyton Jones authored
      This patch fixes Trac #15558.  There turned out to be
      two distinct problems
      
      * In TcExpr.tc_poly_expr_nc we had
      
          tc_poly_expr_nc (L loc expr) res_ty
            = do { traceTc "tcPolyExprNC" (ppr res_ty)
                 ; (wrap, expr')
                     <- tcSkolemiseET GenSigCtxt res_ty $ \ res_ty ->
                        setSrcSpan loc $
                          -- NB: setSrcSpan *after* skolemising,
                          -- so we get better skolem locations
                        tcExpr expr res_ty
      
        Putting the setSrcSpan inside the tcSkolemise means that
        the location on the Implication constraint is the /call/
        to the function rather than the /argument/ to the call,
        and that is really quite wrong.
      
        I don't know what Richard's comment NB means -- I moved the
        setSrcSpan outside, and the "binding site" info in error
        messages actually improved.
      
        The reason I found this is that it affects the span reported
        for Trac #15558.
      
      * In TcErrors.mkGivenErrorReporter we carefully munge the location
        for an insoluble Given constraint (Note [Inaccessible code]).
        But the 'implic' passed in wasn't necesarily the immediately-
        enclosing implication -- but for location-munging purposes
        it jolly well should be.
      
        Solution: use the innermost implication. This actually
        simplifies the code -- no need to pass an implication in to
        mkGivenErrorReporter.
      ff29fc84
    • Simon Peyton Jones's avatar
      Clean up TcHsSyn.zonkEnv · 184a569c
      Simon Peyton Jones authored
      Triggered by Trac #15552, I'd been looking at ZonkEnv in TcHsSyn.
      
      This patch does some minor refactoring
      
      * Make ZonkEnv into a record with named fields, and use them.
        (I'm planning to add a new field, for TyCons, so this prepares
        the way.)
      
      * Replace UnboundTyVarZonker (a higer order function) with the
        simpler and more self-descriptive ZonkFlexi data type, below.
       It's just much more perspicuous and direct, and (I suspect)
       a tiny bit faster too -- no unknown function calls.
      
      data ZonkFlexi   -- See Note [Un-unified unification variables]
        = DefaultFlexi    -- Default unbound unificaiton variables to Any
        | SkolemiseFlexi  -- Skolemise unbound unification variables
                          -- See Note [Zonking the LHS of a RULE]
        | RuntimeUnkFlexi -- Used in the GHCi debugger
      
      There was one knock-on effect in the GHCi debugger -- the
      RuntimeUnkFlexi case.  Somehow previously, these RuntimeUnk
      variables were sometimes getting SystemNames (and hence
      printed as 'a0', 'a1', etc) and sometimes not (and hence
      printed as 'a', 'b' etc).  I'm not sure precisely why, but
      the new behaviour seems more uniform, so I just accepted the
      (small) renaming wibbles in some ghci.debugger tests.
      
      I had a quick look at perf: any changes are tiny.
      184a569c
  3. 23 Aug, 2018 2 commits
    • Simon Peyton Jones's avatar
      Accommodate API change in transSuperClasses · 4293a80a
      Simon Peyton Jones authored
      In this patch
      
          commit 6eabb6dd
          Author: Simon Peyton Jones <simonpj@microsoft.com>
          Date:   Tue Dec 15 14:26:13 2015 +0000
      
          Allow recursive (undecidable) superclasses
      
      I changed (transSuperClasses p) to return only the
      superclasses of p, but not p itself. (Previously it always
      returned p as well.)
      
      The use of transSuperClasses in TcErrors.warnRedundantConstraints
      really needs 'p' in the result -- but I faild to fix this
      call site, and instead crippled the test for Trac #10100.
      
      This patch sets things right
      
      * Accomodates the API change
      * Re-enables T10100
      * And thereby fixes Trac #11474
      4293a80a
    • Simon Peyton Jones's avatar
      Fix a typo in TcValidity.checkFamInstRhs · 8c7f90ab
      Simon Peyton Jones authored
      In error message generation we were using the wrong
      type constructor in inst_head.  Result: the type became
      ill-kinded, and that sent the compiler into a loop.
      
      A separate patch fixes the loop. This patch fixes the
      actual bug -- Trac #15473.
      
      I also improved the "occurs more often" error message
      a bit.  But it's still pretty terrible:
      
          * Variable ‘a’ occurs more often
            in the type family application ‘Undefined’
            than in the instance head ‘LetInterleave xs t ts is y z’
      
      It looks like nonsense, but all becomes clear if you use
      -fprint-explicit-kinds.  Really we should fix this by spotting
      when invisible arguments are involved and at least suggesting
      -fprint-explicit-kinds.
      8c7f90ab
  4. 21 Aug, 2018 9 commits
  5. 20 Aug, 2018 1 commit
    • Simon Peyton Jones's avatar
      Initialise cec_suppress properly · ecc0ddf6
      Simon Peyton Jones authored
      In TcErrors, cec_suppress is used to suppress low-priority
      errors in favour of truly insoluble ones.
      
      But I was failing to initialise it correcly at top level, which
      resulted in Trac #15539.  Easy to fix.
      
      A few regression tests have fewer errors reported, but that seems to
      be an improvement.
      ecc0ddf6
  6. 18 Aug, 2018 1 commit
  7. 17 Aug, 2018 3 commits
    • adityadivekar's avatar
      Add test cases for Ticket #12146. · 8f4df7f7
      adityadivekar authored
      Two tests - a ghci script and a compile fail test have been added.
      8f4df7f7
    • Ryan Scott's avatar
      Be mindful of GADT tyvar order when desugaring record updates · 63b6a1d4
      Ryan Scott authored
      Summary:
      After commit ef26182e,
      the type variable binders in GADT constructor type signatures
      are now quantified in toposorted order, instead of always having
      all the universals before all the existentials. Unfortunately, that
      commit forgot to update some code (which was assuming the latter
      scenario) in `DsExpr` which desugars record updates. This wound
      up being the cause of #15499.
      
      This patch makes up for lost time by desugaring record updates in
      a way such that the desugared expression applies type arguments to
      the right-hand side constructor in the correct order—that is, the
      order in which they were quantified by the user.
      
      Test Plan: make test TEST=T15499
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15499
      
      Differential Revision: https://phabricator.haskell.org/D5060
      63b6a1d4
    • Joachim Breitner's avatar
      Rename SigTv to TyVarTv (#15480) · a50244c6
      Joachim Breitner authored
      because since #15050, these are no longer used in pattern SIGnatures,
      but still in other places where meta-variables should only be unified
      with TYpe VARiables.
      
      I also found mentions of `SigTv` in parts of the renamer and desugarer
      that do not seem to directly relate to `SigTv` as used in the type
      checker, but rather to uses of `forall a.` in type signatures. I renamed
      these to `ScopedTv`.
      
      Differential Revision: https://phabricator.haskell.org/D5074
      a50244c6
  8. 16 Aug, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15527 by pretty-printing an RdrName prefixly · 5238f204
      Ryan Scott authored
      Summary:
      When `(.) @Int` is used without enabling `TypeApplications`,
      the resulting error message will pretty-print the (symbolic)
      `RdrName` `(.)`. However, it does so without parenthesizing it, which
      causes the pretty-printed expression to appear as `.@Int`. Yuck.
      
      Since the expression in a type application will always be prefix,
      we can fix this issue by using `pprPrefixOcc` instead of plain ol'
      `ppr`.
      
      Test Plan: make test TEST=T15527
      
      Reviewers: bgamari, monoidal, simonpj
      
      Reviewed By: monoidal, simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15527
      
      Differential Revision: https://phabricator.haskell.org/D5071
      5238f204
  9. 15 Aug, 2018 1 commit
  10. 14 Aug, 2018 1 commit
    • Ryan Scott's avatar
      Properly designate LambdaCase alts as CaseAlt in TH · 32008a9d
      Ryan Scott authored
      Summary:
      When `\case` expressions are parsed normally, their
      alternatives are marked as `CaseAlt` (which means that they are
      pretty-printed without a `\` character in front of them, unlike for
      lambda expressions). However, `\case` expressions created by way of
      Template Haskell (in `Convert`) inconsistently designated the case
      alternatives as `LambdaExpr`, causing them to be pretty-printed
      poorly (as shown in #15518). The fix is simple: use `CaseAlt`
      consistently.
      
      Test Plan: make test TEST=T15518
      
      Reviewers: goldfire, bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15518
      
      Differential Revision: https://phabricator.haskell.org/D5069
      32008a9d
  11. 12 Aug, 2018 5 commits
  12. 11 Aug, 2018 2 commits
    • Krzysztof Gogolewski's avatar
      Simplify testsuite driver · f27d7145
      Krzysztof Gogolewski authored
      Summary:
      - remove clean_cmd
      - framework_failures was undefined
      - times_file was not used
      - if_verbose_dump was called only when verbose >= 1; remove the check
      - simplify normalise_whitespace
      
      Test Plan: validate
      
      Reviewers: bgamari, thomie
      
      Reviewed By: thomie
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5061
      f27d7145
    • Christiaan Baaij's avatar
      Filter plugin dylib locations · b324c562
      Christiaan Baaij authored
      Summary:
      Previously we just created a cartesian product of the library
      paths of the plugin package and the libraries of the package.
      Of course, some of these combinations result in a filepath of
      a file doesn't exists, leading to #15475.
      
      Instead of making `haskFile` return Nothing in case a file
      doesn't exist (which would hide errors), we look at all the
      possible dylib locations and ensure that at least one of those
      locations is an existing file. If the list turns out to be
      empty however, we panic.
      
      Reviewers: mpickering, bgamari
      
      Reviewed By: mpickering
      
      Subscribers: monoidal, rwbarton, carter
      
      GHC Trac Issues: #15475
      
      Differential Revision: https://phabricator.haskell.org/D5048
      b324c562
  13. 07 Aug, 2018 2 commits
    • Ben Gamari's avatar
      testsuite: Add (broken) test for #15473 · 5487f305
      Ben Gamari authored
      5487f305
    • Herbert Valerio Riedel's avatar
      Turn on MonadFail desugaring by default · aab8656b
      Herbert Valerio Riedel authored
      Summary:
      This contains two commits:
      
      ----
      
      Make GHC's code-base compatible w/ `MonadFail`
      
      There were a couple of use-sites which implicitly used pattern-matches
      in `do`-notation even though the underlying `Monad` didn't explicitly
      support `fail`
      
      This refactoring turns those use-sites into explicit case
      discrimations and adds an `MonadFail` instance for `UniqSM`
      (`UniqSM` was the worst offender so this has been postponed for a
      follow-up refactoring)
      
      ---
      
      Turn on MonadFail desugaring by default
      
      This finally implements the phase scheduled for GHC 8.6 according to
      
      https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail#Transitionalstrategy
      
      This also preserves some tests that assumed MonadFail desugaring to be
      active; all ghc boot libs were already made compatible with this
      `MonadFail` long ago, so no changes were needed there.
      
      Test Plan: Locally performed ./validate --fast
      
      Reviewers: bgamari, simonmar, jrtc27, RyanGlScott
      
      Reviewed By: bgamari
      
      Subscribers: bgamari, RyanGlScott, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D5028
      aab8656b
  14. 06 Aug, 2018 4 commits
  15. 05 Aug, 2018 1 commit
  16. 04 Aug, 2018 1 commit
  17. 03 Aug, 2018 1 commit
  18. 02 Aug, 2018 1 commit
    • Richard Eisenberg's avatar
      Remove decideKindGeneralisationPlan · c955a514
      Richard Eisenberg authored
      TypeInType came with a new function: decideKindGeneralisationPlan.
      This type-level counterpart to the term-level decideGeneralisationPlan
      chose whether or not a kind should be generalized. The thinking was
      that if `let` should not be generalized, then kinds shouldn't either
      (under the same circumstances around -XMonoLocalBinds).
      
      However, this is too conservative -- the situation described in the
      motivation for "let should be be generalized" does not occur in types.
      
      This commit thus removes decideKindGeneralisationPlan, always
      generalizing.
      
      One consequence is that tc_hs_sig_type_and_gen no longer calls
      solveEqualities, which reports all unsolved constraints, instead
      relying on the solveLocalEqualities in tcImplicitTKBndrs. An effect
      of this is that reporing kind errors gets delayed more frequently.
      This seems to be a net benefit in error reporting; often, alongside
      a kind error, the type error is now reported (and users might find
      type errors easier to understand).
      
      Some of these errors ended up at the top level, where it was
      discovered that the GlobalRdrEnv containing the definitions in the
      local module was not in the TcGblEnv, and thus errors were reported
      with qualified names unnecessarily. This commit rejiggers some of
      the logic around captureTopConstraints accordingly.
      
      One error message (typecheck/should_fail/T1633)
      is a regression, mentioning the name of a default method. However,
      that problem is already reported as #10087, its solution is far from
      clear, and so I'm not addressing it here.
      
      This commit fixes #15141. As it's an internal refactor, there is
      no concrete test case for it.
      
      Along the way, we no longer need the hsib_closed field of
      HsImplicitBndrs (it was used only in decideKindGeneralisationPlan)
      and so it's been removed, simplifying the datatype structure.
      
      Along the way, I removed code in the validity checker that looks
      at coercions. This isn't related to this patch, really (though
      it was, at one point), but it's an improvement, so I kept it.
      
      This updates the haddock submodule.
      c955a514
  19. 01 Aug, 2018 1 commit