1. 21 Aug, 2018 9 commits
  2. 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
  3. 18 Aug, 2018 1 commit
  4. 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
  5. 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
  6. 15 Aug, 2018 1 commit
  7. 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
  8. 12 Aug, 2018 5 commits
  9. 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
  10. 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
  11. 06 Aug, 2018 6 commits
  12. 05 Aug, 2018 1 commit
  13. 04 Aug, 2018 1 commit
  14. 03 Aug, 2018 1 commit
  15. 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
  16. 01 Aug, 2018 4 commits
    • Vladislav Zavialov's avatar
      Fix #15415 and simplify tcWildCardBinders · 120cc9f8
      Vladislav Zavialov authored
      Test Plan: Validate
      
      Reviewers: goldfire, simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: RyanGlScott, rwbarton, thomie, carter
      
      GHC Trac Issues: #15415
      
      Differential Revision: https://phabricator.haskell.org/D5022
      120cc9f8
    • Ryan Scott's avatar
      Fix #15450 by refactoring checkEmptyCase' · 7f3cb50d
      Ryan Scott authored
      `checkEmptyCase'` (the code path for coverage-checking
      `EmptyCase` expressions) had a fair bit of code duplication from the
      code path for coverage-checking non-`EmptyCase` expressions, and to
      make things worse, it behaved subtly different in some respects (for
      instance, emitting different warnings under unsatisfiable
      constraints, as shown in #15450). This patch attempts to clean up
      both this discrepancy and the code duplication by doing the
      following:
      
      * Factor out a `pmInitialTmTyCs` function, which returns the initial
        set of term and type constraints to use when beginning coverage
        checking. If either set of constraints is unsatisfiable, we use an
        empty set in its place so that we can continue to emit as many
        warnings as possible. (The code path for non-`EmptyCase`
        expressions was doing this already, but not the code path for
        `EmptyCase` expressions, which is the root cause of #15450.)
      
        Along the way, I added a `Note` to explain why we do this.
      * Factor out a `pmIsSatisfiable` constraint which checks if a set of
        term and type constraints are satisfiable. This does not change any
        existing behavior; this is just for the sake of deduplicating code.
      
      Test Plan: make test TEST=T15450
      
      Reviewers: simonpj, bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15450
      
      Differential Revision: https://phabricator.haskell.org/D5017
      7f3cb50d
    • Christiaan Baaij's avatar
      Plugin dependency information is stored separately · 52065e95
      Christiaan Baaij authored
      We need to store the used plugins so that we recompile
      a module when a plugin that it uses is recompiled.
      
      However, storing the `ModuleName`s of the plugins used by a
      module in the `dep_mods` field made the rest of GHC think
      that they belong in the HPT, causing at least the issues
      reported in #15234
      
      We therefor store the `ModuleName`s of the plugins in a
      new field, `dep_plgins`, which is only used the the
      recompilation logic.
      
      Reviewers: mpickering, bgamari
      
      Reviewed By: mpickering, bgamari
      
      Subscribers: alpmestan, rwbarton, thomie, carter
      
      GHC Trac Issues: #15234
      
      Differential Revision: https://phabricator.haskell.org/D4937
      52065e95
    • Richard Eisenberg's avatar
      Remove the type-checking knot. · f8618a9b
      Richard Eisenberg authored
      Bug #15380 hangs because a knot-tied TyCon ended up in a kind.
      Looking at the code in tcInferApps, I'm amazed this hasn't happened
      before! I couldn't think of a good way to fix it (with dependent
      types, we can't really keep types out of kinds, after all), so
      I just went ahead and removed the knot.
      
      This was remarkably easy to do. In tcTyVar, when we find a TcTyCon,
      just use it. (Previously, we looked up the knot-tied TyCon and used
      that.) Then, during the final zonk, replace TcTyCons with the real,
      full-blooded TyCons in the global environment. It's all very easy.
      
      The new bit is explained in the existing
      Note [Type checking recursive type and class declarations]
      in TcTyClsDecls.
      
      Naturally, I removed various references to the knot and the
      zonkTcTypeInKnot (and related) functions. Now, we can print types
      during type checking with abandon!
      
      NB: There is a teensy error message regression with this patch,
      around the ordering of quantified type variables. This ordering
      problem is fixed (I believe) with the patch for #14880. The ordering
      affects only internal variables that cannot be instantiated with
      any kind of visible type application.
      
      There is also a teensy regression around the printing of types
      in TH splices. I think this is really a TH bug and will file
      separately.
      
      Test case: dependent/should_fail/T15380
      f8618a9b