1. 02 Apr, 2018 2 commits
    • Simon Peyton Jones's avatar
      Allow unpacking of single-data-con GADTs · 9187d5fb
      Simon Peyton Jones authored
      Trac #14978 pointed out that single-constructor GADTs should be
      unpackable without trouble.
      Acutally I realise that even existentials should be unpackable
      too, but that's a bit more work, so it's not part of this patch.
      See Note [Unpacking GADTs and existentials] in MkId.
    • Richard Eisenberg's avatar
      Test #14884, #14969 · 07abff71
      Richard Eisenberg authored
      These were fixed by faec8d35
      test cases: typecheck/should_fail/T14884
  2. 01 Apr, 2018 4 commits
    • Richard Eisenberg's avatar
      Clarify comments around dropping Derived constraints · 1845d1bc
      Richard Eisenberg authored
      [skip ci]
    • Richard Eisenberg's avatar
    • Richard Eisenberg's avatar
      Apply the interim fix for #14119 to liftCoMatch · ef443820
      Richard Eisenberg authored
      Matching in the presence of casts can happen in liftCoMatch, too.
    • Richard Eisenberg's avatar
      Track type variable scope more carefully. · faec8d35
      Richard Eisenberg authored
      The main job of this commit is to track more accurately the scope
      of tyvars introduced by user-written foralls. For example, it would
      be to have something like this:
        forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool
      In that type, a's kind must be k, but k isn't in scope. We had a
      terrible way of doing this before (not worth repeating or describing
      here, but see the old tcImplicitTKBndrs and friends), but now
      we have a principled approach: make an Implication when kind-checking
      a forall. Doing so then hooks into the existing machinery for
      preventing skolem-escape, performing floating, etc. This also means
      that we bump the TcLevel whenever going into a forall.
      The new behavior is done in TcHsType.scopeTyVars, but see also
      TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant
      rewriting. There are several Notes near there to guide you. Of
      particular interest there is that Implication constraints can now
      have skolems that are out of order; this situation is reported in
      A major consequence of this is a slightly tweaked process for type-
      checking type declarations. The new Note [Use SigTvs in kind-checking
      pass] in TcTyClsDecls lays it out.
      The error message for dependent/should_fail/TypeSkolEscape has become
      noticeably worse. However, this is because the code in TcErrors goes to
      some length to preserve pre-8.0 error messages for kind errors. It's time
      to rip off that plaster and get rid of much of the kind-error-specific
      error messages. I tried this, and doing so led to a lovely error message
      for TypeSkolEscape. So: I'm accepting the error message quality regression
      for now, but will open up a new ticket to fix it, along with a larger
      error-message improvement I've been pondering. This applies also to
      dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142.
      Other minor changes:
       - isUnliftedTypeKind didn't look for tuples and sums. It does now.
       - check_type used check_arg_type on both sides of an AppTy. But the left
         side of an AppTy isn't an arg, and this was causing a bad error message.
         I've changed it to use check_type on the left-hand side.
       - Some refactoring around when we print (TYPE blah) in error messages.
         The changes decrease the times when we do so, to good effect.
         Of course, this is still all controlled by
      Fixes #14066 #14749
      Test cases: dependent/should_compile/{T14066a,T14749},
  3. 31 Mar, 2018 3 commits
  4. 30 Mar, 2018 1 commit
  5. 29 Mar, 2018 5 commits
  6. 27 Mar, 2018 11 commits
  7. 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.
      T3064, T5321FD, T5321Fun, T9872a, T9872b, T9872c all pass.
      T9872a and T9872c show improvements beyond the -5% threshold.
      T9872d fails at 10.9% increased allocations.
    • 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.
    • 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.
    • Ö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
    • Douglas Wilson's avatar
      rts, base: Refactor stats.c to improve --machine-readable report · f0b258bc
      Douglas Wilson 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
      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
    • Ben Gamari's avatar
      circleci: Bump Hackage index state · 60e29dc2
      Ben Gamari authored
    • Mark Karpov's avatar
      Add a job running on Fedora · d152dab9
      Mark Karpov authored
    • 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
    • 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
    • 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
    • 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
  8. 25 Mar, 2018 3 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
    • 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
    • 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