1. 19 Aug, 2020 1 commit
    • 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.
      0c5ed5c7
  2. 18 Aug, 2020 2 commits
    • fendor's avatar
      9ad5cab3
    • 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.
      f4cc57fa
  3. 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:
          T10421
          T10421a
          T12150
          T12227
          T12425
          T12545
          T12707
          T13035
          T14683
          T3064
          T4801
          T5030
          T5321FD
          T5321Fun
          T5631
          T5642
          T783
          T9020
          T9961
          haddock.Cabal
          haddock.compiler
      Metric Decrease 'compile_time/bytes allocated':
          T1969
      Metric Increase 'compile_time/max_bytes_used':
          T1969
          T10370
          haddock.base
      8a51b2ab
  4. 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
      easier.
      
      Bump haddock submodule
      ffc0d578
    • 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
      RHS.
      
      Fixes #18533.
      Regression test case: T18533
      55dec4dc
    • Ben Gamari's avatar
      parser: Suggest ImportQualifiedPost in prepositive import warning · 7831fe05
      Ben Gamari authored
      As suggested in #18545.
      7831fe05
    • Alan Zimmerman's avatar
      25fdf25e
    • 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]
      bee43aca
  5. 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
      accbc242
    • 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.
      ab4d1589
  6. 11 Aug, 2020 1 commit
  7. 10 Aug, 2020 2 commits
  8. 08 Aug, 2020 1 commit
  9. 07 Aug, 2020 5 commits
  10. 06 Aug, 2020 6 commits
    • Sylvain Henry's avatar
      Use a type alias for Ways · 63348155
      Sylvain Henry authored
      63348155
    • Richard Eisenberg's avatar
      Fail eagerly on a lev-poly datacon arg · d2a43225
      Richard Eisenberg authored
      Close #18534.
      
      See commentary in the patch.
      d2a43225
    • 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
      0ddb4384
    • 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.
      826d07db
    • 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.
      6770e199
    • 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:
      
      	tyapps
      	  : tyapp
      	  | tyapps tyapp
      
      	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
      types:
      
      	infixtype
      	  : ftype
      	  | ftype tyop infixtype
      	  | unpackedness infixtype
      
      	ftype
      	  : atype
      	  | tyop
      	  | ftype tyarg
      	  | ftype PREFIX_AT tyarg
      
      	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.
      686e06c5
  11. 05 Aug, 2020 2 commits
  12. 03 Aug, 2020 1 commit
  13. 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
      bit:
      
      * The nested `forall`s check now lives in the `rnConDecl` case for
        `ConDeclGADT`.
      * 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.
      22641742
  14. 31 Jul, 2020 4 commits
  15. 30 Jul, 2020 6 commits
    • Simon Peyton Jones's avatar
      Add two bangs to improve perf of flattening · 9f71f697
      Simon Peyton Jones authored
      This tiny patch improves the compile time of flatten-heavy
      programs by 1-2%, by adding two bangs.
      
      Addresses (somewhat) #18502
      
      This reduces allocation by
         T9872b   -1.1%
         T9872d   -3.3%
      
         T5321Fun -0.2%
         T5631    -0.2%
         T5837    +0.1%
         T6048    +0.1%
      
      Metric Decrease:
          T9872b
          T9872d
      9f71f697
    • Simon Peyton Jones's avatar
      Remove an incorrect WARN in extendLocalRdrEnv · ebe2cf45
      Simon Peyton Jones authored
      I noticed this warning going off, and discovered that it's
      really fine.  This small patch removes the warning, and docments
      what is going on.
      ebe2cf45
    • Ryan Scott's avatar
      Don't mark closed type family equations as occurrences · d47324ce
      Ryan Scott authored
      Previously, `rnFamInstEqn` would mark the name of the type/data
      family used in an equation as an occurrence, regardless of what sort
      of family it is. Most of the time, this is the correct thing to do.
      The exception is closed type families, whose equations constitute its
      definition and therefore should not be marked as occurrences.
      Overzealously counting the equations of a closed type family as
      occurrences can cause certain warnings to not be emitted, as observed
      in #18470.  See `Note [Type family equations and occurrences]` in
      `GHC.Rename.Module` for the full story.
      
      This fixes #18470 with a little bit of extra-casing in
      `rnFamInstEqn`. To accomplish this, I added an extra
      `ClosedTyFamInfo` field to the `NonAssocTyFamEqn` constructor of
      `AssocTyFamInfo` and refactored the relevant call sites accordingly
      so that this information is propagated to `rnFamInstEqn`.
      
      While I was in town, I moved `wrongTyFamName`, which checks that the
      name of a closed type family matches the name in an equation for that
      family, from the renamer to the typechecker to avoid the need for an
      `ASSERT`. As an added bonus, this lets us simplify the details of
      `ClosedTyFamInfo` a bit.
      d47324ce
    • Ryan Scott's avatar
      Clean up the inferred type variable restriction · 01c948eb
      Ryan Scott authored
      This patch primarily:
      
      * Documents `checkInferredVars` (previously called
        `check_inferred_vars`) more carefully. This is the
        function which throws an error message if a user quantifies an
        inferred type variable in a place where specificity cannot be
        observed. See `Note [Unobservably inferred type variables]` in
        `GHC.Rename.HsType`.
      
        Note that I now invoke `checkInferredVars` _alongside_
        `rnHsSigType`, `rnHsWcSigType`, etc. rather than doing so _inside_
        of these functions. This results in slightly more call sites for
        `checkInferredVars`, but it makes it much easier to enumerate the
        spots where the inferred type variable restriction comes into
        effect.
      * Removes the inferred type variable restriction for default method
        type signatures, per the discussion in #18432. As a result, this
        patch fixes #18432.
      
      Along the way, I performed some various cleanup:
      
      * I moved `no_nested_foralls_contexts_err` into `GHC.Rename.Utils`
        (under the new name `noNestedForallsContextsErr`), since it now
        needs to be invoked from multiple modules. I also added a helper
        function `addNoNestedForallsContextsErr` that throws the error
        message after producing it, as this is a common idiom.
      * In order to ensure that users cannot sneak inferred type variables
        into `SPECIALISE instance` pragmas by way of nested `forall`s, I
        now invoke `addNoNestedForallsContextsErr` when renaming
        `SPECIALISE instance` pragmas, much like when we rename normal
        instance declarations. (This probably should have originally been
        done as a part of the fix for #18240, but this task was somehow
        overlooked.) As a result, this patch fixes #18455 as a side effect.
      01c948eb
    • cgibbard's avatar
      Add haddock comment for unfilteredEdges · 502de556
      cgibbard authored
      and move the note about drop_hs_boot_nodes into it.
      502de556
    • John Ericson's avatar
      For `-fkeep-going` do not duplicate dependency edge code · 6c68a842
      John Ericson authored
      We now compute the deps for `-fkeep-going` the same way that the
      original graph calculates them, so the edges are correct. Upsweep really
      ought to take the graph rather than a topological sort so we are never
      recalculating anything, but at least things are recaluclated
      consistently now.
      6c68a842