1. 12 Sep, 2017 2 commits
  2. 09 Sep, 2017 1 commit
  3. 08 Sep, 2017 1 commit
  4. 07 Sep, 2017 2 commits
  5. 06 Sep, 2017 1 commit
    • Moritz Angermann's avatar
      Clean up opt and llc · 22733532
      Moritz Angermann authored
      The LLVM backend shells out to LLVMs `opt` and `llc` tools. This clean
      up introduces a shared data structure to carry the arguments we pass to
      each tool so that corresponding flags are next to each other. It drops
      the hard coded data layouts in favor of using `-mtriple` and have LLVM
      infer them. Furthermore we add `clang` as a proper tool, so we don't
      rely on assuming that `clang` is called `clang` on the `PATH` when using
      `clang` as the assembler.  Finally this diff also changes the type of
      `optLevel` from `Int` to `Word`, as we do not have negative optimization
      levels.
      
      Reviewers: erikd, hvr, austin, rwbarton, bgamari, kavon
      
      Reviewed By: kavon
      
      Subscribers: michalt, Ericson2314, ryantrinkle, dfeuer, carter, simonpj,
      kavon, simonmar, thomie, erikd, snowleopard
      
      Differential Revision: https://phabricator.haskell.org/D3352
      22733532
  6. 05 Sep, 2017 5 commits
    • Ryan Scott's avatar
      Implicitly bind kind variables in type family instance RHSes when it's sensible · 0829821a
      Ryan Scott authored
      Summary:
      Before, there was a discrepancy in how GHC renamed type synonyms as
      opposed to type family instances. That is, GHC would accept definitions like
      this one:
      
      ```lang=haskell
      type T = (Nothing :: Maybe a)
      ```
      
      However, it would not accept a very similar type family instance:
      
      ```lang=haskell
      type family   T :: Maybe a
      type instance T = (Nothing :: Maybe a)
      ```
      
      The primary goal of this patch is to bring the renaming of type family
      instances up to par with that of type synonyms, causing the latter definition
      to be accepted, and fixing #14131.
      
      In particular, we now allow kind variables on the right-hand sides of type
      (and data) family instances to be //implicitly// bound by LHS type (or kind)
      patterns (as opposed to type variables, which must always be explicitly
      bound by LHS type patterns only). As a consequence, this allows programs
      reported in #7938 and #9574 to typecheck, whereas before they would
      have been rejected.
      
      Implementation-wise, there isn't much trickery involved in making this happen.
      We simply need to bind additional kind variables from the RHS of a type family
      in the right place (in particular, see `RnSource.rnFamInstEqn`, which has
      undergone a minor facelift).
      
      While doing this has the upside of fixing #14131, it also made it easier to
      trigger #13985, so I decided to fix that while I was in town. This was
      accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13985, #14131
      
      Differential Revision: https://phabricator.haskell.org/D3872
      0829821a
    • alekzcb's avatar
      base: Update acosh to handle -1::Complex · 6458b8dc
      alekzcb authored
      Summary: Fixes #8532
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #8532
      
      Differential Revision: https://phabricator.haskell.org/D3916
      6458b8dc
    • Ben Gamari's avatar
      SetLevels: Substitute in ticks in lvlMFE · cd857dd4
      Ben Gamari authored
      Previously SetLevels.lvlMFE would fail to substitute in ticks, unlike
      lvlExpr.  This lead to #13481. Fix this.
      
      Test Plan: `make test TEST=T12622 WAY=ghci`
      
      Reviewers: austin, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #13481
      
      Differential Revision: https://phabricator.haskell.org/D3920
      cd857dd4
    • Ryan Scott's avatar
      Fix egregious duplication of vars in RnTypes · b9ac9e05
      Ryan Scott authored
      `RnTypes` contains a fairly intricate algorithm to extract
      the kind and type variables of an HsType. This algorithm carefully
      maintains the separation between type variables and kind variables
      so that the difference between `-XPolyKinds` and `-XTypeInType` can
      be respected.
      
      But after doing all this, `rmDupsInRdrTyVars` stupidly just
      concatenated the lists of type and kind variables at the end. If a
      variable were used as both a type and a kind, the algorithm would
      produce *both*! This led to all kinds of problems, including #13988.
      
      This is mostly Richard Eisenberg's patch. The only original
      contribution I made was adapting call sites of `rnImplicitBndrs` to
      work with the new definition of `rmDupsInRdrTyVars`. That is,
      `rnImplicitBndrs` checks for variables that are illegally used in
      both type and kind positions without using `-XTypeInType`, but in
      order to check this, one cannot have filtered duplicate variables out
      before passing them to `rnImplicitBndrs`. To accommodate for this, I
      needed to concoct variations on the existing `extract-` functions in
      `RnTypes` which do not remove duplicates, and use those near
      `rnImplicitBndrs` call sites.
      
      test case: ghci/scripts/T13988
      
      Test Plan: make test TEST=T13988
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13988
      
      Differential Revision: https://phabricator.haskell.org/D3902
      b9ac9e05
    • Ben Gamari's avatar
      testsuite: Add test for #14129 · b996e12d
      Ben Gamari authored
      It's not impossible that this will also get caught by another test given
      a suitably configured compiler, but this is minimal enough that it seems
      worth including.
      
      Test Plan: Validate with `DYNAMIC_GHC_PROGRAMS=NO`
      
      Reviewers: austin
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14129
      
      Differential Revision: https://phabricator.haskell.org/D3924
      b996e12d
  7. 04 Sep, 2017 1 commit
  8. 02 Sep, 2017 2 commits
    • Ryan Scott's avatar
      Fix #14167 by using isGadtSyntaxTyCon in more places · 8e4229ab
      Ryan Scott authored
      Summary:
      Two places in GHC effectively attempt to //guess// whether a data type
      was declared using GADT syntax:
      
      1. When reifying a data type in Template Haskell
      2. When pretty-printing a data type (e.g., via `:info` in GHCi)
      
      But there's no need for heuristics here, since we have a 100% accurate way to
      determine whether a data type was declared using GADT syntax: the
      `isGadtSyntaxTyCon` function! By simply using that as the metric, we obtain
      far more accurate TH reification and pretty-printing results.
      
      This is technically a breaking change, since Template Haskell reification will
      now reify some data type constructors as `(Rec)GadtC` that it didn't before,
      and some data type constructors that were previously reified as `(Rec)GadtC`
      will no longer be reified as such. But it's a very understandable breaking
      change, since the previous behavior was simply incorrect.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14167
      
      Differential Revision: https://phabricator.haskell.org/D3901
      8e4229ab
    • Ryan Scott's avatar
      Disallow bang/lazy patterns in the RHSes of implicitly bidirectional patsyns · 5dd6b13c
      Ryan Scott authored
      Summary:
      GHC was allowing implicitly bidirectional pattern synonyms with bang
      patterns and irrefutable patterns in the RHS, like so:
      
      ```lang=haskell
      pattern StrictJust a = Just !a
      ```
      
      This has multiple problems:
      
      1. `Just !a` isn't a valid expression, so it feels strange to allow it in an
         implicitly bidirectional pattern synonym.
      2. `StrictJust` doesn't provide the strictness properties one would expect
         from a strict constructor. (One could imagine a design where the
         `StrictJust` builder infers a bang pattern for its pattern variable, but
         accomplishing this inference in a way that accounts for all possible
         patterns on the RHS, including other pattern synonyms, is somewhat
         awkward, so we do not pursue this design.)
      
      We nip these issues in the bud by simply disallowing bang/irrefutable patterns
      on the RHS.
      
      Test Plan: make test TEST="T14112 unidir"
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14112
      
      Differential Revision: https://phabricator.haskell.org/D3896
      5dd6b13c
  9. 01 Sep, 2017 1 commit
  10. 31 Aug, 2017 1 commit
    • Simon Peyton Jones's avatar
      Really fix Trac #14158 · 2c133b67
      Simon Peyton Jones authored
      I dug more into how #14158 started working. I temporarily reverted the
      patch that "fixed" it, namely
      
          commit a6c448b4
          Author: Simon Peyton Jones <simonpj@microsoft.com>
          Date:   Mon Aug 28 17:33:59 2017 +0100
      
          Small refactor of getRuntimeRep
      
      Sure enough, there was a real bug, described in the new
      TcExpr Note [Visible type application zonk]
      
      In general, syntactic substituion should be kind-preserving!
      Maybe we should check that invariant...
      2c133b67
  11. 29 Aug, 2017 5 commits
    • Ryan Scott's avatar
      Refactor type family instance abstract syntax declarations · 895a7650
      Ryan Scott authored
      This implements @simonpj's suggested refactoring of the abstract syntax
      for type/data family instances (from
      https://ghc.haskell.org/trac/ghc/ticket/14131#comment:9). This combines
      the previously separate `TyFamEqn` and `DataFamInstDecl` types into a
      single `FamEqn` datatype. This also factors the `HsImplicitBndrs` out of
      `HsTyPats` in favor of putting them just outside of `FamEqn` (as opposed
      to before, where all of the implicit binders were embedded inside of
      `TyFamEqn`/`DataFamInstDecl`). Finally, along the way I noticed that
      `dfid_fvs` and `tfid_fvs` were completely unused, so I removed them.
      
      Aside from some changes in parser test output, there is no change in
      behavior.
      
      Requires a Haddock submodule commit from my fork (at
      https://github.com/RyanGlScott/haddock/commit/815d2deb9c0222c916becccf84
      64b740c26255fd)
      
      Test Plan: ./validate
      
      Reviewers: simonpj, austin, goldfire, bgamari, alanz
      
      Reviewed By: bgamari
      
      Subscribers: mpickering, goldfire, rwbarton, thomie, simonpj
      
      GHC Trac Issues: #14131
      
      Differential Revision: https://phabricator.haskell.org/D3881
      895a7650
    • Ben Gamari's avatar
      testsuite: Add test for #14128 · 248ad303
      Ben Gamari authored
      Reviewers: austin, goldfire
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14128
      
      Differential Revision: https://phabricator.haskell.org/D3890
      248ad303
    • Simon Peyton Jones's avatar
      Use a well-kinded substitution to instantiate · 4455c86d
      Simon Peyton Jones authored
      In tcDataConPat we were creating an ill-kinded substitution
      -- or at least one that is well kinded only after you have solved
      other equalities.  THat led to a crash, because the instantiated
      data con type was ill-kinded.
      
      This patch guarantees that the instantiating substitution is
      well-kinded.
      
      Fixed Trac #14154
      4455c86d
    • Simon Peyton Jones's avatar
      Refactor bindHsQTyVars and friends · 0257dacf
      Simon Peyton Jones authored
      This work was triggered by Trac #13738, which revealed to me that
      the code RnTypes.bindHsQTyVars and bindLHsTyVarBndrs was a huge
      tangled mess -- and outright wrong on occasion as the ticket showed.
      
      The big problem was that bindLHsTyVarBndrs (which is invoked at every
      HsForAll, including nested higher rank ones) was attempting to bind
      implicit kind variables, which it has absolutely no busineess doing.
      Imlicit kind quantification is done at the outside only, in fact
      precisely where we have HsImplicitBndrs or LHsQTyVars (which also
      has implicit binders).
      
      Achieving this move was surprisingly hard, because more and more
      barnacles had accreted aroud the original mistake.  It's much
      much better now.
      
      Summary of changes.  Almost all the action is in RnTypes.
      
      * Implicit kind variables are bound only by
        - By bindHsQTyVars, which deals with LHsQTyVars
        - By rnImplicitBndrs, which deals with HsImplicitBndrs
      
      * bindLHsTyVarBndrs, and bindLHsTyVarBndr are radically simplified.
        They simply does far less, and have lots their forest of
        incomprehensible accumulating parameters.  (To be fair, some of
        the code in bindLHsTyVarBndrs just moved to bindHsQTyVars, but
        in much more perspicuous form.)
      
      * The code that checks if a variable appears in both a kind and
        a type (triggering RnTypes.mixedVarsErr) was bizarre.  E.g.
        we had this in RnTypes.extract_hs_tv_bndrs
             ; check_for_mixed_vars bndr_kvs acc_tvs
             ; check_for_mixed_vars bndr_kvs body_tvs
             ; check_for_mixed_vars body_tvs acc_kvs
             ; check_for_mixed_vars body_kvs acc_tvs
             ; check_for_mixed_vars locals body_kvs
        I cleaned all this up; now we check for mixed use at binding
        sites only.
      
      * Checks for "Variable used as a kind before being bound", like
           data T (a :: k) k = rhs
        now just show up straightforwardly as "k is not in scope".
        See Note [Kind variable ordering]
      
      * There are some knock-on simplifications in RnSource.
      0257dacf
    • David Feuer's avatar
      Make parsed AST dump output lazily · 29da01e0
      David Feuer authored
      Previously, `showAstData` produced a `String`. That `String` would
      then be converted to a `Doc` using `text` to implement
      `-ddump-parsed-ast`. But rendering `text` calculates the length
      of the `String` before doing anything else. Since the AST can be
      very large, this was bad: the whole dump string (potentially hundreds
      of millions of `Char`s) was accumulated in memory.
      
      Now, `showAstData` produces a `Doc` directly, which seems to work
      a lot better. As an extra bonus, the code is simpler and cleaner.
      The formatting has changed a bit, as the previous ad hoc approach
      didn't really match the pretty printer too well. If someone cares
      enough to request adjustments, we can surely make them.
      
      Reviewers: austin, bgamari, mpickering, alanz
      
      Reviewed By: bgamari
      
      Subscribers: mpickering, rwbarton, thomie
      
      GHC Trac Issues: #14161
      
      Differential Revision: https://phabricator.haskell.org/D3894
      29da01e0
  12. 28 Aug, 2017 2 commits
  13. 25 Aug, 2017 2 commits
    • 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
      8649535c
    • 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
      33452dfc
  14. 24 Aug, 2017 1 commit
  15. 22 Aug, 2017 7 commits
    • 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
      3625728a
    • Ben Gamari's avatar
      Bump haddock submodule · 20c7053d
      Ben Gamari authored
      20c7053d
    • 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
      4717ce86
    • Ryan Scott's avatar
      Revise function arity mismatch errors involving TypeApplications · 84760976
      Ryan Scott authored
      Summary:
      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
      84760976
    • Ryan Scott's avatar
      Fix #13885 by freshening reified GADT constructors' universal tyvars · 79b259ae
      Ryan Scott authored
      Summary:
      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
      79b259ae
    • Ryan Scott's avatar
      Fix #14114 by checking for duplicate vars on pattern synonym RHSes · a89bb806
      Ryan Scott authored
      Summary:
      Because we weren't checking for duplicate variables on the right-hand
      sides of pattern synonyms, bogus definitions like this one passed the renamer:
      
      ```lang=haskell
      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
      a89bb806
    • Ryan Scott's avatar
      Fix #14125 by normalizing data family instances more aggressively · 6982ee99
      Ryan Scott authored
      Summary:
      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
      6982ee99
  16. 18 Aug, 2017 1 commit
  17. 17 Aug, 2017 5 commits