This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts, and can be resumed by a project maintainer.
Last successful update .
  1. 21 Aug, 2018 2 commits
    • Simon Peyton Jones's avatar
      Set strictness correctly for JoinIds · b81fc821
      Simon Peyton Jones authored
      We were failing to keep correct strictness info when eta-expanding
      join points; Trac #15517.   The situation was something like
      
        \q v eta ->
           let j x = error "blah
               -- STR Lx   bottoming!
           in case y of
                 A -> j x eta
                 B -> blah
                 C -> j x eta
      
      So we spot j as a join point and eta-expand it.  But we must
      also adjust the stricness info, else it vlaimes to bottom after
      one arg is applied but now it has become two.
      
      I fixed this in two places:
      
       - In CoreOpt.joinPointBinding_maybe, adjust strictness info
      
       - In SimplUtils.tryEtaExpandRhs, return consistent values
         for arity and bottom-ness
      
      (cherry picked from commit ce6ce788)
      b81fc821
    • Ryan Scott's avatar
      Be mindful of GADT tyvar order when desugaring record updates · 2d308da2
      Ryan Scott authored
      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
      
      (cherry picked from commit 63b6a1d4)
      2d308da2
  2. 20 Aug, 2018 1 commit
  3. 19 Aug, 2018 3 commits
    • wz1000's avatar
      Check if files are same in combineSrcSpans · 033d6ac7
      wz1000 authored
      Summary: If this is not checked, SrcSpans are sometimes mangled by CPP.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, dfeuer
      
      Reviewed By: bgamari
      
      Subscribers: dfeuer, rwbarton, thomie, carter
      
      GHC Trac Issues: #15279
      
      Differential Revision: https://phabricator.haskell.org/D4866
      
      (cherry picked from commit f7f9820e)
      033d6ac7
    • Ryan Scott's avatar
      Fix #15527 by pretty-printing an RdrName prefixly · fb8b2cb1
      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
      
      (cherry picked from commit 5238f204)
      fb8b2cb1
    • Christiaan Baaij's avatar
      Filter plugin dylib locations · 13105a1a
      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
      
      (cherry picked from commit b324c562)
      13105a1a
  4. 11 Aug, 2018 1 commit
  5. 10 Aug, 2018 1 commit
  6. 09 Aug, 2018 7 commits
  7. 08 Aug, 2018 1 commit
  8. 07 Aug, 2018 2 commits
  9. 06 Aug, 2018 13 commits
  10. 03 Aug, 2018 1 commit
  11. 02 Aug, 2018 7 commits
    • Matthías Páll Gissurarson's avatar
      Clone relevant constraints to avoid side-effects on HoleDests. Fixes #15370. · 588364c3
      Matthías Páll Gissurarson authored
      Summary: When looking for valid hole fits, the constraints relevant
      to the hole may sometimes contain a HoleDest. Previously,
      these were not cloned, which could cause the filling of filled
      coercion hole being, which would cause an assert to fail. This is now fixed.
      
      Test Plan: Regression test included.
      
      Reviewers: simonpj, bgamari, goldfire
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15370
      
      Differential Revision: https://phabricator.haskell.org/D5004
      
      (cherry picked from commit 0dc86f6b)
      588364c3
    • Christiaan Baaij's avatar
      Plugin dependency information is stored separately · e86db0d5
      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
      
      (cherry picked from commit 52065e95)
      e86db0d5
    • Simon Peyton Jones's avatar
      Treat isConstraintKind more consistently · 6a7cb806
      Simon Peyton Jones authored
      It turned out that we were not being consistent
      about our use of isConstraintKind.
      
      It's delicate, because the typechecker treats Constraint and Type as
      /distinct/, whereas they are the /same/ in the rest of the compiler
      (Trac #11715).
      
      And had it wrong, which led to Trac #15412.  This patch does the
      following:
      
      * Rename isConstraintKind      to tcIsConstraintKind
               returnsConstraintKind to tcReturnsConstraintKind
        to emphasise that they use the 'tcView' view of types.
      
      * Move these functions, and some related ones (tcIsLiftedTypeKind),
        from Kind.hs, to group together in Type.hs, alongside isPredTy.
      
      It feels very unsatisfactory that these 'tcX' functions live in Type,
      but it happens because isPredTy is called later in the compiler
      too.  But it's a consequence of the 'Constraint vs Type' dilemma.
      
      (cherry picked from commit c5d31df7)
      6a7cb806
    • Ryan Scott's avatar
      Fix #15385 by using addDictsDs in matchGuards · e649085b
      Ryan Scott authored
      When coverage checking pattern-matches, we rely on the call
      sites in the desugarer to populate the local dictionaries and term
      evidence in scope using `addDictsDs` and `addTmCsDs`. But it turns
      out that only the call site for desugaring `case` expressions was
      actually doing this properly. In another part of the desugarer,
      `matchGuards` (which handles pattern guards), it did not update the
      local dictionaries in scope at all, leading to #15385.
      
      Fixing this is relatively straightforward: just augment the
      `BindStmt` case of `matchGuards` to use `addDictsDs` and `addTmCsDs`.
      Accomplishing this took a little bit of import/export tweaking:
      
      * We now need to export `collectEvVarsPat` from `HsPat.hs`.
      * To avoid an import cycle with `Check.hs`, I moved `isTrueLHsExpr`
        from `DsGRHSs.hs` to `DsUtils.hs`, which resides lower on the
        import chain.
      
      Test Plan: make test TEST=T15385
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15385
      
      Differential Revision: https://phabricator.haskell.org/D4968
      
      (cherry picked from commit 9d388eb8)
      e649085b
    • Simon Peyton Jones's avatar
      Small refactor in desugar of pattern matching · 42c51e2f
      Simon Peyton Jones authored
      In reviewing Phab:D4968 for Trac #15385 I saw a small
      but simple refactor to avoid unnecessary work in the
      desugarer.
      
      This patch just arranges to call
         matchSinglePatVar v ...
      rather than
         matchSinglePat (Var v) ...
      
      The more specialised function already existed, as
         match_single_pat_var
      
      I also added more comments about decideBangHood
      
      (cherry picked from commit 45cfe651)
      42c51e2f
    • Richard Eisenberg's avatar
      Remove the type-checking knot. · 59f38587
      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
      
      (cherry picked from commit f8618a9b)
      59f38587
    • Ben Gamari's avatar
      Bump Cabal submodule to 2.4 · ff086cc1
      Ben Gamari authored
      ff086cc1
  12. 01 Aug, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15450 by refactoring checkEmptyCase' · ebd773a0
      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
      
      (cherry picked from commit 7f3cb50d)
      ebd773a0