1. 29 Mar, 2018 4 commits
  2. 27 Mar, 2018 11 commits
  3. 26 Mar, 2018 11 commits
    • alexvieth's avatar
      Fix performance of flattener patch (#12919) · b47a6c3a
      alexvieth authored
      This patch, authored by alexvieth and reviewed at D4451,
      makes performance improvements by critically optimizing parts
      of the flattener.
      
      Summary:
      T3064, T5321FD, T5321Fun, T9872a, T9872b, T9872c all pass.
      T9872a and T9872c show improvements beyond the -5% threshold.
      T9872d fails at 10.9% increased allocations.
      b47a6c3a
    • Richard Eisenberg's avatar
      Fix #12919 by making the flattener homegeneous. · e3dbb44f
      Richard Eisenberg authored
      This changes a key invariant of the flattener. Previously,
      flattening a type meant flattening its kind as well. But now,
      flattening is always homogeneous -- that is, the kind of the
      flattened type is the same as the kind of the input type.
      This is achieved by various wizardry in the TcFlatten.flatten_many
      function, as described in Note [flatten_many].
      
      There are several knock-on effects, including some refactoring
      in the canonicalizer to take proper advantage of the flattener's
      changed behavior. In particular, the tyvar case of can_eq_nc' no
      longer needs to take casts into account.
      
      Another effect is that flattening a tyconapp might change it
      into a casted tyconapp. This might happen if the result kind
      of the tycon contains a variable, and that variable changes
      during flattening. Because the flattener is homogeneous, it tacks
      on a cast to keep the tyconapp kind the same. However, this
      is problematic when flattening CFunEqCans, which need to have
      an uncasted tyconapp on the LHS and must remain homogeneous.
      The solution is a more involved canCFunEqCan, described in
      Note [canCFunEqCan].
      
      This patch fixes #13643 (as tested in typecheck/should_compile/T13643)
      and the panic in typecheck/should_compile/T13822 (as reported in #14024).
      Actually, there were two bugs in T13822: the first was just some
      incorrect logic in tryFill (part of the unflattener) -- also fixed
      in this patch -- and the other was the main bug fixed in this ticket.
      
      The changes in this patch exposed a long-standing flaw in OptCoercion,
      in that breaking apart an AppCo sometimes has unexpected effects on
      kinds. See new Note [EtaAppCo] in OptCoercion, which explains the
      problem and fix.
      
      Also here is a reversion of the major change in
      09bf135a, affecting ctEvCoercion.
      It turns out that making the flattener homogeneous changes the
      invariants on the algorithm, making the change in that patch
      no longer necessary.
      
      This patch also fixes:
        #14038 (dependent/should_compile/T14038)
        #13910 (dependent/should_compile/T13910)
        #13938 (dependent/should_compile/T13938)
        #14441 (typecheck/should_compile/T14441)
        #14556 (dependent/should_compile/T14556)
        #14720 (dependent/should_compile/T14720)
        #14749 (typecheck/should_compile/T14749)
      
      Sadly, this patch negatively affects performance of type-family-
      heavy code. The following patch fixes these performance degradations.
      However, the performance fixes are somewhat invasive and so I've
      kept them as a separate patch, labeling this one as [skip ci] so
      that validation doesn't fail on the performance cases.
      e3dbb44f
    • Richard Eisenberg's avatar
      Fix compilation stopper on macOS with -Werror · 97e1f300
      Richard Eisenberg authored
      Commit 94f02547
      added some pragmas that allow GCC to compile GHC, but stop
      macOS's clang. This adds another counter-pragma to halp
      clang lumber along, too.
      
      Fixes #14977.
      97e1f300
    • Ömer Sinan Ağacan's avatar
      Make it evident in types that StgLam can't have empty args · 41c15587
      Ömer Sinan Ağacan authored
      StgLam can't have empty arguments. Reflect this in types. An assertion
      can now be deleted.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4484
      41c15587
    • duog's avatar
      rts, base: Refactor stats.c to improve --machine-readable report · f0b258bc
      duog authored
      There should be no change in the output of the '+RTS -s' (summary)
      report, or
      the 'RTS -t' (one-line) report.
      
      All data shown in the summary report is now shown in the machine
      readable
      report.
      
      All data in RTSStats is now shown in the machine readable report.
      
      init times are added to RTSStats and added to GHC.Stats.
      
      Example of the new output:
      ```
       [("bytes allocated", "375016384")
       ,("num_GCs", "113")
       ,("average_bytes_used", "148348")
       ,("max_bytes_used", "206552")
       ,("num_byte_usage_samples", "2")
       ,("peak_megabytes_allocated", "6")
       ,("init_cpu_seconds", "0.001642")
       ,("init_wall_seconds", "0.001027")
       ,("mut_cpu_seconds", "3.020166")
       ,("mut_wall_seconds", "0.757244")
       ,("GC_cpu_seconds", "0.037750")
       ,("GC_wall_seconds", "0.009569")
       ,("exit_cpu_seconds", "0.000890")
       ,("exit_wall_seconds", "0.002551")
       ,("total_cpu_seconds", "3.060452")
       ,("total_wall_seconds", "0.770395")
       ,("major_gcs", "2")
       ,("allocated_bytes", "375016384")
       ,("max_live_bytes", "206552")
       ,("max_large_objects_bytes", "159344")
       ,("max_compact_bytes", "0")
       ,("max_slop_bytes", "59688")
       ,("max_mem_in_use_bytes", "6291456")
       ,("cumulative_live_bytes", "296696")
       ,("copied_bytes", "541024")
       ,("par_copied_bytes", "493976")
       ,("cumulative_par_max_copied_bytes", "104104")
       ,("cumulative_par_balanced_copied_bytes", "274456")
       ,("fragmentation_bytes", "2112")
       ,("alloc_rate", "124170795")
       ,("productivity_cpu_percent", "0.986838")
       ,("productivity_wall_percent", "0.982935")
       ,("bound_task_count", "1")
       ,("sparks_count", "5836258")
       ,("sparks_converted", "237")
       ,("sparks_overflowed", "1990408")
       ,("sparks_dud ", "0")
       ,("sparks_gcd", "3455553")
       ,("sparks_fizzled", "390060")
       ,("work_balance", "0.555606")
       ,("n_capabilities", "4")
       ,("task_count", "10")
       ,("peak_worker_count", "9")
       ,("worker_count", "9")
       ,("gc_alloc_block_sync_spin", "162")
       ,("gc_alloc_block_sync_yield", "0")
       ,("gc_alloc_block_sync_spin", "162")
       ,("gc_spin_spin", "18840855")
       ,("gc_spin_yield", "10355")
       ,("mut_spin_spin", "70331392")
       ,("mut_spin_yield", "61700")
       ,("waitForGcThreads_spin", "241")
       ,("waitForGcThreads_yield", "2797")
       ,("whitehole_gc_spin", "0")
       ,("whitehole_lockClosure_spin", "0")
       ,("whitehole_lockClosure_yield", "0")
       ,("whitehole_executeMessage_spin", "0")
       ,("whitehole_threadPaused_spin", "0")
       ,("any_work", "1667")
       ,("no_work", "1662")
       ,("scav_find_work", "1026")
       ,("gen_0_collections", "111")
       ,("gen_0_par_collections", "111")
       ,("gen_0_cpu_seconds", "0.036126")
       ,("gen_0_wall_seconds", "0.036126")
       ,("gen_0_max_pause_seconds", "0.036126")
       ,("gen_0_avg_pause_seconds", "0.000081")
       ,("gen_0_sync_spin", "21")
       ,("gen_0_sync_yield", "0")
       ,("gen_1_collections", "2")
       ,("gen_1_par_collections", "1")
       ,("gen_1_cpu_seconds", "0.001624")
       ,("gen_1_wall_seconds", "0.001624")
       ,("gen_1_max_pause_seconds", "0.001624")
       ,("gen_1_avg_pause_seconds", "0.000272")
       ,("gen_1_sync_spin", "3")
       ,("gen_1_sync_yield", "0")
       ]
      ```
      
      Test Plan: Ensure that one-line and summary reports are unchanged.
      
      Reviewers: erikd, simonmar, hvr
      
      Subscribers: duog, carter, thomie, rwbarton
      
      GHC Trac Issues: #14660
      
      Differential Revision: https://phabricator.haskell.org/D4529
      f0b258bc
    • Ben Gamari's avatar
      circleci: Bump Hackage index state · 60e29dc2
      Ben Gamari authored
      60e29dc2
    • Mark Karpov's avatar
      Add a job running on Fedora · d152dab9
      Mark Karpov authored
      d152dab9
    • Reiner Pope's avatar
      Add unaligned bytearray access primops. Fixes #4442. · efd70cfb
      Reiner Pope authored
      Reviewers: bgamari, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: dfeuer, rwbarton, thomie, carter
      
      GHC Trac Issues: #4442
      
      Differential Revision: https://phabricator.haskell.org/D4488
      efd70cfb
    • Ben Gamari's avatar
      Add new debugging flag -dinline-check · ecfb4d36
      Ben Gamari authored
      This flag reports a summary of the inlining decision for identifiers
      prefixed by the flag's argument.
      
      For example, `-dinline-check foo` will report why definitions whose
      prefix is `foo` are inlined or not.
      
      Previously the only way to get this information was to pass a
      combination of `-dverbose-core2core` and `-ddump-inlinings`.
      
      This combination led to a log of 12 million lines in a module of about
      200 lines I recently had to apply it to. This flag provides a much more
      direct way to find the occurence you care about.
      
      Reviewers: osa1, dfeuer, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4458
      ecfb4d36
    • Ben Gamari's avatar
      base: Fix Unicode handling of TyCon's Show instance · 20ae19fc
      Ben Gamari authored
      Test Plan: `make test TEST=T14925`
      
      Reviewers: hvr, dfeuer
      
      Reviewed By: dfeuer
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14925
      
      Differential Revision: https://phabricator.haskell.org/D4530
      20ae19fc
    • Oleg Grenrus's avatar
      llvmGen: Pass -optlo flags last to opt · 41db237e
      Oleg Grenrus authored
      LLVM, like GHC, processes flags in the order that they appear.
      Consequently, we need to ensure the user-provided flags appear last so
      they can override flags produced by GHC. See #14821.
      
      Test Plan: `ghc -O2 -optlo-O2 -v3 $FILE` and ensure that `opt` and `llc`
      are invoked with `-O2`.
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14821
      
      Differential Revision: https://phabricator.haskell.org/D4421
      41db237e
  4. 25 Mar, 2018 13 commits
    • Tao He's avatar
      Fix scoped type variables in TH for several constructs · a3986d7f
      Tao He authored
      Namely class methods, default signatures and pattern synonyms.
      
      When scoped type variables occur inside class default methods,
      default signatures and pattern synonyms, avoid re-create explicit
      type variables when represent the type signatures.
      
      This patch should fix Trac#14885.
      Signed-off-by: Tao He's avatarHE, Tao <sighingnow@gmail.com>
      
      Test Plan: make test TEST="T14885a T14885b T14885c"
      
      Reviewers: goldfire, bgamari, simonpj, RyanGlScott
      
      Reviewed By: simonpj, RyanGlScott
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14885
      
      Differential Revision: https://phabricator.haskell.org/D4469
      a3986d7f
    • niteria's avatar
      Don't refer to blocks in debug info when -g1 · 0cbb13b3
      niteria authored
      -g1 removes block information, but it turns out that procs can
      refer to block information through parents.
      Note [Splitting DebugBlocks] explains the parentage relationship.
      
      Test Plan:
      * ./validate
      * added a new test
      
      Reviewers: bgamari, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14894
      
      Differential Revision: https://phabricator.haskell.org/D4496
      0cbb13b3
    • Ryan Scott's avatar
      Fix #14916 with an additional validity check in deriveTyData · 20f14b4f
      Ryan Scott authored
      Manually-written instances and standalone-derived instances
      have the benefit of having the `checkValidInstHead` function run over
      them, which catches manual instances of built-in types like `(~)` and
      `Coercible`. However, instances generated from `deriving` clauses
      weren't being passed through `checkValidInstHead`, leading to
      confusing results as in #14916.
      
      `checkValidInstHead` also has additional validity checks for language
      extensions like `FlexibleInstances` and `MultiParamTypeClasses`. Up
      until now, GHC has never required these language extensions for
      `deriving` clause, so to avoid unnecessary breakage, I opted to
      suppress these language extension checks for `deriving` clauses, just
      like we currently suppress them for `SPECIALIZE instance` pragmas.
      
      Test Plan: make test TEST=T14916
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14916
      
      Differential Revision: https://phabricator.haskell.org/D4501
      20f14b4f
    • Ben Gamari's avatar
      testsuite: Add test for #14925 · 0703c00f
      Ben Gamari authored
      Test Plan: Validate
      
      Reviewers: alpmestan
      
      Reviewed By: alpmestan
      
      Subscribers: alpmestan, leftaroundabout, rwbarton, thomie, carter
      
      GHC Trac Issues: #14925
      
      Differential Revision: https://phabricator.haskell.org/D4512
      0703c00f
    • Ryan Scott's avatar
      rts/RetainerProfile: Dump closure type if push() fails · 9a00bfba
      Ryan Scott authored
      While investigating #14947, I noticed that the `barf`ed
      error message in `push()` doesn't print out the closure type that
      causes it to crash. Let's do so.
      
      Reviewers: bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: alexbiehl, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4525
      9a00bfba
    • voanhduy1512's avatar
      document: fix trac issue #14229 · c16df606
      voanhduy1512 authored
      Accroding to
      https://git.haskell.org/ghc.git/commitdiff/49672659113371c3bee691e6d913d
      f8e6f60a1d8,
      `-Wredundant-constraints` is no longer turn on by default.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4528
      c16df606
    • Adam Gundry's avatar
      Fix panic on module re-exports of DuplicateRcordFields · fb462f94
      Adam Gundry authored
      Test Plan: new test overloadedrecflds/should_fail/T14953
      
      Reviewers: mpickering, simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14953
      
      Differential Revision: https://phabricator.haskell.org/D4527
      fb462f94
    • Simon Marlow's avatar
      Run C finalizers incrementally during mutation · f7bbc343
      Simon Marlow authored
      With a large heap it's possible to build up a lot of finalizers
      between GCs.  We've observed GC spending up to 50% of its time running
      finalizers.  But there's no reason we have to run finalizers during
      GC, and especially no reason we have to block *all* the mutator
      threads while *one* GC thread runs finalizers one by one.
      
      I thought about a bunch of alternative ways to handle this, which are
      documented along with runSomeFinalizers() in Weak.c.  The approach I
      settled on is to have a capability run finalizers if it is idle.  So
      running finalizers is like a low-priority background thread. This
      requires some minor scheduler changes, but not much.  In the future we
      might be able to move more GC work into here (I have my eye on freeing
      large blocks, for example).
      
      Test Plan:
      * validate
      * tested on our system and saw reductions in GC pauses of 40-50%.
      
      Reviewers: bgamari, niteria, osa1, erikd
      
      Reviewed By: bgamari, osa1
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4521
      f7bbc343
    • Simon Marlow's avatar
      Add Note [BLACKHOLE points to IND] · cf809950
      Simon Marlow authored
      Test Plan: ci
      
      Reviewers: osa1, bgamari, erikd
      
      Reviewed By: osa1
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4517
      cf809950
    • Ryan Scott's avatar
      Fix two pernicious bugs in DeriveAnyClass · 98930426
      Ryan Scott authored
      The way GHC was handling `DeriveAnyClass` was subtly wrong
      in two notable ways:
      
      * In `inferConstraintsDAC`, we were //always// bumping the `TcLevel`
        of newly created unification variables, under the assumption that
        we would always place those unification variables inside an
        implication constraint. But #14932 showed precisely the scenario
        where we had `DeriveAnyClass` //without// any of the generated
        constraints being used inside an implication, which made GHC
        incorrectly believe the unification variables were untouchable.
      * Even worse, we were using the generated unification variables from
        `inferConstraintsDAC` in every single iteration of `simplifyDeriv`.
        In #14933, however, we have a scenario where we fill in a
        unification variable with a skolem in one iteration, discard it,
        proceed on to another iteration, use the same unification variable
        (still filled in with the old skolem), and try to unify it with
        a //new// skolem! This results in an utter disaster.
      
      The root of both these problems is `inferConstraintsDAC`. This patch
      fixes the issue by no longer generating unification variables
      directly in `inferConstraintsDAC`. Instead, we store the original
      variables from a generic default type signature in `to_metas`, a new
      field of `ThetaOrigin`, and in each iteration of `simplifyDeriv`, we
      generate fresh meta tyvars (avoiding the second issue). Moreover,
      this allows us to more carefully fine-tune the `TcLevel` under which
      we create these meta tyvars, fixing the first issue.
      
      Test Plan: make test TEST="T14932 T14933"
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14932, #14933
      
      Differential Revision: https://phabricator.haskell.org/D4507
      98930426
    • John Ericson's avatar
      Support iOS variants elsewhere when configuring · 10566a81
      John Ericson authored
      Reviewers: hvr, bgamari, angerman
      
      Reviewed By: angerman
      
      Subscribers: rwbarton, thomie, erikd, carter, angerman
      
      Differential Revision: https://phabricator.haskell.org/D4513
      10566a81
    • Ben Gamari's avatar
      testsuite: Add test for #14931 · 7bb1fde1
      Ben Gamari authored
      Reviewers: alpmestan
      
      Reviewed By: alpmestan
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14931
      
      Differential Revision: https://phabricator.haskell.org/D4518
      7bb1fde1
    • Alec Theriault's avatar
      Support adding objects from TH · ceb91477
      Alec Theriault authored
      The user facing TH interface changes are:
      
        * 'addForeignFile' is renamed to 'addForeignSource'
        * 'qAddForeignFile'/'addForeignFile' now expect 'FilePath's
        * 'RawObject' is now a constructor for 'ForeignSrcLang'
        * 'qAddTempFile'/'addTempFile' let you request a temporary file
          from the compiler.
      
      Test Plan: unsure about this, added a TH test
      
      Reviewers: goldfire, bgamari, angerman
      
      Reviewed By: bgamari, angerman
      
      Subscribers: hsyl20, mboes, carter, simonmar, bitonic, ljli, rwbarton, thomie
      
      GHC Trac Issues: #14298
      
      Differential Revision: https://phabricator.haskell.org/D4217
      ceb91477
  5. 23 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Allow PartialTypeSignatures in standalone deriving contexts · affdea82
      Ryan Scott authored
      Summary:
      At its core, this patch is a simple tweak that allows a user
      to write:
      
      ```lang=haskell
      deriving instance _ => Eq (Foo a)
      ```
      
      Which is functionally equivalent to:
      
      ```lang=haskell
      data Foo a = ...
        deriving Eq
      ```
      
      But with the added flexibility that `StandaloneDeriving` gives you
      (namely, the ability to use it anywhere, not just in the same module
      that `Foo` was declared in). This fixes #13324, and should hopefully
      address a use case brought up in #10607.
      
      Currently, only the use of a single, extra-constraints wildcard is
      permitted in a standalone deriving declaration. Any other wildcard
      is rejected, so things like
      `deriving instance (Eq a, _) => Eq (Foo a)` are currently forbidden.
      
      There are quite a few knock-on changes brought on by this change:
      
      * The `HsSyn` type used to represent standalone-derived instances
        was previously `LHsSigType`, which isn't sufficient to hold
        wildcard types. This needed to be changed to `LHsSigWcType` as a
        result.
      
      * Previously, `DerivContext` was a simple type synonym for
        `Maybe ThetaType`, under the assumption that you'd only ever be in
        the `Nothing` case if you were in a `deriving` clause. After this
        patch, that assumption no longer holds true, as you can also be
        in this situation with standalone deriving when an
        extra-constraints wildcard is used.
      
        As a result, I changed `DerivContext` to be a proper datatype that
        reflects the new wrinkle that this patch adds, and plumbed this
        through the relevant parts of `TcDeriv` and friends.
      
      * Relatedly, the error-reporting machinery in `TcErrors` also assumed
        that if you have any unsolved constraints in a derived instance,
        then you should be able to fix it by switching over to standalone
        deriving. This was always sound advice before, but with this new
        feature, it's possible to have unsolved constraints even when
        you're standalone-deriving something!
      
        To rectify this, I tweaked some constructors of `CtOrigin` a bit
        to reflect this new subtlety.
      
      This requires updating the Haddock submodule. See my fork at
      https://github.com/RyanGlScott/haddock/commit/067d52fd4be15a1842cbb05f42d9d482de0ad3a7
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #13324
      
      Differential Revision: https://phabricator.haskell.org/D4383
      affdea82