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. It can be resumed by a project maintainer.
Last successful update .
  1. 17 Mar, 2017 1 commit
  2. 14 Mar, 2017 1 commit
    • Ryan Scott's avatar
      Allow associated types to pattern-match in non-class-bound variables · 67345ccf
      Ryan Scott authored
      Summary:
      After 8136a5cb (#11450), if you have
      a class with an associated type:
      
      ```
      class C a where
        type T a b
      ```
      
      And you try to create an instance of `C` like this:
      
      ```
      instance C Int where
        type T Int Char = Bool
      ```
      
      Then it is rejected, since you're trying to instantiate the variable ``b`` with
      something other than a type variable. But this restriction proves quite
      onerous in practice, as it prevents you from doing things like this:
      
      ```
      class C a where
        type T a (b :: Identity c) :: c
      
      instance C Int where
        type T Int ('Identity x) = x
      ```
      
      You have to resort to an auxiliary type family in order to define this now,
      which becomes extremely tiring. This lifts this restriction and fixes #13398,
      in which it was discovered that adding this restriction broke code in the wild.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari, austin
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3302
      67345ccf
  3. 10 Mar, 2017 1 commit
    • 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
  4. 04 Mar, 2017 1 commit
  5. 26 Feb, 2017 2 commits
    • rwbarton's avatar
      tests: remove extra_files.py (#12223) · 3415bcaa
      rwbarton authored and Ben Gamari's avatar Ben Gamari committed
      The script I used is included as testsuite/driver/kill_extra_files.py,
      though at this point it is for mostly historical interest.
      
      Some of the tests in libraries/hpc relied on extra_files.py, so this
      commit includes an update to that submodule.
      
      One test in libraries/process also relies on extra_files.py, but we
      cannot update that submodule so easily, so for now we special-case it
      in the test driver.
      3415bcaa
    • rwbarton's avatar
      tests: manually move some extra_files into *.T files · 98119f5a
      rwbarton authored and Ben Gamari's avatar Ben Gamari committed
      Some of the *.T files were in libraries/hpc, so this contains an
      update to that submodule.
      98119f5a
  6. 18 Feb, 2017 1 commit
    • Ben Gamari's avatar
      Generalize kind of the (->) tycon · b207b536
      Ben Gamari authored
      This is generalizes the kind of `(->)`, as discussed in #11714.
      
      This involves a few things,
      
       * Generalizing the kind of `funTyCon`, adding two new `RuntimeRep`
      binders,
        ```lang=haskell
      (->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                     (a :: TYPE r1) (b :: TYPE r2).
              a -> b -> *
        ```
      
       * Unsaturated applications of `(->)` are expressed as explicit
      `TyConApp`s
      
       * Saturated applications of `(->)` are expressed as `FunTy` as they are
      currently
      
       * Saturated applications of `(->)` are expressed by a new `FunCo`
      constructor in coercions
      
       * `splitTyConApp` needs to ensure that `FunTy`s are split to a
      `TyConApp`
         of `(->)` with the appropriate `RuntimeRep` arguments
      
       * Teach CoreLint to check that all saturated applications of `(->)` are
      represented with `FunTy`
      
      At the moment I assume that `Constraint ~ *`, which is an annoying
      source of complexity. This will
      be simplified once D3023 is resolved.
      
      Also, this introduces two known regressions,
      
      `tcfail181`, `T10403`
      =====================
      Only shows the instance,
      
          instance Monad ((->) r) -- Defined in ‘GHC.Base’
      
      in its error message when -fprint-potential-instances is used. This is
      because its instance head now mentions 'LiftedRep which is not in scope.
      I'm not entirely sure of the right way to fix this so I'm just accepting
      the new output for now.
      
      T5963 (Typeable)
      ================
      
      T5963 is now broken since Data.Typeable.Internals.mkFunTy computes its
      fingerprint without the RuntimeRep variables that (->) expects. This
      will be fixed with the merge of D2010.
      
      Haddock performance
      ===================
      
      The `haddock.base` and `haddock.Cabal` tests regress in allocations by
      about 20%. This certainly hurts, but it's also not entirely unexpected:
      the size of every function type grows with this patch and Haddock has a
      lot of functions in its heap.
      b207b536
  7. 14 Feb, 2017 1 commit
    • rwbarton's avatar
      Check local type family instances against all imported ones · bedcb716
      rwbarton authored and Ben Gamari's avatar Ben Gamari committed
      We previously checked type family instance declarations
      in a module for consistency with all instances that we happened
      to have read into the EPS or HPT. It was possible to arrange that
      an imported type family instance (used by an imported function)
      was in a module whose interface file was never read during
      compilation; then we wouldn't check consistency of local instances
      with this imported instance and as a result type safety was lost.
      
      With this patch, we still check consistency of local type family
      instances with all type family instances that we have loaded; but
      we make sure to load the interface files of all our imports that
      define family instances first. More selective consistency checking
      is left to #13102.
      
      On the other hand, we can now safely assume when we import a module
      that it has been checked for consistency with its imports. So we
      can save checking in checkFamInstConsistency, and overall we should
      have less work to do now.
      
      This patch also adds a note describing the Plan for ensuring type
      family consistency.
      
      Test Plan: Two new tests added; harbormaster
      
      Reviewers: austin, simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: ggreif, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2992
      bedcb716
  8. 10 Feb, 2017 1 commit
  9. 06 Feb, 2017 2 commits
    • Matthew Pickering's avatar
      Don't return empty initial uncovered set for an unsat context · adb565aa
      Matthew Pickering authored and Ben Gamari's avatar Ben Gamari committed
      Previously when the checker encountered an unsatisfiable term of type
      context it would return an empty initial uncovered set. This caused all
      pattern matches in the context to be reported as redudant.
      
      This is arguably correct behaviour as they will never be reached but it
      is better to recover and provide accurate warnings for these cases to
      avoid error cascades. It would perhaps be better to report an error to
      the user about an inacessible branch but this is certainly better than
      many confusing redundant match warnings.
      
      Reviewers: gkaracha, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3064
      adb565aa
    • rwbarton's avatar
      Don't replace type family instances with the same LHS in GHCi (#7102) · 0abe7361
      rwbarton authored and Ben Gamari's avatar Ben Gamari committed
      This fixes the easy part of #7102 by removing the logic that lets the
      user replace a type family instance with a new one with the same LHS.
      As discussed on that ticket, this is unsound in general. Better to have
      the user redefine the type family from scratch.
      
      The example from comment:7 involving loading modules into ghci is not
      fixed yet; it actually doesn't rely on the instances having the same LHS.
      This commit adds an expect_broken test for that example as well.
      
      Test Plan: T7102a for the fix; T7102 is the test not fixed yet
      
      Reviewers: dfeuer, austin, bgamari, goldfire
      
      Reviewed By: dfeuer
      
      Subscribers: dfeuer, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2994
      0abe7361
  10. 02 Feb, 2017 2 commits
  11. 23 Jan, 2017 1 commit
    • Ryan Scott's avatar
      Don't quantify implicit type variables when quoting type signatures in TH · 729a5e45
      Ryan Scott authored
      Summary:
      A bug was introduced in GHC 8.0 in which Template Haskell-quoted type
      signatures would quantify _all_ their type variables, even the implicit ones.
      This would cause splices like this:
      
      ```
      $([d| idProxy :: forall proxy (a :: k). proxy a -> proxy a
            idProxy x = x
         |])
      ```
      
      To splice back in something that was slightly different:
      
      ```
      idProxy :: forall k proxy (a :: k). proxy a -> proxy a
      idProxy x = x
      ```
      
      Notice that the kind variable `k` is now explicitly quantified! What's worse,
      this now requires the `TypeInType` extension to be enabled.
      
      This changes the behavior of Template Haskell quoting to never explicitly
      quantify type variables which are implicitly quantified in the source.
      
      There are some other places where this behavior pops up too, including
      class methods, type ascriptions, `SPECIALIZE` pragmas, foreign imports,
      and pattern synonynms (#13018), so I fixed those too.
      
      Fixes #13018 and #13123.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Reviewed By: simonpj, goldfire
      
      Subscribers: simonpj, mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2974
      
      GHC Trac Issues: #13018, #13123
      729a5e45
  12. 22 Jan, 2017 1 commit
  13. 20 Jan, 2017 2 commits
  14. 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
  15. 06 Jan, 2017 1 commit
  16. 27 Dec, 2016 1 commit
    • Peter Trommler's avatar
      Testsuite: Skip failing tests on PowerPC 64-bit · 4dec7d19
      Peter Trommler authored and Ben Gamari's avatar Ben Gamari committed
      The Power ISA says the result of a division by zero is undefined.  So
      ignore stdout on PowerPC 64-bit systems.
      
      Disable ext-interp tests on 64-bit PowerPC.  We don't have support for
      PowerPC 64-bit ELF in the RTS linker, which is needed for the external
      interpreter.
      
      Test Plan: ./validate
      
      Reviewers: austin, simonmar, hvr, erikd, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2782
      4dec7d19
  17. 23 Dec, 2016 1 commit
    • Rufflewind's avatar
      Add caret diagnostics · 158530a5
      Rufflewind authored and Ben Gamari's avatar Ben Gamari committed
      This is controlled by -f[no-]diagnostics-show-caret.
      
      Example of what it looks like:
      ```
          |
       42 |     x = 1 + ()
          |         ^^^^^^
      ```
      This is appended to each diagnostic message.
      
      Test Plan:
      testsuite/tests/warnings/should_fail/CaretDiagnostics1
      testsuite/tests/warnings/should_fail/CaretDiagnostics2
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: joehillen, mpickering, Phyx, simonpj, alanz, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2718
      
      GHC Trac Issues: #8809
      158530a5
  18. 15 Dec, 2016 1 commit
  19. 13 Dec, 2016 1 commit
  20. 08 Dec, 2016 1 commit
  21. 07 Dec, 2016 1 commit
    • Alan Zimmerman's avatar
      Add HsSyn prettyprinter tests · 499e4382
      Alan Zimmerman authored
      Summary:
      Add prettyprinter tests, which take a file, parse it, pretty print it,
      re-parse the pretty printed version and then compare the original and
      new ASTs (ignoring locations)
      
      Updates haddock submodule to match the AST changes.
      
      There are three issues outstanding
      
      1. Extra parens around a context are not reproduced. This will require an
         AST change and will be done in a separate patch.
      
      2. Currently if an `HsTickPragma` is found, this is not pretty-printed,
         to prevent noise in the output.
      
         I am not sure what the desired behaviour in this case is, so have left
         it as before. Test Ppr047 is marked as expected fail for this.
      
      3. Apart from in a context, the ParsedSource AST keeps all the parens from
         the original source.  Something is happening in the renamer to remove the
         parens around visible type application, causing T12530 to fail, as the
         dumped splice decl is after the renamer.
      
         This needs to be fixed by keeping the parens, but I do not know where they
         are being removed.  I have amended the test to pass, by removing the parens
         in the expected output.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, mpickering, simonpj, bgamari, austin
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: simonpj, goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2752
      
      GHC Trac Issues: #3384
      499e4382
  22. 29 Nov, 2016 1 commit
  23. 21 Nov, 2016 3 commits
  24. 16 Nov, 2016 1 commit
  25. 13 Nov, 2016 1 commit
    • Ben Gamari's avatar
      Kill Type pretty-printer · 6c0f10fa
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      Here we consolidate the pretty-printing logic for types in IfaceType. We
      need IfaceType regardless and the printer for Type can be implemented in
      terms of that for IfaceType. See #11660.
      
      Note that this is very much a work-in-progress. Namely I still have yet
      to ponder how to ease the hs-boot file situation, still need to rip out
      more dead code, need to move some of the special cases for, e.g., `*` to
      the IfaceType printer, and need to get it to validate. That being said,
      it comes close to validating as-is.
      
      Test Plan: Validate
      
      Reviewers: goldfire, austin
      
      Subscribers: goldfire, thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D2528
      
      GHC Trac Issues: #11660
      6c0f10fa
  26. 12 Nov, 2016 1 commit
  27. 21 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      A collection of type-inference refactorings. · 3f5673f3
      Simon Peyton Jones authored
      This patch does a raft of useful tidy-ups in the type checker.
      I've been meaning to do this for some time, and finally made
      time to do it en route to ICFP.
      
      1. Modify TcType.ExpType to make a distinct data type,
         InferResult for the Infer case, and consequential
         refactoring.
      
      2. Define a new function TcUnify.fillInferResult, to fill in
         an InferResult. It uses TcMType.promoteTcType to promote
         the type to the level of the InferResult.
         See TcMType Note [Promoting a type]
         This refactoring is in preparation for an improvement
         to typechecking pattern bindings, coming next.
      
         I flirted with an elaborate scheme to give better
         higher rank inference, but it was just too complicated.
         See TcMType Note [Promotion and higher rank types]
      
      3. Add to InferResult a new field ir_inst :: Bool to say
         whether or not the type used to fill in the
         InferResult should be deeply instantiated.  See
         TcUnify Note [Deep instantiation of InferResult].
      
      4. A...
      3f5673f3
  28. 08 Oct, 2016 1 commit
  29. 01 Oct, 2016 1 commit
    • mniip's avatar
      GHCi: Don't remove shadowed bindings from typechecker scope. · 59d7ee53
      mniip authored and Ben Gamari's avatar Ben Gamari committed
      The shadowed out bindings are accessible via qualified names like
      Ghci1.foo.  Since they are accessable in the renamer the typechecker
      should be able to see them too.  As a consequence they show up in :show
      bindings.
      
      This fixes T11547
      
      Test Plan:
      Fixed current tests to accomodate to new stuff in :show bindings
      Added a test that verifies that the typechecker doesn't crash
      
      Reviewers: austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2447
      
      GHC Trac Issues: #11547
      59d7ee53
  30. 12 Sep, 2016 1 commit
    • Simon Peyton Jones's avatar
      Be less picky about reporing inaccessible code · 03541cba
      Simon Peyton Jones authored
      Triggered by the discussion on Trac #12466, this patch
      makes GHC less aggressive about reporting an error when
      there are insoluble Givens.
      
      Being so agressive was making some libraries fail to
      compile, and is arguably wrong in at least some cases.
      See the discussion on the ticket.
      
      Several test now pass when they failed before; see
      the files-modified list for this patch.
      03541cba
  31. 31 Aug, 2016 1 commit
  32. 30 Aug, 2016 1 commit
    • mniip's avatar
      Tag pointers in interpreted constructors · a25bf267
      mniip authored and Ben Gamari's avatar Ben Gamari committed
      Instead of stg_interp_constr_entry there are now 7 functions (one for
      each value of the tag bits) that tag the constructor pointer before
      returning. This is consistent with compiled constructors' entry code,
      and expectations that compiled code places on compiled constructors. The
      iserv protocol is extended with an extra field that explains what
      pointer tag the constructor should use.
      
      Test Plan: Added tests for #12523
      
      Reviewers: erikd, bgamari, hvr, austin, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: osa1, thomie, rwbarton
      
      Differential Revision: https://phabricator.haskell.org/D2473
      
      GHC Trac Issues: #12523
      a25bf267
  33. 23 Aug, 2016 1 commit
  34. 14 Jul, 2016 1 commit