1. 22 Jan, 2017 4 commits
  2. 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
  3. 20 Jan, 2017 9 commits
    • Yuras's avatar
      Warn on missing home modules · 15b9a85e
      Yuras authored and Ben Gamari's avatar Ben Gamari committed
      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
    • rwbarton's avatar
      testsuite: Don't fail if "target has RTS linker" field is missing · b626a001
      rwbarton authored and Ben Gamari's avatar Ben Gamari committed
      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 and Ben Gamari's avatar Ben Gamari committed
      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 and Ben Gamari's avatar Ben Gamari committed
      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 and Ben Gamari's avatar Ben Gamari committed
      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
    • Oleg Grenrus's avatar
      Add 'type family (m :: Symbol) <> (n :: Symbol)' · 7026edc3
      Oleg Grenrus authored and Ben Gamari's avatar Ben Gamari committed
      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
    • 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
  4. 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
  5. 18 Jan, 2017 5 commits
  6. 17 Jan, 2017 4 commits
    • Rufflewind's avatar
      Unquote ‘import’ in bad import error message · e195add1
      Rufflewind authored and Ben Gamari's avatar Ben Gamari committed
          In module ‘Prelude’:
            ‘True’ is a data constructor of ‘Bool’
          To import it use
            ‘import’ Prelude( Bool( True ) )
      
      The quotes around `import` don't make any sense.
      
      Test Plan: manual
      
      Reviewers: austin, mpickering, bgamari
      
      Reviewed By: mpickering, bgamari
      
      Subscribers: dfeuer, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2935
      e195add1
    • Ben Gamari's avatar
      testsuite: Bump allocations for T12234 · 19cc0071
      Ben Gamari authored
      Unfortunately it's not clear why but this has been failing on Harbormaster.
      19cc0071
    • Ben Gamari's avatar
      testsuite/recomp001: Sleep to ensure that GHC notices file change · 769e3ee7
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      Some operating systems (e.g. Darwin) have very poor file timestamp
      resolution.  On these systems GHC often fails to notice that B.hs
      changes in this testsuite, leading to sporatic test failures. Add a
      sleep to ensure the change is noticed.
      
      Test Plan: Validate
      
      Reviewers: ezyang, austin
      
      Subscribers: mpickering, gracjan, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2964
      769e3ee7
    • Alan Zimmerman's avatar
      Fix API Annotations for unboxed sums · 38f289fa
      Alan Zimmerman authored
      An unboxed tuple such as
      
          (# | b | | | | | #)
      
      Ends up in the parser via `tup_exprs` as
      
          Sum 2 7 lexp
      
      where `lexp` is a `LHsExpr`
      
      From an API annotation perspective, the 5 `AnnVbar`s after the `b` were attached
      to `lexp`, but the leading `AnnVbar`s did not have a home.
      
      This patch attaches them all to the the parent tuple expression. The first (alt
      - 1) of them come before `lexp`, and the remaining (arity - alt) come after.
      
      Test Plan: ./validate
      
      Reviewers: osa1, austin, bgamari
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2968
      
      GHC Trac Issues: #12417
      38f289fa
  7. 16 Jan, 2017 1 commit
    • Tamar Christina's avatar
      Add missing test files for T13082. · 4bfe3d4d
      Tamar Christina authored
      Summary:
      Add two missing test files for T13082.
      The reason they were missing is because the .gitignore
      contains a very harmful and broad wildcard `foo*`. Why?
      
      Test Plan: make test TEST="T13082_good T13082_fail"
      
      Reviewers: austin, bgamari, simonmar, erikd
      
      Reviewed By: erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2981
      
      GHC Trac Issues: #13082
      4bfe3d4d
  8. 15 Jan, 2017 4 commits
    • Alan Zimmerman's avatar
      Add dump-parsed-ast flag and functionality · 1ff3c588
      Alan Zimmerman authored
      Summary:
      This flag causes a dump of the ParsedSource as an AST in textual form, similar
      to the ghc-dump-tree on hackage.
      
      Test Plan: ./validate
      
      Reviewers: mpickering, bgamari, austin
      
      Reviewed By: mpickering
      
      Subscribers: nominolo, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2958
      
      GHC Trac Issues: #11140
      1ff3c588
    • Ryan Scott's avatar
      Improve access violation reporting on Windows · c13151e5
      Ryan Scott authored
      Summary:
      This patch is courtesy of @awson.
      
      Currently, whenever GHC catches a segfault on Windows, it simply reports the
      somewhat uninformative message
      `Segmentation fault/access violation in generated code`. This patch adds to
      the message the type of violation (read/write/dep) and location information,
      which should help debugging segfaults in the future.
      
      Fixes #13108.
      
      Test Plan: Build on Windows
      
      Reviewers: austin, erikd, bgamari, simonmar, Phyx
      
      Reviewed By: bgamari, Phyx
      
      Subscribers: awson, thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2969
      
      GHC Trac Issues: #13108
      c13151e5
    • Tamar Christina's avatar
      Fix abort and import lib search on Windows · 331f88d0
      Tamar Christina authored
      Summary:
      Apparently `sysErrorBelch` doesn't terminate the program anymore making
      previously unreachable code now execute. If a dll is not found the error
      message we return needs to be a heap value.
      
      Secondly also allow the pattern `lib<name>` to be allowed for finding an
      import library with the name `lib<name>.dll.a`.
      
      Test Plan: ./validate, new tests T13082_good and T13082_fail
      
      Reviewers: austin, RyanGlScott, hvr, erikd, simonmar, bgamari
      
      Reviewed By: RyanGlScott, bgamari
      
      Subscribers: thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2941
      
      GHC Trac Issues: #13082
      331f88d0
    • Tamar Christina's avatar
      Use latin1 code page on Windows for response files. · f63c8ef3
      Tamar Christina authored
      Summary:
      D2917 added a change that will make paths on Windows response files
      use DOS 8.3 shortnames to get around the fact that `libiberty` assumes
      a one byte per character encoding.
      
      This is actually not the problem, the actual problem is that GCC on
      Windows doesn't seem to support Unicode at all.
      
      This comes down to how unicode characters are handled between POSIX and
      Windows. On Windows, Unicode is only supported using a multibyte character
      encoding such as `wchar_t` with calls to the appropriate wide version of
      APIs (name post-fixed with the `W` character). On Posix I believe the standard
      `char` is used and based on the value it is decoded to the correct string.
      
      GCC doesn't seem to make calls to the Wide version of the Windows APIs,
      and even if it did, it's character representation would be wrong. So I
      believe GCC just does not support utf-8 paths on Windows.
      
      So the hack in D2917 is the only way to get Unicode support. The problem is
      however that `GCC` is not the only tool with this issue and we don't use response
      files for every invocation of the tools. Most of the tools probably don't support it.
      
      Furthermore, DOS 8.1 shortnames only exist when the path or file physically exists on
      disk. We pass lots of paths to GCC that don't exist yet, like the output file.
      D2917 works around this by splitting the path from the file and try shortening that.
      
      But this may not always work.
      
      In short, even if we do Unicode correctly (which we don't atm, the GCC driver we build
      uses `char` instead of `wchar_t`) we won't be able to compile using unicode paths that
      need to be passed to `GCC`. So not sure about the point of D2917.
      
      What we can do is support the most common non-ascii characters by writing the response
      files out using the `latin1` code page.
      
      Test Plan: compile + make test TEST=T12971
      
      Reviewers: austin, bgamari, erikd
      
      Reviewed By: bgamari
      
      Subscribers: thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2942
      
      GHC Trac Issues: #12971
      f63c8ef3
  9. 13 Jan, 2017 2 commits
  10. 12 Jan, 2017 2 commits
    • Simon Peyton Jones's avatar
      Fix top-level constraint handling (Trac #12921) · f5f6d423
      Simon Peyton Jones authored
      Some out-of-scope errors were not being reported if anyone
      throws an un-caught exception in the TcM monad.  That led to
      
        ghc: panic! (the 'impossible' happened)
      	initTc: unsolved constraints
      
      I fixed this
      
      * Splitting captureConstraints to use an auxilliary
        tryCaptureConstraints (which never fails)
      
      * Define a new TcSimplify.captureTopConstraints (replacing
        the old TcRnMonad.captureTopConstraints), which reports
        any unsolved out-of-scope constraints before propagating
        the exception
      
      That in turn allowed me to do some tidying up of the static-constraint
      machinery, reducing duplication.
      
      Also solves #13106.
      f5f6d423
    • Gabor Greif's avatar
      Typos in manual, comments and tests · c6b04865
      Gabor Greif authored
      c6b04865
  11. 11 Jan, 2017 6 commits
    • Edward Z. Yang's avatar
      Fix handling of closed type families in Backpack. · f59aad68
      Edward Z. Yang authored
      
      
      Summary:
      A few related problems:
      
      - CoAxioms, like DFuns, are implicit and never exported,
        so we have to make sure we treat them the same way as
        DFuns: in RnModIface we need to rename references to
        them with rnIfaceImplicit and in mergeSignatures we need
        to NOT check them directly for compatibility (the
        test on the type family will do this check for us.)
      
      - But actually, we weren't checking if the axioms WERE
        consistent.  This is because we were forwarding all
        embedded CoAxiom references in the type family TyThing
        to the merged version, but that reference was what
        checkBootDeclM was using as a comparison point.
        This is similar to a problem we saw with DFuns.
      
        To fix this, I refactored the handling of implicit entities in TcIface
        for Backpack.  See Note [The implicit TypeEnv] for the gory details.
        Instead of passing the TypeEnv around explicitly, we stuffed it in
        IfLclEnv.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: bgamari, simonpj, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2928
      f59aad68
    • Edward Z. Yang's avatar
      Revamp Backpack/hs-boot handling of type class signatures. · 5def07fa
      Edward Z. Yang authored
      
      
      Summary:
      A basket of fixes and improvements:
      
      - The permissible things that one can write in a type
        class definition in an hsig file has been reduced
        to encompass the following things:
      
          - Methods
          - Default method signatures (but NOT implementation)
          - MINIMAL pragma
      
        It is no longer necessary nor encouraged to specify
        that a method has a default if it is mentioned in
        a MINIMAL pragma; the MINIMAL pragma is assumed to
        provide the base truth as to what methods need to
        be implemented when writing instances of a type
        class.
      
      - Handling of default method signatures in hsig was
        previously buggy, as these identifiers were not exported,
        so we now treat them similarly to DFuns.
      
      - Default methods are merged, where methods with defaults
        override those without.
      
      - MINIMAL pragmas are merged by ORing together pragmas.
      
      - Matching has been relaxed: a method with a default can
        be used to fill a signature which did not declare the
        method as having a default, and a more relaxed MINIMAL
        pragma can be used (we check if the signature pragma
        implies the final implementation pragma, on the way
        fixing a bug with BooleanFormula.implies, see #13073)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2925
      
      GHC Trac Issues: #13041
      5def07fa
    • Edward Z. Yang's avatar
      Improve Backpack support for fixities. · e41c61fa
      Edward Z. Yang authored
      
      
      Summary:
      Two major bug-fixes:
      
          - Check that fixities match between hsig and implementation
      
          - Merge and preserve fixities when merging signatures
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: bgamari, simonpj, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2919
      
      GHC Trac Issues: #13066
      e41c61fa
    • Edward Z. Yang's avatar
      Warn if you explicitly export an identifier with warning attached. · 0bbcf76a
      Edward Z. Yang authored
      
      
      Summary:
      This won't stop people from attempting to use this identifier
      (since it is still always going to be in the export list), but
      having an explicit reference to something people shouldn't
      use is a smell, so warn about it.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2907
      0bbcf76a
    • Edward Z. Yang's avatar
      Attach warnings to non-PVP compatible uses of signatures. · 9f169bcd
      Edward Z. Yang authored
      
      
      Summary:
      If you use an inherited signature from another package in your own code,
      the only valid PVP bound you can specify for this package is an *exact*
      version bound.  This is because the signature is used both covariantly
      (it provides declarations for import) and contravariantly (it specifies
      what is required).  However, this is a bit distressing if you want to
      use a PVP-style bound that allows for upgrading a package.  So there is
      a dichotomy:
      
          1. Any signatures that come from packages with exact bounds
          (this includes, in particular, signature packages, who are
          included solely to make declarations available), can be
          used without problem by modules, but
      
          2. Any signatures that come from packages that are version
          bounded (i.e., any package that also provides modules) must
          NOT be used, because if they were used, they could break
          under a PVP policy that allows relaxations in the needed
          requirements.
      
      To help users avoid situation (2), I've added a warning to all
      signature declarations that come solely from (2).  This is not
      perfect; you might still end up relying on some type identity
      specified by a signature in a version-bounded package, but it
      should help catch major errors.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2906
      9f169bcd
    • Edward Z. Yang's avatar
      Support for using only partial pieces of included signatures. · 5f9c6d2a
      Edward Z. Yang authored
      
      
      Summary:
      Generally speaking, it's not possible to "hide" a requirement from a
      package you include, because if there is some module relying on that
      requirement, well, you can't just wish it out of existence.
      
      However, some packages don't have any modules.  For these, we can
      validly thin out requirements; indeed, this is very convenient if
      someone has published a large signature package but you only want
      some of the definitions.
      
      This patchset tweaks the interpretation of export lists in
      signatures: in particular, they no longer need to refer to
      entities that are defined locally; they range over both the current
      signature as well as any signatures that were inherited from
      signature packages (defined by having zero exposed modules.)
      
      In the process of doing this, I cleaned up a number of other
      things:
      
      * rnModIface and rnModExports now report errors that occurred
        during renaming and can propagate these to the TcM monad.
        This is important because in the current semantics, you can
        thin out a type which is referenced by a value you keep;
        in this situation, we need to error (to ensure that all
        types in signatures are rooted, so that we can determine
        their identities).
      
      * I ended up introducing a new construct 'dependency signature;
        to bkp files, to make it easier to tell if we were depending
        on a signature package.  It's not difficult for Cabal to
        figure this out (I already have a patch for it.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2904
      
      GHC Trac Issues: #12994
      5f9c6d2a
  12. 10 Jan, 2017 1 commit
    • David Feuer's avatar
      Inline partially-applied wrappers · 2be364ac
      David Feuer authored and David Feuer's avatar David Feuer committed
      Suppose we have
      
      ```
      data Node a = Node2 !Int a a | Node3 !Int a a a
      instance Traversable Node where
        traverse f (Node2 s x y) = Node2 s <$> f x <*> f y
        ...
      
      ```
      
      Since `Node2` is partially applied, we wouldn't inline its
      wrapper.  The result was that we'd box up the `Int#` to put
      the box in the closure passed to `fmap`. We now allow the wrapper
      to inline when partially applied, so GHC stores the `Int#`
      directly in the closure.
      
      Reviewers: rwbarton, mpickering, simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2891
      
      GHC Trac Issues: #12990
      2be364ac