1. 09 Jul, 2019 1 commit
    • Ryan Scott's avatar
      Use an empty data type in TTG extension constructors (#15247) · 6a03d77b
      Ryan Scott authored
      To avoid having to `panic` any time a TTG extension constructor is
      consumed, this MR introduces an uninhabited 'NoExtCon' type and uses
      that in every extension constructor's type family instance where it
      is appropriate. This also introduces a 'noExtCon' function which
      eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates
      a 'Void'.
      I also renamed the existing `NoExt` type to `NoExtField` to better
      distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of
      code churn resulting from this.
      Bumps the Haddock submodule. Fixes #15247.
  2. 08 Jul, 2019 2 commits
  3. 05 Jul, 2019 10 commits
    • Alex D's avatar
    • Ryan Scott's avatar
      More sensible SrcSpans for recursive pattern synonym errors (#16900) · 62b82135
      Ryan Scott authored
      Attach the `SrcSpan` of the first pattern synonym binding involved in
      the recursive group when throwing the corresponding error message,
      similarly to how it is done for type synonyms.
      Fixes #16900.
    • Artem Pelenitsyn's avatar
      Make all submodules have absolute URLs · a76b233d
      Artem Pelenitsyn authored
      The relative URLs were a workaround to let most contributors fork from
      Github due to a weakness in the haskell.org server.
      This workaround is no longer needed. And relative submodule URLs are
      an impediment to forking which makes contributions harder than they
      should be.
      The URLs are chosen to clone from https, because this makes sure that
      anybody, even not a registered Gitlab user, can clone a fork
    • Andreas Klebinger's avatar
      Dont gather ticks when only striping them in STG. · f002250a
      Andreas Klebinger authored
      Adds stripStgTicksTopE which only returns the stripped expression.
      So far we also allocated a list for the stripped ticks which was
      never used.
      Allocation difference is as expected very small but present.
      About 0.02% difference when compiling with -O.
    • Simon Peyton Jones's avatar
      Fix over-eager implication constraint discard · 80afdf6b
      Simon Peyton Jones authored
      Ticket #16247 showed that we were discarding an implication
      constraint that had empty ic_wanted, when we still needed to
      keep it so we could check whether it had a bad telescope.
      Happily it's a one line fix.  All the rest is comments!
    • Daniel Gröber (dxld)'s avatar
      rts: Fix -hT option with profiling rts · ed662901
      Daniel Gröber (dxld) authored
      In dumpCensus we switch/case on doHeapProfile twice. The second switch
      tries to barf on unknown doHeapProfile modes but HEAP_BY_CLOSURE_TYPE is
      checked by the first switch and not included in the second.
      So when trying to pass -hT to the profiling rts it barfs.
      This commit simply merges the two switches into one which fixes this
    • Simon Peyton Jones's avatar
      Add a missing zonk (fixes #16902) · 53aa59f3
      Simon Peyton Jones authored
      In the eager unifier, when unifying (tv1 ~ tv2),
      when we decide to swap them over, to unify (tv2 ~ tv1),
      I'd forgotten to ensure that tv1's kind was fully zonked,
      which is an invariant of uUnfilledTyVar2.
      That could lead us to build an infinite kind, or (in the
      case of #16902) update the same unification variable twice.
      Now we get an error message rather than non-termination,
      which is much better.  The error message is not great,
      but it's a very strange program, and I can't see an easy way
      to improve it, so for now I'm just committing this fix.
      Here's the decl
       data F (a :: k) :: (a ~~ k) => Type where
          MkF :: F a
      and the rather error message of which I am not proud
        T16902.hs:11:10: error:
          • Expected a type, but found something with kind ‘a1’
          • In the type ‘F a’
    • Vladislav Zavialov's avatar
      Produce all DerivInfo in tcTyAndClassDecls · 679427f8
      Vladislav Zavialov authored
      Before this refactoring:
      * DerivInfo for data family instances was returned from tcTyAndClassDecls
      * DerivInfo for data declarations was generated with mkDerivInfos and added at a
        later stage of the pipeline in tcInstDeclsDeriv
      After this refactoring:
      * DerivInfo for both data family instances and data declarations is returned from
        tcTyAndClassDecls in a single list.
      This uniform treatment results in a more convenient arrangement to fix #16731.
    • Ben Gamari's avatar
      gitlab: Reduce size of template headings · 675d27fc
      Ben Gamari authored
    • Siddharth Bhat's avatar
      Make printer untag when chasing a pointer in a RET_FUN frame · d7f7e1ed
      Siddharth Bhat authored
      This is to mimic what `Scav.c` does. This should fix a crash in
      the printer.
  4. 04 Jul, 2019 1 commit
  5. 03 Jul, 2019 3 commits
  6. 02 Jul, 2019 9 commits
  7. 28 Jun, 2019 4 commits
    • Ben Gamari's avatar
      rts: Assert that LDV profiling isn't used with parallel GC · bd660ede
      Ben Gamari authored
      I'm not entirely sure we are careful about ensuring this; this is a
      last-ditch check.
    • Travis Whitaker's avatar
      Correct closure observation, construction, and mutation on weak memory machines. · 11bac115
      Travis Whitaker authored
      Here the following changes are introduced:
          - A read barrier machine op is added to Cmm.
          - The order in which a closure's fields are read and written is changed.
          - Memory barriers are added to RTS code to ensure correctness on
            out-or-order machines with weak memory ordering.
      Cmm has a new CallishMachOp called MO_ReadBarrier. On weak memory machines, this
      is lowered to an instruction that ensures memory reads that occur after said
      instruction in program order are not performed before reads coming before said
      instruction in program order. On machines with strong memory ordering properties
      (e.g. X86, SPARC in TSO mode) no such instruction is necessary, so
      MO_ReadBarrier is simply erased. However, such an instruction is necessary on
      weakly ordered machines, e.g. ARM and PowerPC.
      Weam memory ordering has consequences for how closures are observed and mutated.
      For example, consider a closure that needs to be updated to an indirection. In
      order for the indirection to be safe for concurrent observers to enter, said
      observers must read the indirection's info table before they read the
      indirectee. Furthermore, the entering observer makes assumptions about the
      closure based on its info table contents, e.g. an INFO_TYPE of IND imples the
      closure has an indirectee pointer that is safe to follow.
      When a closure is updated with an indirection, both its info table and its
      indirectee must be written. With weak memory ordering, these two writes can be
      arbitrarily reordered, and perhaps even interleaved with other threads' reads
      and writes (in the absence of memory barrier instructions). Consider this
      example of a bad reordering:
      - An updater writes to a closure's info table (INFO_TYPE is now IND).
      - A concurrent observer branches upon reading the closure's INFO_TYPE as IND.
      - A concurrent observer reads the closure's indirectee and enters it. (!!!)
      - An updater writes the closure's indirectee.
      Here the update to the indirectee comes too late and the concurrent observer has
      jumped off into the abyss. Speculative execution can also cause us issues,
      - An observer is about to case on a value in closure's info table.
      - The observer speculatively reads one or more of closure's fields.
      - An updater writes to closure's info table.
      - The observer takes a branch based on the new info table value, but with the
        old closure fields!
      - The updater writes to the closure's other fields, but its too late.
      Because of these effects, reads and writes to a closure's info table must be
      ordered carefully with respect to reads and writes to the closure's other
      fields, and memory barriers must be placed to ensure that reads and writes occur
      in program order. Specifically, updates to a closure must follow the following
      - Update the closure's (non-info table) fields.
      - Write barrier.
      - Update the closure's info table.
      Observing a closure's fields must follow the following pattern:
      - Read the closure's info pointer.
      - Read barrier.
      - Read the closure's (non-info table) fields.
      This patch updates RTS code to obey this pattern. This should fix long-standing
      SMP bugs on ARM (specifically newer aarch64 microarchitectures supporting
      out-of-order execution) and PowerPC. This fixes issue #15449.
      Co-Authored-By: Ben Gamari's avatarBen Gamari <ben@well-typed.com>
    • Artem Pelenitsyn's avatar
      typo in the docs for DynFlags.hs · ef6d9a50
      Artem Pelenitsyn authored
    • Sylvain Henry's avatar
  8. 27 Jun, 2019 9 commits
  9. 26 Jun, 2019 1 commit