1. 06 Mar, 2017 2 commits
  2. 03 Mar, 2017 2 commits
  3. 02 Mar, 2017 2 commits
    • David Feuer's avatar
      Prohibit RULES changing constructors · bc332b31
      David Feuer authored
      Previously, `RULES` like
      
      ```
      {-# RULES
      "JustNothing" forall x . Just x = Nothing
       #-}
      ```
      
      were allowed. Simon Peyton Jones say this seems to have been a
      mistake, that such rules have never been supported intentionally,
      and that he doesn't know if they can break in horrible ways.
      Furthermore, Ben Gamari and Reid Barton are considering trying to
      detect the presence of "static data" that the simplifier doesn't
      need to traverse at all. Such rules do not play well with that.
      So for now, we ban them altogether. In most cases, it's possible
      to work around the ban using hand-written wrapper functions.
      
      Reviewers: austin, simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3169
      bc332b31
    • David Feuer's avatar
      Eliminate ListSetOps from imp_trust_pkgs · ae676198
      David Feuer authored
      Eliminate ListSetOps from imp_trust_pkgs and imp_dep_pkgs
      
      Replace Map with NameEnv in TmOracle
      
      Reviewers: austin, dfeuer, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3113
      ae676198
  4. 01 Mar, 2017 1 commit
    • David Feuer's avatar
      Upgrade UniqSet to a newtype · cbe569a5
      David Feuer authored
      The fundamental problem with `type UniqSet = UniqFM` is that `UniqSet`
      has a key invariant `UniqFM` does not. For example, `fmap` over
      `UniqSet` will generally produce nonsense.
      
      * Upgrade `UniqSet` from a type synonym to a newtype.
      
      * Remove unused and shady `extendVarSet_C` and `addOneToUniqSet_C`.
      
      * Use cached unique in `tyConsOfType` by replacing
        `unitNameEnv (tyConName tc) tc` with `unitUniqSet tc`.
      
      Reviewers: austin, hvr, goldfire, simonmar, niteria, bgamari
      
      Reviewed By: niteria
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3146
      cbe569a5
  5. 26 Feb, 2017 1 commit
    • Joachim Breitner's avatar
      Ensure that Literals are in range · 6dfc5ebf
      Joachim Breitner authored
      This commit fixes several bugs related to case expressions
      involving numeric literals which are not in the range of values of
      their (fixed-width, integral) type.
      
      There is a new invariant on Literal: The argument of a MachInt[64]
      or MachWord[64] must lie within the range of the corresponding
      primitive type Int[64]# or Word[64]#, as defined by the target machine.
      This invariant is enforced in mkMachInt[64]/mkMachWord[64] by wrapping
      the argument to the target type's range if necessary.
      
      Test Plan: Test Plan: make slowtest TEST="T9533 T9533b T9533c T10245
      T10246"
      
      Trac issues: #9533, #10245, #10246, #13171
      
      Reviewers: simonmar, simonpj, austin, bgamari, nomeata
      
      Reviewed By: bgamari
      
      Subscribers: thomie, rwbarton
      
      Differential Revision: https://phabricator.haskell.org/D810
      6dfc5ebf
  6. 20 Feb, 2017 1 commit
    • Simon Peyton Jones's avatar
      Kill off the remaining Rec [] · 8a9b57f6
      Simon Peyton Jones authored
      The desugarer was producing an empty Rec group, which is never
      supposed to happen.  This small patch stops that happening.
      
      Next up: Lint should check.
      8a9b57f6
  7. 18 Feb, 2017 1 commit
    • Ben Gamari's avatar
      Type-indexed Typeable · 8fa4bf9a
      Ben Gamari authored
      This at long last realizes the ideas for type-indexed Typeable discussed in A
      Reflection on Types (#11011). The general sketch of the project is described on
      the Wiki (Typeable/BenGamari). The general idea is that we are adding a type
      index to `TypeRep`,
      
          data TypeRep (a :: k)
      
      This index allows the typechecker to reason about the type represented by the `TypeRep`.
      This index representation mechanism is exposed as `Type.Reflection`, which also provides
      a number of patterns for inspecting `TypeRep`s,
      
      ```lang=haskell
      pattern TRFun :: forall k (fun :: k). ()
                    => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                              (arg :: TYPE r1) (res :: TYPE r2).
                       (k ~ Type, fun ~~ (arg -> res))
                    => TypeRep arg
                    -> TypeRep res
                    -> TypeRep fun
      
      pattern TRApp :: forall k2 (t :: k2). ()
                    => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b)
                    => TypeRep a -> TypeRep b -> TypeRep t
      
      -- | Pattern match on a type constructor.
      pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a
      
      -- | Pattern match on a type constructor including its instantiated kind
      -- variables.
      pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a
      ```
      
      In addition, we give the user access to the kind of a `TypeRep` (#10343),
      
          typeRepKind :: TypeRep (a :: k) -> TypeRep k
      
      Moreover, all of this plays nicely with 8.2's levity polymorphism, including the
      newly levity polymorphic (->) type constructor.
      
      Library changes
      ---------------
      
      The primary change here is the introduction of a Type.Reflection module to base.
      This module provides access to the new type-indexed TypeRep introduced in this
      patch. We also continue to provide the unindexed Data.Typeable interface, which
      is simply a type synonym for the existentially quantified SomeTypeRep,
      
          data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep
      
      Naturally, this change also touched Data.Dynamic, which can now export the
      Dynamic data constructor. Moreover, I removed a blanket reexport of
      Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable
      now).
      
      We also add a kind heterogeneous type equality type, (:~~:), to
      Data.Type.Equality.
      
      Implementation
      --------------
      
      The implementation strategy is described in Note [Grand plan for Typeable] in
      TcTypeable. None of it was difficult, but it did exercise a number of parts of
      the new levity polymorphism story which had not yet been exercised, which took
      some sorting out.
      
      The rough idea is that we augment the TyCon produced for each type constructor
      with information about the constructor's kind (which we call a KindRep). This
      allows us to reconstruct the monomorphic result kind of an particular
      instantiation of a type constructor given its kind arguments.
      
      Unfortunately all of this takes a fair amount of work to generate and send
      through the compilation pipeline. In particular, the KindReps can unfortunately
      get quite large. Moreover, the simplifier will float out various pieces of them,
      resulting in numerous top-level bindings. Consequently we mark the KindRep
      bindings as noinline, ensuring that the float-outs don't make it into the
      interface file. This is important since there is generally little benefit to
      inlining KindReps and they would otherwise strongly affect compiler performance.
      
      Performance
      -----------
      
      Initially I was hoping to also clear up the remaining holes in Typeable's
      coverage by adding support for both unboxed tuples (#12409) and unboxed sums
      (#13276). While the former was fairly straightforward, the latter ended up being
      quite difficult: while the implementation can support them easily, enabling this
      support causes thousands of Typeable bindings to be emitted to the GHC.Types as
      each arity-N sum tycon brings with it N promoted datacons, each of which has a
      KindRep whose size which itself scales with N. Doing this was simply too
      expensive to be practical; consequently I've disabled support for the time
      being.
      
      Even after disabling sums this change regresses compiler performance far more
      than I would like. In particular there are several testcases in the testsuite
      which consist mostly of types which regress by over 30% in compiler allocations.
      These include (considering the "bytes allocated" metric),
      
       * T1969:  +10%
       * T10858: +23%
       * T3294:  +19%
       * T5631:  +41%
       * T6048:  +23%
       * T9675:  +20%
       * T9872a: +5.2%
       * T9872d: +12%
       * T9233:  +10%
       * T10370: +34%
       * T12425: +30%
       * T12234: +16%
       * 13035:  +17%
       * T4029:  +6.1%
      
      I've spent quite some time chasing down the source of this regression and while
      I was able to make som improvements, I think this approach of generating
      Typeable bindings at time of type definition is doomed to give us unnecessarily
      large compile-time overhead.
      
      In the future I think we should consider moving some of all of the Typeable
      binding generation logic back to the solver (where it was prior to
      91c6b1f5). I've opened #13261 documenting this
      proposal.
      8fa4bf9a
  8. 17 Feb, 2017 1 commit
  9. 14 Feb, 2017 2 commits
    • rwbarton's avatar
      Make deSugarExpr use runTcInteractive · f90e61ad
      rwbarton authored
      Preparation for #13102, which needs to add more logic to
      runTcInteractive, which would need to be duplicated in deSugarExpr.
      
      In order to break an import cycle, I had to move
      "Dependency/fingerprinting code" to a new module
      DsUsage; which seems sensible anyways.
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, snowleopard
      
      Differential Revision: https://phabricator.haskell.org/D3125
      f90e61ad
    • Adam Gundry's avatar
      Implement HasField constraint solving and modify OverloadedLabels · da493897
      Adam Gundry authored
      This implements automatic constraint solving for the new HasField class
      and modifies the existing OverloadedLabels extension, as described in
      the GHC proposal
      (https://github.com/ghc-proposals/ghc-proposals/pull/6). Per the current
      form of the proposal, it does *not* currently introduce a separate
      `OverloadedRecordFields` extension.
      
      This replaces D1687.
      
      The users guide documentation still needs to be written, but I'll do
      that after the implementation is merged, in case there are further
      design changes.
      
      Test Plan: new and modified tests in overloadedrecflds
      
      Reviewers: simonpj, goldfire, dfeuer, bgamari, austin, hvr
      
      Reviewed By: bgamari
      
      Subscribers: maninalift, dfeuer, ysangkok, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2708
      da493897
  10. 09 Feb, 2017 1 commit
  11. 08 Feb, 2017 3 commits
    • Simon Peyton Jones's avatar
      Kill inaccessible-branch complaints in record update · 3cfef763
      Simon Peyton Jones authored
      Trac #12957 (the original case in the Description) showed a record
      update that yielded an "inaccessible code" warning. This should not
      happen; it's just some redundant code generated by the desugarer (later
      pruned away) and it's not the user's fault.
      
      This patch suppresses the warning.  See Check.hs
      Note [Inaccessible warnings for record updates]
      3cfef763
    • Gabor Greif's avatar
      More typos in comments [skip ci] · b990f656
      Gabor Greif authored
      b990f656
    • Matthew Pickering's avatar
      Fix push_bang_into_newtype when the pattern match has no arguments · 062f1123
      Matthew Pickering authored
      Correct behaviour of push_bang_into_newtype when the pattern match has
      no arguments. A user can write
      
      ```
      newtype T = T Int
      
      f :: T -> ()
      f !(T {}) = ()
      ```
      in which case we have to push the bang inwards through the newtype in
      order to achieve the desired strictness properties. This patch fixes
      this special case where the pattern match has no arguments to push the
      bang onto. We now make up a wildcard pattern which is wrapped in the
      bang pattern.
      
      ```
      f (T !_) = ()
      ```
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3057
      062f1123
  12. 06 Feb, 2017 2 commits
    • Gabor Greif's avatar
      Typos in comments [skip ci] · 4aae1918
      Gabor Greif authored
      4aae1918
    • Matthew Pickering's avatar
      Don't return empty initial uncovered set for an unsat context · adb565aa
      Matthew Pickering authored
      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
  13. 03 Feb, 2017 1 commit
    • Sylvain Henry's avatar
      Ditch static flags · bbd3c399
      Sylvain Henry authored
      This patch converts the 4 lasting static flags (read from the command
      line and unsafely stored in immutable global variables) into dynamic
      flags. Most use cases have been converted into reading them from a DynFlags.
      
      In cases for which we don't have easy access to a DynFlags, we read from
      'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'.
      It's not perfect (not thread-safe) but it is still better as we can
      set/unset these 4 flags before each run when using GHC API.
      
      Updates haddock submodule.
      
      Rebased and finished by: bgamari
      
      Test Plan: validate
      
      Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2839
      
      GHC Trac Issues: #8440
      bbd3c399
  14. 02 Feb, 2017 3 commits
  15. 01 Feb, 2017 1 commit
  16. 26 Jan, 2017 2 commits
    • Matthew Pickering's avatar
      Template Haskell support for COMPLETE pragmas · 95dc6dc0
      Matthew Pickering authored
      Reviewers: RyanGlScott, austin, goldfire, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2997
      
      GHC Trac Issues: #13098
      95dc6dc0
    • Matthew Pickering's avatar
      COMPLETE pragmas for enhanced pattern exhaustiveness checking · 1a3f1eeb
      Matthew Pickering authored
      This patch adds a new pragma so that users can specify `COMPLETE` sets of
      `ConLike`s in order to sate the pattern match checker.
      
      A function which matches on all the patterns in a complete grouping
      will not cause the exhaustiveness checker to emit warnings.
      
      ```
      pattern P :: ()
      pattern P = ()
      
      {-# COMPLETE P #-}
      
      foo P = ()
      ```
      
      This example would previously have caused the checker to warn that
      all cases were not matched even though matching on `P` is sufficient to
      make `foo` covering. With the addition of the pragma, the compiler
      will recognise that matching on `P` alone is enough and not emit
      any warnings.
      
      Reviewers: goldfire, gkaracha, alanz, austin, bgamari
      
      Reviewed By: alanz
      
      Subscribers: lelf, nomeata, gkaracha, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2669
      
      GHC Trac Issues: #8779
      1a3f1eeb
  17. 25 Jan, 2017 1 commit
  18. 23 Jan, 2017 2 commits
    • 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
    • Gabor Greif's avatar
      Typos and grammar in manual/comments · 80560e69
      Gabor Greif authored
      80560e69
  19. 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
  20. 18 Jan, 2017 2 commits
  21. 17 Jan, 2017 1 commit
    • David Feuer's avatar
      Split mkInlineUnfolding into two functions · d360ec39
      David Feuer authored
      Previously, `mkInlineUnfolding` took a `Maybe` argument indicating
      whether the caller requested a specific arity.  This was not
      self-documenting at call sites. Now we distinguish between
      `mkInlineUnfolding` and `mkInlineUnfoldingWithArity`.
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2933
      d360ec39
  22. 13 Jan, 2017 1 commit
  23. 06 Jan, 2017 2 commits
  24. 05 Jan, 2017 1 commit
    • Simon Peyton Jones's avatar
      Ensure nested binders have Internal Names · baf9ebe5
      Simon Peyton Jones authored
      This is a long-standing bug.  A nested (non-top-level) binder
      in Core should not have an External Name, like M.x. But
      
      - Lint was not checking this invariant
      
      - The desugarer could generate programs that failed the
        invariant.  An example is in
        tests/deSugar/should_compile/T13043, which had
           let !_ = M.scState in ...
        This desugared to
           let ds = case M.scSate of M.scState { DEFAULT -> () }
           in case ds of () -> ...
      
        We were wrongly re-using that scrutinee as a case binder.
        And Trac #13043 showed that could ultimately lead to two
        top-level bindings with the same closure name.  Alas!
      
      - The desugarer had one other place (in DsUtils.mkCoreAppDs)
        that could generate bogus code
      
      This patch fixes all three bugs, and adds a regression test.
      baf9ebe5
  25. 23 Dec, 2016 1 commit
  26. 22 Dec, 2016 1 commit
  27. 21 Dec, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix 'SPECIALISE instance' · 1a4c04b1
      Simon Peyton Jones authored
      Trac #12944 showed that the DsBinds code that implemented a
      SPECIALISE pragma was inadequate if the constraints solving
      added let-bindings for dictionaries.  The result was that
      we ended up with an unbound dictionary in a DFunUnfolding -- and
      Lint didn't even check for that!
      
      Fixing this was not entirely straightforward
      
      * In DsBinds.dsSpec we use a new function
           TcEvidence.collectHsWrapBinders
        to pick off the lambda binders from the HsWapper
      
      * dsWrapper now returns a (CoreExpr -> CoreExpr) function
      
      * CoreUnfold.specUnfolding now takes a (CoreExpr -> CoreExpr)
        function it can use to specialise the unfolding.
      
      On the whole the code is simpler than before.
      1a4c04b1