1. 19 Aug, 2019 1 commit
  2. 18 Aug, 2019 4 commits
  3. 16 Aug, 2019 3 commits
  4. 15 Aug, 2019 1 commit
    • James Foster's avatar
      Remove unused imports of the form 'import foo ()' (Fixes #17065) · ca71d551
      James Foster authored
      These kinds of imports are necessary in some cases such as
      importing instances of typeclasses or intentionally creating
      dependencies in the build system, but '-Wunused-imports' can't
      detect when they are no longer needed. This commit removes the
      unused ones currently in the code base (not including test files
      or submodules), with the hope that doing so may increase
      parallelism in the build system by removing unnecessary
  5. 14 Aug, 2019 2 commits
    • Richard Eisenberg's avatar
      GHCi supports not-necessarily-lifted join points · 6329c70a
      Richard Eisenberg authored
      Fixes #16509.
      See Note [Not-necessarily-lifted join points] in ByteCodeGen,
      which tells the full story.
      This commit also adds some comments and cleans some code
      in the byte-code generator, as I was exploring around trying
      to understand it.
      (This commit removes an old test -- this is really a GHCi problem,
      not a pattern-synonym problem.)
      test case: ghci/scripts/T16509
    • Andreas Klebinger's avatar
      Rework the Binary Integer instance. · a38104b4
      Andreas Klebinger authored
      We used to serialise large integers as strings. Now they are serialized
      as a list of Bytes.
      This changes the size for a Integer in the higher 64bit range from 77 to
      9 bytes when written to disk.
      The impact on the general case is small (<1% for interface files) as we
      don't use many Integers. But for code that uses many this should be a
      nice benefit.
  6. 13 Aug, 2019 1 commit
  7. 10 Aug, 2019 3 commits
    • Ömer Sinan Ağacan's avatar
      Reformat comments in StgSyn · 672cbab2
      Ömer Sinan Ağacan authored
      This does not make any changes in the contents -- formatting only.
      Previously the comments were too noisy and I've always found it very
      hard to read. Hopefully it's easier to read now.
    • Ben Gamari's avatar
      Add timing on loadInterface · 422ffce0
      Ben Gamari authored
      AndreasK recently mentioned that he thought that interface file loading
      may be a non-trivial cost. Let's measure.
    • Joachim Breitner's avatar
      Consolidate `TablesNextToCode` and `GhcUnreigsterised` in configure (#15548) · 81860281
      Joachim Breitner authored
      `TablesNextToCode` is now a substituted by configure, where it has the
      correct defaults and error handling. Nowhere else needs to duplicate
      that, though we may want the compiler to to guard against bogus settings
      I renamed it from `GhcEnableTablesNextToCode` to `TablesNextToCode` to:
       - Help me guard against any unfixed usages
       - Remove any lingering connotation that this flag needs to be combined
         with `GhcUnreigsterised`.
      Original reviewers:
      Original subscribers: TerrorJack, rwbarton, carter
      Original Differential Revision: https://phabricator.haskell.org/D5082
  8. 07 Aug, 2019 5 commits
  9. 04 Aug, 2019 1 commit
    • Simon Peyton Jones's avatar
      Don't float unlifted join points to top level · 7d8d0012
      Simon Peyton Jones authored
      Ticket #16978 showed that we were floating a recursive,
      unlifted join point to top level.  It's very much a corner
          joinrec j :: Int#
                  j = jump j
          in ...
      But somehow it showed up in a real program.
      For non-recursive bindings in SetLevels.lvlBind we were already
      (correctly) checking for unlifted bindings, but when I wrote
      that code I didn't think that a /recursive/ binding could be
      unlifted but /join-points/ can be!
      Actually I don't think that SetLevels should be floating
      join points at all.  SetLevels really floats things to move
      stuff out of loops and save allocation; but none of that applies
      to join points.  The only reason to float join points is in
      cases like
         join j1 x = join j2 y = ...
                     in ...
      which we might want to swizzle to
         join j2 x y = ... in
         join j1 x = ...
         in ...
      because now j1 looks small and might be inlined away altogether.
      But this is a very local float perhaps better done in the simplifier.
      Still: this patch fixes the crash, and does so in a way that is
      harmless if/when we change our strategy for floating join points.
  10. 03 Aug, 2019 3 commits
  11. 02 Aug, 2019 2 commits
    • Ryan Scott's avatar
      Use injectiveVarsOfType to catch dodgy type family instance binders (#17008) · 93bed40a
      Ryan Scott authored
      Previously, we detected dodgy type family instances binders by
      expanding type synonyms (via `exactTyCoVarsOfType`) and looking for
      type variables on the RHS that weren't mentioned on the (expanded)
      LHS. But this doesn't account for type families (like the example
      in #17008), so we instead use `injectiveVarsOfType` to only count
      LHS type variables that are in injective positions. That way, the `a`
      in `type instance F (x :: T a) = a` will not count if `T` is a type
      synonym _or_ a type family.
      Along the way, I moved `exactTyCoVarsOfType` to `TyCoFVs` to live
      alongside its sibling functions that also compute free variables.
      Fixes #17008.
    • Ryan Scott's avatar
      Rip out 9-year-old pattern variable hack (#17007) · 1b9d32b8
      Ryan Scott authored
      GHC had an ad hoc validity check in place to rule out pattern
      variables bound by type synonyms, such as in the following example:
      type ItemColID a b = Int  -- Discards a,b
      get :: ItemColID a b -> ItemColID a b
      get (x :: ItemColID a b) = x :: ItemColID a b
      This hack is wholly unnecessary nowadays, since OutsideIn(X) is more
      than capable of instantiating `a` and `b` to `Any`. In light of this,
      let's rip out this validity check.
      Fixes #17007.
  12. 31 Jul, 2019 3 commits
    • Ben Gamari's avatar
      Work around redundant import issue · 787fab43
      Ben Gamari authored
      As mentioned in #16997, GHC currently complains about this import.
      In general I'm reluctant to paper over things like this but in the case
      of an hs-boot file I think adding an import list is the right thing to
      do regardless of the bug.
    • Ben Gamari's avatar
      Move tyConAppNeedsKindSig to Type · 88410e77
      Ben Gamari authored
      Previously it was awkwardly in TyCoFVs (and before that in TyCoRep).
      Type seems like a sensible place for it to live.
    • Ben Gamari's avatar
      Break up TyCoRep · 371dadfb
      Ben Gamari authored
      This breaks up the monstrous TyCoReps module into several new modules by
       * TyCoRep: Contains the `Coercion`, `Type`, and related type
         definitions and a few simple predicates but nothing further
       * TyCoPpr: Contains the the pretty-printer logic
       * TyCoFVs: Contains the free variable computations (and
         `tyConAppNeedsKindSig`, although I suspect this should change)
       * TyCoSubst: Contains the substitution logic for types and coercions
       * TyCoTidy: Contains the tidying logic for types
      While we are able to eliminate a good number of `SOURCE` imports (and
      make a few others smaller) with this change, we must introduce one new
      `hs-boot` file for `TyCoPpr` so that `TyCoRep` can define `Outputable`
      instances for the types it defines.
      Metric Increase:
  13. 30 Jul, 2019 1 commit
  14. 29 Jul, 2019 1 commit
    • Richard Eisenberg's avatar
      Add Note [RuntimeRep and PrimRep] in RepType · 9f8cdb35
      Richard Eisenberg authored
      Also adds Note [Getting from RuntimeRep to PrimRep], which
      deocuments a related thorny process.
      This Note addresses #16964, which correctly observes that
      documentation for this thorny design is lacking.
      Documentation only.
  15. 26 Jul, 2019 4 commits
    • Vladislav Zavialov's avatar
    • Vladislav Zavialov's avatar
      TemplateHaskell: reifyType (#16976) · 00d9d284
      Vladislav Zavialov authored
    • Alex D's avatar
      Change behaviour of -ddump-cmm-verbose to dump each Cmm pass output to a... · aae0457f
      Alex D authored
      Change behaviour of -ddump-cmm-verbose to dump each Cmm pass output to a separate file and add -ddump-cmm-verbose-by-proc to keep old behaviour (#16930)
    • Ryan Scott's avatar
      Banish reportFloatingViaTvs to the shadow realm (#15831, #16181) · 30b6f391
      Ryan Scott authored
      GHC used to reject programs of this form:
      newtype Age = MkAge Int
        deriving Eq via Const Int a
      That's because an earlier implementation of `DerivingVia` would
      generate the following instance:
      instance Eq Age where
        (==) = coerce @(Const Int a -> Const Int a -> Bool)
                      @(Age         -> Age         -> Bool)
      Note that the `a` in `Const Int a` is not bound anywhere, which
      causes all sorts of issues. I figured that no one would ever want to
      write code like this anyway, so I simply banned "floating" `via` type
      variables like `a`, checking for their presence in the aptly named
      `reportFloatingViaTvs` function.
      `reportFloatingViaTvs` ended up being implemented in a subtly
      incorrect way, as #15831 demonstrates. Following counsel with the
      sage of gold fire, I decided to abandon `reportFloatingViaTvs`
      entirely and opt for a different approach that would _accept_
      the instance above. This is because GHC now generates this instance
      instance forall a. Eq Age where
        (==) = coerce @(Const Int a -> Const Int a -> Bool)
                      @(Age         -> Age         -> Bool)
      Notice that we now explicitly quantify the `a` in
      `instance forall a. Eq Age`, so everything is peachy scoping-wise.
      See `Note [Floating `via` type variables]` in `TcDeriv` for the full
      A pleasant benefit of this refactoring is that it made it much easier
      to catch the problem observed in #16181, so this patch fixes that
      issue too.
      Fixes #15831. Fixes #16181.
  16. 25 Jul, 2019 4 commits
  17. 24 Jul, 2019 1 commit