1. 21 Aug, 2020 5 commits
  2. 19 Aug, 2020 3 commits
    • Simon Peyton Jones's avatar
      Add right-to-left rule for pattern bindings · eb9bdaef
      Simon Peyton Jones authored
      Fix #18323 by adding a few lines of code to handle non-recursive
      pattern bindings.  see GHC.Tc.Gen.Bind
      Note [Special case for non-recursive pattern bindings]
      Alas, this confused the pattern-match overlap checker; see #18323.
      Note that this patch only affects pattern bindings like that
      for (x,y) in this program
        combine :: (forall a . [a] -> a) -> [forall a. a -> a]
                -> ((forall a . [a] -> a), [forall a. a -> a])
        breaks = let (x,y) = combine head ids
                 in x y True
      We need ImpredicativeTypes for those [forall a. a->a] types to be
      valid. And with ImpredicativeTypes the old, unprincipled "allow
      unification variables to unify with a polytype" story actually
      works quite well. So this test compiles fine (if delicatedly) with
      old GHCs; but not with QuickLook unless we add this patch
    • Alex D's avatar
      Implement -Wredundant-bang-patterns (#17340) · 731c8d3b
      Alex D authored
      Add new flag '-Wredundant-bang-patterns' that enables checks for "dead" bangs.
      Dead bangs are the ones that under no circumstances can force a thunk that
      wasn't already forced. Dead bangs are a form of redundant bangs. The new check
      is performed in Pattern-Match Coverage Checker along with other checks (namely,
      redundant and inaccessible RHSs). Given
          f :: Bool -> Int
          f True = 1
          f !x   = 2
      we can detect dead bang patterns by checking whether @x ~ ⊥@ is satisfiable
      where the PmBang appears in 'checkGrdTree'. If not, then clearly the bang is
      dead. Such a dead bang is then indicated in the annotated pattern-match tree by
      a 'RedundantSrcBang' wrapping. In 'redundantAndInaccessibles', we collect
      all dead bangs to warn about.
      Note that we don't want to warn for a dead bang that appears on a redundant
      clause. That is because in that case, we recommend to delete the clause wholly,
      including its leading pattern match.
      Dead bang patterns are redundant. But there are bang patterns which are
      redundant that aren't dead, for example
          f !() = 0
      the bang still forces the match variable, before we attempt to match on (). But
      it is redundant with the forcing done by the () match. We currently don't
      detect redundant bangs that aren't dead.
    • Sylvain Henry's avatar
      DynFlags: refactor GHC.CmmToAsm (#17957, #10143) · 0c5ed5c7
      Sylvain Henry authored
      This patch removes the use of `sdocWithDynFlags` from GHC.CmmToAsm.*.Ppr
      To do that I've had to make some refactoring:
      * X86' and PPC's `Instr` are no longer `Outputable` as they require a
        `Platform` argument
      * `Instruction` class now exposes `pprInstr :: Platform -> instr -> SDoc`
      * as a consequence, I've refactored some modules to avoid .hs-boot files
      * added (derived) functor instances for some datatypes parametric in the
        instruction type. It's useful for pretty-printing as we just have to
        map `pprInstr` before pretty-printing the container datatype.
  3. 18 Aug, 2020 2 commits
    • fendor's avatar
    • Ben Gamari's avatar
      Allow unsaturated runRW# applications · f4cc57fa
      Ben Gamari authored
      Previously we had a very aggressive Core Lint check which caught
      unsaturated applications of runRW#. However, there is nothing
      wrong with such applications and they may naturally arise in desugared
      Core. For instance, the desugared Core of Data.Primitive.Array.runArray#
      from the `primitive` package contains:
          case ($) (runRW# @_ @_) (\s -> ...) of ...
      In this case it's almost certain that ($) will be inlined, turning the
      application into a saturated application. However, even if this weren't
      the case there isn't a problem: CorePrep (after deleting an unnecessary
      case) can simply generate code in its usual way, resulting in a call to
      the Haskell definition of runRW#.
      Fixes #18291.
  4. 14 Aug, 2020 1 commit
    • Sylvain Henry's avatar
      Make IOEnv monad one-shot (#18202) · 8a51b2ab
      Sylvain Henry authored
      On CI (x86_64-linux-deb9-hadrian, compile_time/bytes_allocated):
          T10421     -1.8%    (threshold: +/- 1%)
          T10421a    -1.7%    (threshold: +/- 1%)
          T12150     -4.9%    (threshold: +/- 2%)
          T12227     -1.6     (threshold: +/- 1%)
          T12425     -1.5%    (threshold: +/- 1%)
          T12545     -3.8%    (threshold: +/- 1%)
          T12707     -3.0%    (threshold: +/- 1%)
          T13035     -3.0%    (threshold: +/- 1%)
          T14683     -10.3%   (threshold: +/- 2%)
          T3064      -6.9%    (threshold: +/- 2%)
          T4801      -4.3%    (threshold: +/- 2%)
          T5030      -2.6%    (threshold: +/- 2%)
          T5321FD    -3.6%    (threshold: +/- 2%)
          T5321Fun   -4.6%    (threshold: +/- 2%)
          T5631      -19.7%   (threshold: +/- 2%)
          T5642      -13.0%   (threshold: +/- 2%)
          T783       -2.7     (threshold: +/- 2%)
          T9020      -11.1    (threshold: +/- 2%)
          T9961      -3.4%    (threshold: +/- 2%)
          T1969 (compile_time/bytes_allocated)  -2.2%  (threshold: +/-1%)
          T1969 (compile_time/max_bytes_used)   +24.4% (threshold: +/-20%)
      Additionally on other CIs:
          haddock.Cabal                  -10.0%   (threshold: +/- 5%)
          haddock.compiler               -9.5%    (threshold: +/- 5%)
          haddock.base (max bytes used)  +24.6%   (threshold: +/- 15%)
          T10370 (max bytes used, i386)  +18.4%   (threshold: +/- 15%)
      Metric Decrease:
      Metric Decrease 'compile_time/bytes allocated':
      Metric Increase 'compile_time/max_bytes_used':
  5. 13 Aug, 2020 5 commits
    • Sylvain Henry's avatar
      Add HomeUnit type · ffc0d578
      Sylvain Henry authored
      Since Backpack the "home unit" is much more involved than what it was
      before (just an identifier obtained with `-this-unit-id`). Now it is
      used in conjunction with `-component-id` and `-instantiated-with` to
      configure module instantiations and to detect if we are type-checking an
      indefinite unit or compiling a definite one.
      This patch introduces a new HomeUnit datatype which is much easier to
      understand. Moreover to make GHC support several packages in the same
      instances, we will need to handle several HomeUnits so having a
      dedicated (documented) type is helpful.
      Finally in #14335 we will also need to handle the case where we have no
      HomeUnit at all because we are only loading existing interfaces for
      plugins which live in a different space compared to units used to
      produce target code. Several functions will have to be refactored to
      accept "Maybe HomeUnit" parameters instead of implicitly querying the
      HomeUnit fields in DynFlags. Having a dedicated type will make this
      Bump haddock submodule
    • Sebastian Graf's avatar
      PmCheck: Better long-distance info for where bindings (#18533) · 55dec4dc
      Sebastian Graf authored
      Where bindings can see evidence from the pattern match of the `GRHSs`
      they belong to, but not from anything in any of the guards (which belong
      to one of possibly many RHSs).
      Before this patch, we did *not* consider said evidence, causing #18533,
      where the lack of considering type information from a case pattern match
      leads to failure to resolve the vanilla COMPLETE set of a data type.
      Making available that information required a medium amount of
      refactoring so that `checkMatches` can return a
      `[(Deltas, NonEmpty Deltas)]`; one `(Deltas, NonEmpty Deltas)` for each
      `GRHSs` of the match group. The first component of the pair is the
      covered set of the pattern, the second component is one covered set per
      Fixes #18533.
      Regression test case: T18533
    • Ben Gamari's avatar
      parser: Suggest ImportQualifiedPost in prepositive import warning · 7831fe05
      Ben Gamari authored
      As suggested in #18545.
    • Alan Zimmerman's avatar
    • Sylvain Henry's avatar
      Rewrite and move the monad-state hack note · bee43aca
      Sylvain Henry authored
      The note has been rewritten by @simonpj in !3851
      [skip ci]
  6. 12 Aug, 2020 2 commits
    • Sylvain Henry's avatar
      DynFlags: disentangle Outputable · accbc242
      Sylvain Henry authored
      - put panic related functions into GHC.Utils.Panic
      - put trace related functions using DynFlags in GHC.Driver.Ppr
      One step closer making Outputable fully independent of DynFlags.
      Bump haddock submodule
    • Ben Gamari's avatar
      typecheck: Drop SPECIALISE pragmas when there is no unfolding · ab4d1589
      Ben Gamari authored
      Previously the desugarer would instead fall over when it realized that
      there was no unfolding for an imported function with a SPECIALISE
      pragma. We now rather drop the SPECIALISE pragma and throw a warning.
      Fixes #18118.
  7. 11 Aug, 2020 1 commit
  8. 10 Aug, 2020 2 commits
  9. 08 Aug, 2020 1 commit
  10. 07 Aug, 2020 5 commits
  11. 06 Aug, 2020 6 commits
    • Sylvain Henry's avatar
      Use a type alias for Ways · 63348155
      Sylvain Henry authored
    • Richard Eisenberg's avatar
      Fail eagerly on a lev-poly datacon arg · d2a43225
      Richard Eisenberg authored
      Close #18534.
      See commentary in the patch.
    • Vladislav Zavialov's avatar
      Fix visible forall in ppr_ty (#18522) · 0ddb4384
      Vladislav Zavialov authored
      Before this patch, this type:
        T :: forall k -> (k ~ k) => forall j -> k -> j -> Type
      was printed incorrectly as:
        T :: forall k j -> (k ~ k) => k -> j -> Type
    • Vladislav Zavialov's avatar
      Fix debug_ppr_ty ForAllTy (#18522) · 826d07db
      Vladislav Zavialov authored
      Before this change, GHC would
      pretty-print   forall k. forall a -> ()
                as   forall @k a. ()
      which isn't even valid Haskell.
    • Vladislav Zavialov's avatar
      Clean up the story around runPV/runECP_P/runECP_PV · 6770e199
      Vladislav Zavialov authored
      This patch started as a small documentation change, an attempt to make
      Note [Parser-Validator] and Note [Ambiguous syntactic categories]
      more clear and up-to-date.
      But it turned out that runECP_P/runECP_PV are weakly motivated,
      and it's easier to remove them than to find a good rationale/explanation
      for their existence.
      As the result, there's a bit of refactoring in addition to
      a documentation update.
    • Vladislav Zavialov's avatar
      Grammar for types and data/newtype constructors · 686e06c5
      Vladislav Zavialov authored
      Before this patch, we parsed types into a reversed sequence
      of operators and operands. For example, (F x y + G a b * X)
      would be parsed as [X, *, b, a, G, +, y, x, F],
      using a simple grammar:
      	  : tyapp
      	  | tyapps tyapp
      	  : atype
      	  | PREFIX_AT atype
      	  | tyop
      	  | unpackedness
      Then we used a hand-written state machine to assemble this
       either into a type,        using 'mergeOps',
           or into a constructor, using 'mergeDataCon'.
      This is due to a syntactic ambiguity:
      	data T1 a =          MkT1 a
      	data T2 a = Ord a => MkT2 a
      In T1, what follows after the = sign is a data/newtype constructor
      declaration. However, in T2, what follows is a type (of kind
      Constraint). We don't know which of the two we are parsing until we
      encounter =>, and we cannot check for => without unlimited lookahead.
      This poses a few issues when it comes to e.g. infix operators:
      	data I1 = Int :+ Bool :+ Char          -- bad
      	data I2 = Int :+ Bool :+ Char => MkI2  -- fine
      By this issue alone we are forced into parsing into an intermediate
      representation and doing a separate validation pass.
      However, should that intermediate representation be as low-level as a
      flat sequence of operators and operands?
      Before GHC Proposal #229, the answer was Yes, due to some particularly
      nasty corner cases:
      	data T = ! A :+ ! B          -- used to be fine, hard to parse
      	data T = ! A :+ ! B => MkT   -- bad
      However, now the answer is No, as this corner case is gone:
      	data T = ! A :+ ! B          -- bad
      	data T = ! A :+ ! B => MkT   -- bad
      This means we can write a proper grammar for types, overloading it in
      the DisambECP style, see Note [Ambiguous syntactic categories].
      With this patch, we introduce a new class, DisambTD. Just like
      DisambECP is used to disambiguate between expressions, commands, and patterns,
      DisambTD  is used to disambiguate between types and data/newtype constructors.
      This way, we get a proper, declarative grammar for constructors and
      	  : ftype
      	  | ftype tyop infixtype
      	  | unpackedness infixtype
      	  : atype
      	  | tyop
      	  | ftype tyarg
      	  | ftype PREFIX_AT tyarg
      	  : atype
      	  | unpackedness atype
      And having a grammar for types means we are a step closer to using a
      single grammar for types and expressions.
  12. 05 Aug, 2020 2 commits
  13. 03 Aug, 2020 1 commit
  14. 02 Aug, 2020 1 commit
    • Ryan Scott's avatar
      Remove ConDeclGADTPrefixPs · 22641742
      Ryan Scott authored
      This removes the `ConDeclGADTPrefixPs` per the discussion in #18517.
      Most of this patch simply removes code, although the code in the
      `rnConDecl` case for `ConDeclGADTPrefixPs` had to be moved around a
      * The nested `forall`s check now lives in the `rnConDecl` case for
      * The `LinearTypes`-specific code that used to live in the
        `rnConDecl` case for `ConDeclGADTPrefixPs` now lives in
        `GHC.Parser.PostProcess.mkGadtDecl`, which is now monadic so that
        it can check if `-XLinearTypes` is enabled.
      Fixes #18157.
  15. 31 Jul, 2020 3 commits