1. 01 Sep, 2016 1 commit
  2. 22 Aug, 2016 2 commits
    • Ryan Scott's avatar
      Move #12403, #12513 users guide notes to 8.2.1 release notes · acdbd16f
      Ryan Scott authored
      The changes in #12403 and #12513 subtly changed the behavior of Template
      Haskell reification and splicing. While the old behavior was certainly buggy,
      it's possible that there's code in the wild that depended on the old behavior
      to work. To err on the side of caution, I'll postpone these changes to GHC
      8.2.1 instead of having them merged into GHC 8.0.2.
    • Ryan Scott's avatar
      Splice singleton unboxed tuples correctly with Template Haskell · fb0d87f1
      Ryan Scott authored
      Previously, TH would implicitly remove the parentheses when splicing in
      singleton unboxed tuple types (e.g., turning `(# Int #)` into `Int`). Luckily,
      the fix is simply to delete some code.
      Fixes #12513.
      Test Plan: make test TEST=T12513
      Reviewers: hvr, bgamari, austin, goldfire
      Reviewed By: goldfire
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2462
      GHC Trac Issues: #12513
  3. 18 Jul, 2016 1 commit
  4. 16 Jul, 2016 1 commit
    • tvv's avatar
      CodeGen: Way to dump cmm only once (#11717) · 1ba79fa4
      tvv authored and Ben Gamari's avatar Ben Gamari committed
      The `-ddump-cmm` put all stages of Cmm processing into one output.
      This patch changes its behavior and adds two more options to make
      Cmm dumping flexible.
      - `-ddump-cmm-from-stg` dumps only initial version of  Cmm right after
         STG->Cmm codegen
      - `-ddump-cmm` dumps the final result of the Cmm pipeline processing
      - `-ddump-cmm-verbose` dumps intermediate output of each Cmm pipeline
      - `-ddump-cmm-proc` and `-ddump-cmm-caf` seems were lost. Now enabled
      Test Plan: ./validate
      Reviewers: thomie, simonmar, austin, bgamari
      Reviewed By: thomie, simonmar
      Subscribers: simonpj, thomie
      Differential Revision: https://phabricator.haskell.org/D2393
      GHC Trac Issues: #11717
  5. 23 Jun, 2016 1 commit
  6. 02 May, 2016 1 commit
    • Facundo Domínguez's avatar
      StaticPointers: Allow closed vars in the static form. · 36d29f7c
      Facundo Domínguez authored
      With this patch closed variables are allowed regardless of whether
      they are bound at the top level or not.
      The FloatOut pass is always performed. When optimizations are
      disabled, only expressions that go to the top level are floated.
      Thus, the applications of the StaticPtr data constructor are always
      The CoreTidy pass makes sure the floated applications appear in the
      symbol table of object files. It also collects the floated bindings
      and inserts them in the static pointer table.
      The renamer does not check anymore if free variables appearing in the
      static form are top-level. Instead, the typechecker looks at the
      tct_closed flag to decide if the free variables are closed.
      The linter checks that applications of StaticPtr only occur at the
      top of top-level bindings after the FloatOut pass.
      The field spInfoName of StaticPtrInfo has been removed. It used to
      contain the name of the top-level binding that contains the StaticPtr
      application. However, this information is no longer available when the
      StaticPtr is constructed, as the binding name is determined now by the
      FloatOut pass.
      Test Plan: ./validate
      Reviewers: goldfire, simonpj, austin, hvr, bgamari
      Reviewed By: simonpj
      Subscribers: thomie, mpickering, mboes
      Differential Revision: https://phabricator.haskell.org/D2104
      GHC Trac Issues: #11656