1. 23 Jan, 2017 5 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
    • niteria's avatar
      Make checkFamInstConsistency faster · 18ceb148
      niteria authored
      We've noticed that `checkFamInstConsistency` takes 6% of
      overall build time on our codebase.
      I've poked around for a bit and most of type family
      instances are `Rep` from `Generics`. I think those are
      unavoidable, so I don't think we can have less of them.
      
      I also looked at the code and noticed a simple algorithmic
      improvement can be made. The algorithm is pretty simple:
      we take all the family instances from one module (`M1`)
      and test it against another module (`M2`).
      The cost of that is dominated by the size of `M1`, because
      for each instance in `M1` we look it up in the type family
      env from `M2`, and lookup is cheap.
      If `M1` is bigger than `M2`, that's suboptimal, so after
      my change we always iterate through the smaller set.
      
      This drives down the cost of `checkFamInstConsistency`
      to 2%.
      
      Test Plan: harbormaster
      
      Reviewers: simonmar, simonpj, goldfire, rwbarton, bgamari, ezyang, austin
      
      Reviewed By: rwbarton, ezyang
      
      Subscribers: ezyang, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2833
      18ceb148
    • Gabor Greif's avatar
      Typos and grammar in manual/comments · 80560e69
      Gabor Greif authored
      80560e69
    • Simon Peyton Jones's avatar
      Apply the right substitution in ty-fam improvement · 2b64e926
      Simon Peyton Jones authored
      Trac #13135 showed that we were failing to apply the
      correct substitution to the un-substituted tyvars during
      type-family improvement using injectivity.  Specifically
      in TcInteractlinjImproveEqns we need to use instFlexiX.
      
      An outright bug, easy to fix.
      
      Slight refactoring along the way.  The quantified tyars of the axiom are
      readily to hand; we don't need to take the free tyvars of the LHS
      2b64e926
    • Simon Peyton Jones's avatar
      Improve pretty-printing of IfaceCoercions · 6850eb64
      Simon Peyton Jones authored
      For some reason, unless you have -fprint-explicit-coercions, when
      printing an explicit coercion we were then going to special trouble to
      suppress the unique of a hole (which only happens during debugging
      anyway).  This is bizarre.
      
      So I deleted three lines of code -- hooray.
      6850eb64
  2. 22 Jan, 2017 7 commits
  3. 21 Jan, 2017 1 commit
    • niteria's avatar
      Always use -Xlinker for -rpath · f9ccad23
      niteria authored
      Currently we use `-Wl` which takes a list of
      comma-separated options. Unfortunately that
      breaks when you use it with `-rpath` and
      a path that has commas in them.
      Buck, the build system, produces paths with
      commas in them.
      
      `-Xlinker` doesn't have this disadvantage
      and as far as I can tell is supported by
      both `gcc` and `clang`. Anecdotally `nvcc`
      supports `-Xlinker`, but not `-Wl`.
      
      Test Plan: ./validate, harbourmaster
      
      Reviewers: nomeata, simonmar, austin, bgamari, hvr
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2971
      f9ccad23
  4. 20 Jan, 2017 12 commits
    • Yuras's avatar
      Warn on missing home modules · 15b9a85e
      Yuras authored
      Introduce a warning, -Wmissing-home-modules, to warn about home modules,
      not listed in command line.
      
      It is usefull for cabal when user fails to list a module in
      `exposed-modules` and `other-modules`.
      
      Test Plan: make TEST=MissingMod
      
      Reviewers: mpickering, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2977
      
      GHC Trac Issues: #13129
      15b9a85e
    • dobenour's avatar
      Clean up some shell code and M4 quoting · c43011da
      dobenour authored
      
      Test Plan: GHC CI
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D2993
      c43011da
    • rwbarton's avatar
      testsuite: Don't fail if "target has RTS linker" field is missing · b626a001
      rwbarton authored
      Test Plan: harbormaster
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2991
      b626a001
    • rwbarton's avatar
      Add a failing test for #13099 · b4761317
      rwbarton authored
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2990
      
      GHC Trac Issues: #13099
      b4761317
    • Phil de Joux's avatar
      Show explicit quantifiers in conflicting definitions error · 33140f41
      Phil de Joux authored
      This fixes #12441, where definitions in a Haskell module and its boot
      file which differed only in their quantifiers produced a confusing error
      message. Here we teach GHC to always show quantifiers for these errors.
      
      Reviewers: goldfire, simonmar, erikd, austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: snowleopard, simonpj, mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2734
      
      GHC Trac Issues: #12441
      33140f41
    • takano-akio's avatar
      Allow top-level string literals in Core (#8472) · d49b2bb2
      takano-akio authored
      This commits relaxes the invariants of the Core syntax so that a
      top-level variable can be bound to a primitive string literal of type
      Addr#.
      
      This commit:
      
      * Relaxes the invatiants of the Core, and allows top-level bindings whose
        type is Addr# as long as their RHS is either a primitive string literal or
        another variable.
      
      * Allows the simplifier and the full-laziness transformer to float out
        primitive string literals to the top leve.
      
      * Introduces the new StgGenTopBinding type to accomodate top-level Addr#
        bindings.
      
      * Introduces a new type of labels in the object code, with the suffix "_bytes",
        for exported top-level Addr# bindings.
      
      * Makes some built-in rules more robust. This was necessary to keep them
        functional after the above changes.
      
      This is a continuation of D2554.
      
      Rebasing notes:
      This had two slightly suspicious performance regressions:
      
      * T12425: bytes allocated regressed by roughly 5%
      * T4029: bytes allocated regressed by a bit over 1%
      * T13035: bytes allocated regressed by a bit over 5%
      
      These deserve additional investigation.
      
      Rebased by: bgamari.
      
      Test Plan: ./validate --slow
      
      Reviewers: goldfire, trofi, simonmar, simonpj, austin, hvr, bgamari
      
      Reviewed By: trofi, simonpj, bgamari
      
      Subscribers: trofi, simonpj, gridaphobe, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2605
      
      GHC Trac Issues: #8472
      d49b2bb2
    • Ben Gamari's avatar
      Bump Cabal submodule · a2a67b77
      Ben Gamari authored
      a2a67b77
    • Oleg Grenrus's avatar
      Add 'type family (m :: Symbol) <> (n :: Symbol)' · 7026edc3
      Oleg Grenrus authored
      Reviewers: dfeuer, austin, bgamari, hvr
      
      Subscribers: dfeuer, mpickering, RyanGlScott, ekmett, yav, lelf,
      simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2632
      
      GHC Trac Issues: #12162
      7026edc3
    • rwbarton's avatar
    • Simon Peyton Jones's avatar
      Test Trac #11444 · b8f1b018
      Simon Peyton Jones authored
      b8f1b018
    • Simon Peyton Jones's avatar
      Simplify and improve CSE · b78fa759
      Simon Peyton Jones authored
      Trac #13156 showed a lost opportunity for CSE. I found that it was
      easy to fix, and it had the nice side effect of rendering a previous
      nasty case, described in Note [Corner case for case expressions],
      unnecessary.
      
      Simpler code, does more.  Great.
      b78fa759
    • Simon Peyton Jones's avatar
      Fix a nasty bug in exprIsExpandable · 9be18ea4
      Simon Peyton Jones authored
      This bug has been lurking for ages: Trac #13155
      
      The important semantic change is to ensure that exprIsExpandable
      returns False for primop calls.  Previously exprIsExpandable used
      exprIsCheap' which always used primOpIsCheap.
      
      I took the opportunity to combine the code for exprIsCheap' (two
      variants: exprIsCheap and exprIsExpandable) with that for
      exprIsWorkFree.  Result is simpler, tighter, easier to understand.
      And correct (at least wrt this bug)!
      9be18ea4
  5. 19 Jan, 2017 4 commits
    • David Feuer's avatar
      Add explicit foldMap implementation for Maybe · bf1e1f32
      David Feuer authored
      Eric Mertens pointed out that using the default `foldMap`
      implementation for `Maybe` led to an efficiency problem by
      implementing `foldMap f (Just x)` as `f x <> mempty` rather than
      as `f x`. This should solve the problem.
      
      Reviewers: hvr, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: glguy, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2988
      bf1e1f32
    • dobenour's avatar
      Don't error on missing Perl, just warn and disable object splitting. · f07a6c17
      dobenour authored
      Summary:
      If Perl isn't needed, we don't need to error out.  Since all Perl is
      used for is the splitter, we can just warn.
      
      Test Plan: GHC CI
      
      Reviewers: bgamari, hvr, austin
      
      Reviewed By: bgamari
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D2986
      
      GHC Trac Issues: #13141
      f07a6c17
    • Ryan Scott's avatar
      Fix the GHC 7.10 build · f5bea982
      Ryan Scott authored
      Following e7985ed2. HasDebugCallStack now
      appears in IdInfo, which requires `FlexibleContexts` to be enabled when built
      with GHC 7.10.
      f5bea982
    • 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
  6. 18 Jan, 2017 8 commits
  7. 17 Jan, 2017 3 commits