1. 25 Aug, 2017 7 commits
    • Ben Gamari's avatar
      Add strict variant of iterate · a67b66e6
      Ben Gamari authored
      Summary: This closes the nearly-eight-year-old #3474.
      Test Plan: Validate
      Reviewers: RyanGlScott, austin, hvr
      Subscribers: rwbarton, thomie
      GHC Trac Issues: #3474
      Differential Revision: https://phabricator.haskell.org/D3870
    • Simon Peyton Jones's avatar
    • Simon Peyton Jones's avatar
      Don't do the RhsCtxt thing for join points · 8649535c
      Simon Peyton Jones authored
      This minor change fixes Trac #14137.
      It is described in Note [Join point RHSs] in OccurAnal
    • Simon Peyton Jones's avatar
      Refactor the Mighty Simplifier · 33452dfc
      Simon Peyton Jones authored
      Triggered by #12150, and the knock-on effects of join points, I did a
      major refactoring of the Simplifier.  This is a big patch that change
      a lot of Simplify.hs: I did a lot of other re-organisation.
      The main event
      Since the dawn of time we have had
        simplExpr :: SimplEnv -> InExpr -> SimplCont
                  -> SimplM (SimplEnv, OutExpr)
      What's that SimplEnv in the result?  When simplifying an expression the
      simplifier add floated let-bindings to the SimplEnv, extending the
      in-scope set appropriately, and hence needs to resturn the SimplEnv at
      the end.  The mode, flags, substitution in the returned SimplEnv were
      all irrelevant: it was just the floating bindings.
      It's strange to accumulate part of the /result/ in the /environment/
      argument!  And indeed its leads to all manner of mysterious calls to
      zapFloats and transferring of floats from one SimplEnv to another.
      It got worse with join points, so I finally bit the bullet and refactored.
      Now we have
        simplExpr :: SimplEnv -> InExpr -> SimplCont
                  -> SimplM (SimplFloats, OutExpr)
        -- See Note [The big picture]
      and the SimplEnv no longer has floats in it.  The code is no shorter,
      but it /is/ easier to understand.
      Main changes
      * Remove seLetFloats field from SimplEnv
      * Define new data type SimplFloats, and functions over it
      * Change the types of simplExpr, simplBind, and their many variants,
        to follow the above plan
      Bottoming bindings
      I made one other significant change in SimplUtils (not just refactoring),
      related to Trac #12150 comment:16.  Given
        x = <rhs>
      where <rhs> turns out to be a bottoming expression, propagate that
      information to x's IdInfo immediately.  That's always good, because
      it makes x be inlined less (we don't inline bottoming things), and
      it allows (case x of ...) to drop the dead alterantives immediately.
      Moreover, we are doing the analysis anyway, in tryEtaExpandRhs, which
      calls CoreArity.findRhsArity, which already does simple bottom analysis.
      So we are generating the information; all we need do is to atach the
      bottoming info to the IdInfo.
      See Note [Bottoming bindings]
      Smaller refactoring
      * Rename SimplifierMode to SimplMode
      * Put DynFlags as a new field in SimplMode, to make fewer
        monadic calls to getDynFlags.
      * Move the code in addPolyBind into abstractFloats
      * Move the "don't eta-expand join points" into tryEtaExpandRhs
    • Simon Peyton Jones's avatar
      Bottoming expressions should not be expandable · 407c11b8
      Simon Peyton Jones authored
      This patch changes isExpandableApp and isWorkFreeApp to respond
      False to bottoming applications.  I found that if we had
        x = undefined <dict-expr>
      then prepareRhs was ANF'ing it to
        d = <dict-expr>
        x = undefined d
      which is stupid (no gain); and worse it made the simplifier iterate
      indefinitely.  It showed up when I started marking 'x' as a bottoming
      Id more aggresssively than before; but it's been a lurking bug for
      It was convenient to make isWorkFreeApp also return False for
      bottoming applications, and I see no reason not to do so.
      That leaves isCheapApp.  It currently replies True to bottoming
      applications, but I don't see why that's good..  Something to try
    • Simon Peyton Jones's avatar
      Restrict exprOkForSpeculation/case to unlifted types · a0b7b100
      Simon Peyton Jones authored
        case x of y
          DEFAULT -> let v::Int# = case y of
                                     True  -> e1
                                     False -> e2
                      in ...
      Previously this would have been ok-for-speculation because
      y is evaluated.  But the binder-swap done
      by SetLevels would transform the inner alternative to
           DEFAULT -> let v::Int# = case x of { ... }
                      in ...)
      which does /not/ satisfy the let/app invariant, because x is
      not evaluated.
      I don't know why this has never bitten us before, but it began
      to bite when I did upcoming refactoring of the Simplifier.
      So this patch narrows exprOkForSpeculation to only work for
      /unlifted/ cases.
      To make this work I had to make exprOkForSpeculation non-polymorphic
      in the binder type, which has a little knock-on for is use in
      (It's annoying that we need to handle cases at all, but see
       Note [exprOkForSpeculation: case expressions])
    • Ben Gamari's avatar
      CNF: Implement compaction for small pointer arrays · 5f3d2d3b
      Ben Gamari authored
      Test Plan: Validate
      Reviewers: austin, erikd, simonmar, dfeuer
      Reviewed By: dfeuer
      Subscribers: rwbarton, andrewthad, thomie, dfeuer
      GHC Trac Issues: #13860, #13857
      Differential Revision: https://phabricator.haskell.org/D3888
  2. 24 Aug, 2017 4 commits
  3. 22 Aug, 2017 15 commits
    • Ben Gamari's avatar
    • Ben Gamari's avatar
      Add support for producing position-independent executables · 3625728a
      Ben Gamari authored
      Previously due to #12759 we disabled PIE support entirely. However, this
      breaks the user's ability to produce PIEs. Add an explicit flag, -fPIE,
      allowing the user to build PIEs.
      Test Plan: Validate
      Reviewers: rwbarton, austin, simonmar
      Subscribers: trommler, simonmar, trofi, jrtc27, thomie
      GHC Trac Issues: #12759, #13702
      Differential Revision: https://phabricator.haskell.org/D3589
    • Ben Gamari's avatar
      DynFlags: Add inverse of -dno-debug-output · dbaa9a23
      Ben Gamari authored
      Reviewers: austin
      Subscribers: rwbarton, thomie
      GHC Trac Issues: #14142
      Differential Revision: https://phabricator.haskell.org/D3876
    • Benjamin Hodgson's avatar
      Fixed a typo in template-haskell documentation · 028645ce
      Benjamin Hodgson authored
      The documentation for `Type`'s `ForallT` constructor had a typo (pun not
      intended). `ctxt` is separated from `type` in the surface syntax by a fat
      arrow (`=>`), not a thin arrow (`->`).
    • Chris Martin's avatar
      fix typo (expreesions -> expressions) · 090d8960
      Chris Martin authored
    • Ben Gamari's avatar
      Bump haddock submodule · 20c7053d
      Ben Gamari authored
    • AlainODea's avatar
      Make law for Foldable.length explicit · cd5a9709
      AlainODea authored
      Test Plan: Documentation only. Not necessary.
      Reviewers: austin, hvr, bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3878
    • Ben Gamari's avatar
      StgLint: Allow join point bindings of unlifted type · 9afaebef
      Ben Gamari authored
      As described in `Note [CoreSyn let/app invariant]` this is allowed.
      Fixes #14117.
      Test Plan: Build GHC with BuildFlavour=devel2 with -dstg-lint
      Reviewers: austin, simonpj
      Reviewed By: simonpj
      Subscribers: rwbarton, thomie
      GHC Trac Issues: #14117
      Differential Revision: https://phabricator.haskell.org/D3857
    • Edward Z. Yang's avatar
      Fix incorrect retypecheck loop in -j (#14075) · 4717ce86
      Edward Z. Yang authored
      The parallel codepath was incorrectly retypechecking the
      hs-boot ModIface prior to typechecking the hs file,
      which was inconsistent with the non-parallel case.  The
      non-parallel case gets it right: you don't want to retypecheck
      the hs-boot file itself (forwarding its declarations to hs)
      because you need it to be consistently knot-tied with itself
      when you compare the interfaces.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      Test Plan: validate
      Reviewers: bgamari, simonpj, austin
      Reviewed By: bgamari
      Subscribers: duog, rwbarton, thomie
      GHC Trac Issues: #14075
      Differential Revision: https://phabricator.haskell.org/D3815
    • Douglas Wilson's avatar
      Move validate cleaning from distclean to clean · afc2f798
      Douglas Wilson authored
      This bit me today: I was in validate mode without realising it and "make
      clean" didn't help. I don't see a reason for this to be in distclean, as
      it isn't generated by ./configure, which is the rule described in
      Test Plan: Is there a reason for this to be in distclean?
      Reviewers: austin, bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3814
    • Ryan Scott's avatar
      Make the Read instance for Proxy (and friends) ignore precedence · 8fd95999
      Ryan Scott authored
      The `Read` instance for `Proxy`, as well as a handful of other data
      types in `base` which only have a single constructor, are doing something
      skeevy: they're requiring that they be surrounded by parentheses if the parsing
      precedence is sufficiently high. This means that `"Thing (Proxy)"` would parse,
      but not `"Thing Proxy"`. But the latter really ought to parse, since there's no
      need to surround a single constructor with parentheses. Indeed, that's the
      output of `show (Thing Proxy)`, so the current `Read` instance for `Proxy`
      violates `read . show = id`.
      The simple solution is to change `readParen (d > 10)` to `readParen False` in
      the `Read` instance for `Proxy`. But given that a derived `Read` instance would
      essentially accomplish the same thing, but with even fewer characters, I've
      opted to just replace the hand-rolled `Read` instance with a derived one.
      Test Plan: make test TEST=T12874
      Reviewers: ekmett, austin, hvr, goldfire, bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie
      GHC Trac Issues: #12874
      Differential Revision: https://phabricator.haskell.org/D3871
    • Ryan Scott's avatar
      Revise function arity mismatch errors involving TypeApplications · 84760976
      Ryan Scott authored
      Currently, whenever you apply a function to too many arguments and
      some of those arguments happen to be visible type applications, the error
      message that GHC gives is rather confusing. Consider the message you receive
      when typechecking `id @Int 1 2`:
      The function `id` is applied to three arguments,
      but its type `Int -> Int` has only one
      This is baffling, since the two lines treat the visible type argument `@Int`
      differently. The top line ("applied to three arguments") includes `@Int`,
      whereas the bottom line ("has only one") excludes `@Int` from consideration.
      There are multiple ways one could fix this, which I explain in an addendum to
      `Note [Herald for matchExpectedFunTys]`. The approach adopted here is to change
      the herald of this error message to include visible type arguments, and to
      avoid counting them in the "applied to n arguments" part of the error. The end
      result is that the new error message for `id @Int 1 2` is now:
      The expression `id @Int` is applied to two arguments,
      but its type `Int -> Int` has only one
      Test Plan: make test TEST=T13902
      Reviewers: goldfire, austin, bgamari
      Reviewed By: goldfire
      Subscribers: rwbarton, thomie
      GHC Trac Issues: #13902
      Differential Revision: https://phabricator.haskell.org/D3868
    • Ryan Scott's avatar
      Fix #13885 by freshening reified GADT constructors' universal tyvars · 79b259ae
      Ryan Scott authored
      When reifying GADTs with Template Haskell, the universally quantified
      type variables were being reused across both the data type head and the
      constructors' type signatures. This had the annoying effect of causing sets
      of differently scoped variables to have the same uniques. To avoid this, we
      now freshen the universal tyvars before reifying the constructors so as to
      ensure they have distinct uniques.
      Test Plan: make test TEST=T13885
      Reviewers: goldfire, austin, bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: rwbarton, thomie
      GHC Trac Issues: #13885
      Differential Revision: https://phabricator.haskell.org/D3867
    • Ryan Scott's avatar
      Fix #14114 by checking for duplicate vars on pattern synonym RHSes · a89bb806
      Ryan Scott authored
      Because we weren't checking for duplicate variables on the right-hand
      sides of pattern synonyms, bogus definitions like this one passed the renamer:
      pattern Foo a <- (a,a)
      Luckily, the fix is simple.
      Test Plan: make test TEST=T14114
      Reviewers: mpickering, austin, bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: simonpj, rwbarton, thomie
      GHC Trac Issues: #14114
      Differential Revision: https://phabricator.haskell.org/D3866
    • Ryan Scott's avatar
      Fix #14125 by normalizing data family instances more aggressively · 6982ee99
      Ryan Scott authored
      Commit 3540d1e1 inadvertently broke
      the ability for newtype instances to be used as marshallable types in FFI
      declarations. The reason is a bit silly: an extra check was added for type
      synonyms with no type families on the RHS in `normalise_tc_app`, but this check
      would only skip over type families, not //data// families, since the predicate
      being used was `not . isTypeFamilyCon`.
      The fix is simple: just use `not . isFamilyCon` instead so that data families
      are also skipped by this check.
      Test Plan: make test TEST=T14125
      Reviewers: goldfire, simonpj, austin, bgamari
      Reviewed By: simonpj
      Subscribers: rwbarton, thomie
      GHC Trac Issues: #14125
      Differential Revision: https://phabricator.haskell.org/D3865
  4. 21 Aug, 2017 1 commit
  5. 19 Aug, 2017 6 commits
    • Ben Gamari's avatar
      Revert "Add strict variant of iterate" · 1cdceb9f
      Ben Gamari authored
      This was not ready to commit.
      This reverts commit 8e5b6ec6.
    • Tamar Christina's avatar
      Correct incorrect free in PE linker · ee2e9ece
      Tamar Christina authored
      The big-obj support (D3523) had introduced an early free on
      the info structure. Because the pointer is not NULL'd
      and the default of all the utility functions was to the
      standard object format, it all kept working.
      The one big-obj test that exists was subjected to a timing issue.
      usually the test ran quickly enough that the allocator hasn't
      had time to reclaim the memory yet, so it still passed.
      This corrects it. Also as it so happens, static LLVM libraries
      from mingw-w64 are compiled using big-obj.
      Test Plan: ./validate
      Reviewers: austin, bgamari, erikd, simonmar
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie
      GHC Trac Issues: #13815, #13093
      Differential Revision: https://phabricator.haskell.org/D3862
    • Ben Gamari's avatar
      Add strict variant of iterate · 8e5b6ec6
      Ben Gamari authored
      This closes the nearly-eight-year-old #3474.
    • patrickdoc's avatar
      users_guide: Convert mkUserGuidePart generation to a Sphinx extension · cf8ab1ce
      patrickdoc authored
      This removes all dependencies the users guide had on `mkUserGuidePart`.
      The generation of the flag reference table and the various pieces of the
      man page is now entirely contained within the Spinx extension
      `flags.py`. You can see the man page generation on the orphan page
      The extension works by collecting all of the meta-data attached to the
      `ghc-flag` directives and then formatting and displaying it at
      `flag-print` directives. There is a single printing directive that can
      be customized with two options, what format to display (table, list, or
      block of flags) and an optional category to limit the output to
      (verbosity, warnings, codegen, etc.).
      New display formats can be added by creating a function
      `generate_flag_xxx` (where `xxx` is a description of the format) which
      takes a list of flags and a category and returns a new `xxx`. Then just
      add a reference in the dispatch table `handlers`. That display can now
      be run by passing `:type: xxx` to the `flag-print` directive.
      `flags.py` contains two maps of settings that can be adjusted. The first
      is a canonical list of flag categories, and the second sets default
      categories for files.
      The only functionality that Sphinx could not replace was the
      `what_glasgow_exts_does.gen.rst` file. `mkUserGuidePart` actually just
      reads the list of flags from `compiler/main/DynFlags.hs` which Sphinx
      cannot do. As the flag is deprecated, I added the list as a static file
      which can be updated manually.
      Additionally, this patch updates every single documented flag with the
      data from `mkUserGuidePart` to generate the reference table.
      Fixes #11654 and, incidentally, #12155.
      Reviewers: austin, bgamari
      Subscribers: rwbarton, thomie
      GHC Trac Issues: #11654, #12155
      Differential Revision: https://phabricator.haskell.org/D3839
    • Ben Gamari's avatar
      Enable -Wcpp-undef for GHC and runtime system · 6267d8c9
      Ben Gamari authored
      This gets us much of the benefit of enabling it globally, which avoiding
      (at least for now) the pain of making the core libraries build as well.
      See #13636.
      Test Plan: Validate
      Reviewers: erikd, austin
      Subscribers: rwbarton, thomie
      GHC Trac Issues: #13636
      Differential Revision: https://phabricator.haskell.org/D3517
    • quchen's avatar
      Doctests for Data.Tuple · f50e30e0
      quchen authored
  6. 18 Aug, 2017 6 commits
  7. 17 Aug, 2017 1 commit