1. 24 May, 2019 3 commits
  2. 22 May, 2019 4 commits
    • Ryan Scott's avatar
      Use HsTyPats in associated type family defaults · 6efe04de
      Ryan Scott authored
      Associated type family default declarations behave strangely in a
      couple of ways:
      
      1. If one tries to bind the type variables with an explicit `forall`,
         the `forall`'d part will simply be ignored. (#16110)
      2. One cannot use visible kind application syntax on the left-hand
         sides of associated default equations, unlike every other form
         of type family equation. (#16356)
      
      Both of these issues have a common solution. Instead of using
      `LHsQTyVars` to represent the left-hand side arguments of an
      associated default equation, we instead use `HsTyPats`, which is what
      other forms of type family equations use. In particular, here are
      some highlights of this patch:
      
      * `FamEqn` is no longer parameterized by a `pats` type variable, as
        the `feqn_pats` field is now always `HsTyPats`.
      * The new design for `FamEqn` in chronicled in
        `Note [Type family instance declarations in HsSyn]`.
      * `TyFamDefltEqn` now becomes the same thing as `TyFamInstEqn`. This
        means that many of `TyFamDefltEqn`'s code paths can now reuse the
        code paths for `TyFamInstEqn`, resulting in substantial
        simplifications to various parts of the code dealing with
        associated type family defaults.
      
      Fixes #16110 and #16356.
      6efe04de
    • KevinBuhr's avatar
      78c3f330
    • Michael Sloan's avatar
      Have GHCi use object code for UnboxedTuples modules #15454 · 21272670
      Michael Sloan authored
      The idea is to automatically enable -fobject-code for modules that use
      UnboxedTuples, along with all the modules they depend on. When looking
      into how to solve this, I was pleased to find that there was already
      highly similar logic for enabling code generation when -fno-code is
      specified but TemplateHaskell is used.
      
      The state before this patch was that if you used unboxed tuples then you
      had to enable `-fobject-code` globally rather than on a per module
      basis.
      21272670
    • Julian Leviston's avatar
  3. 21 May, 2019 2 commits
    • Ryan Scott's avatar
      Fix #16666 by parenthesizing contexts in Convert · 4a6c8436
      Ryan Scott authored
      Most places where we convert contexts in `Convert` are actually in
      positions that are to the left of some `=>`, such as in superclasses
      and instance contexts. Accordingly, these contexts need to be
      parenthesized at `funPrec`. To accomplish this, this patch changes
      `cvtContext` to require a precedence argument for the purposes of
      calling `parenthesizeHsContext` and adjusts all `cvtContext` call
      sites accordingly.
      4a6c8436
    • David Eichmann's avatar
      8fc654c3
  4. 20 May, 2019 1 commit
  5. 14 May, 2019 5 commits
  6. 10 May, 2019 2 commits
  7. 08 May, 2019 6 commits
  8. 07 May, 2019 2 commits
  9. 06 May, 2019 1 commit
    • Alp Mestanogullari's avatar
      Hadrian: override $(ghc-config-mk), to prevent redundant config generation · ba0aed2e
      Alp Mestanogullari authored
      This required making the 'ghc-config-mk' variable overridable in
      testsuite/mk/boilerplate.mk, and then making use of this in hadrian
      to point to '<build root>/test/ghcconfig' instead, which is where we
      always put the test config.
      
      Previously, we would build ghc-config and run it against the
      GHC to be tested, a second time, while we're running the tests, because some
      include testsuite/mk/boilerplate.mk. This was causing unexpected output
      failures.
      ba0aed2e
  10. 05 May, 2019 1 commit
  11. 03 May, 2019 4 commits
    • Ryan Scott's avatar
      Make equality constraints in kinds invisible · cc495d57
      Ryan Scott authored
      Issues #12102 and #15872 revealed something strange about the way GHC
      handles equality constraints in kinds: it treats them as _visible_
      arguments! This causes a litany of strange effects, from strange
      error messages
      (#12102 (comment 169035))
      to bizarre `Eq#`-related things leaking through to GHCi output, even
      without any special flags enabled.
      
      This patch is an attempt to contain some of this strangeness.
      In particular:
      
      * In `TcHsType.etaExpandAlgTyCon`, we propagate through the
        `AnonArgFlag`s of any `Anon` binders. Previously, we were always
        hard-coding them to `VisArg`, which meant that invisible binders
        (like those whose kinds were equality constraint) would mistakenly
        get flagged as visible.
      * In `ToIface.toIfaceAppArgsX`, we previously assumed that the
        argument to a `FunTy` always corresponding to a `Required`
        argument. We now dispatch on the `FunTy`'s `AnonArgFlag` and map
        `VisArg` to `Required` and `InvisArg` to `Inferred`. As a
        consequence, the iface pretty-printer correctly recognizes that
        equality coercions are inferred arguments, and as a result,
        only displays them in `-fprint-explicit-kinds` is enabled.
      * Speaking of iface pretty-printing, `Anon InvisArg` binders were
        previously being pretty-printed like `T (a :: b ~ c)`, as if they
        were required. This seemed inconsistent with other invisible
        arguments (that are printed like `T @{d}`), so I decided to switch
        this to `T @{a :: b ~ c}`.
      
      Along the way, I also cleaned up a minor inaccuracy in the users'
      guide section for constraints in kinds that was spotted in
      #12102 (comment 136220).
      
      Fixes #12102 and #15872.
      cc495d57
    • Ningning Xie's avatar
      9b59e126
    • Vladislav Zavialov's avatar
      Pattern/expression ambiguity resolution · 52fc2719
      Vladislav Zavialov authored
      This patch removes 'EWildPat', 'EAsPat', 'EViewPat', and 'ELazyPat'
      from 'HsExpr' by using the ambiguity resolution system introduced
      earlier for the command/expression ambiguity.
      
      Problem: there are places in the grammar where we do not know whether we
      are parsing an expression or a pattern, for example:
      
      	do { Con a b <- x } -- 'Con a b' is a pattern
      	do { Con a b }      -- 'Con a b' is an expression
      
      Until we encounter binding syntax (<-) we don't know whether to parse
      'Con a b' as an expression or a pattern.
      
      The old solution was to parse as HsExpr always, and rejig later:
      
      	checkPattern :: LHsExpr GhcPs -> P (LPat GhcPs)
      
      This meant polluting 'HsExpr' with pattern-related constructors. In
      other words, limitations of the parser were affecting the AST, and all
      other code (the renamer, the typechecker) had to deal with these extra
      constructors.
      
      We fix this abstraction leak by parsing into an overloaded
      representation:
      
      	class DisambECP b where ...
      	newtype ECP = ECP { runECP_PV :: forall b. DisambECP b => PV (Located b) }
      
      See Note [Ambiguous syntactic categories] for details.
      
      Now the intricacies of parsing have no effect on the hsSyn AST when it
      comes to the expression/pattern ambiguity.
      52fc2719
    • Ben Gamari's avatar
      testsuite: Mark concprog001 as fragile · 0dde64f2
      Ben Gamari authored
      Due to #16604.
      0dde64f2
  12. 01 May, 2019 1 commit
    • Sebastian Graf's avatar
      Compute demand signatures assuming idArity · 014ed644
      Sebastian Graf authored
      This does four things:
      
      1. Look at `idArity` instead of manifest lambdas to decide whether to use LetUp
      2. Compute the strictness signature in LetDown assuming at least `idArity`
         incoming arguments
      3. Remove the special case for trivial RHSs, which is subsumed by 2
      4. Don't perform the W/W split when doing so would eta expand a binding.
         Otherwise we would eta expand PAPs, causing unnecessary churn in the
         Simplifier.
      
      NoFib Results
      
      --------------------------------------------------------------------------------
              Program         Allocs    Instrs
      --------------------------------------------------------------------------------
       fannkuch-redux          +0.3%      0.0%
                   gg          -0.0%     -0.1%
             maillist          +0.2%     +0.2%
              minimax           0.0%     +0.8%
               pretty           0.0%     -0.1%
              reptile          -0.0%     -1.2%
      --------------------------------------------------------------------------------
                  Min          -0.0%     -1.2%
                  Max          +0.3%     +0.8%
       Geometric Mean          +0.0%     -0.0%
      014ed644
  13. 30 Apr, 2019 4 commits
  14. 22 Apr, 2019 1 commit
  15. 21 Apr, 2019 2 commits
  16. 20 Apr, 2019 1 commit
    • Alec Theriault's avatar
      Haddock: support strict GADT args with docs · 99dd5d6b
      Alec Theriault authored
      Rather than massaging the output of the parser to re-arrange docs and
      bangs, it is simpler to patch the two places in which the strictness
      info is needed (to accept that the `HsBangTy` may be inside an
      `HsDocTy`).
      
      Fixes #16585.
      99dd5d6b