1. 07 Jan, 2021 6 commits
  2. 05 Jan, 2021 1 commit
    • Sylvain Henry's avatar
      Implement Unique supply with Addr# atomic primop · 6c771aaf
      Sylvain Henry authored
      Before this patch the compiler depended on the RTS way (threaded or not)
      to use atomic incrementation or not. This is wrong because the RTS is
      supposed to be switchable at link time, without recompilation.
      
      Now we always use atomic incrementation of the unique counter.
      6c771aaf
  3. 03 Jan, 2021 3 commits
  4. 02 Jan, 2021 12 commits
    • Simon Peyton Jones's avatar
      Add regression test for #18467 · ee1161d3
      Simon Peyton Jones authored
      ee1161d3
    • Simon Peyton Jones's avatar
      Don't use absentError thunks for strict constructor fields · a8926e95
      Simon Peyton Jones authored
      This patch fixes #19133 by using LitRubbish for strict constructor
      fields, even if they are of lifted types.  Previously LitRubbish
      worked only for unlifted (but boxed) types.
      
      The change is very easy, although I needed a boolean field in
      LitRubbish to say whether or not it is lifted.  (That seemed easier
      than giving it another type argument.
      
      This is preparing for Andreas's work on establishing the invariant
      that strict constructor fields are always tagged and evaluated
      (see #16970).
      
      Meanwhile, nothing was actually wrong before, so there are no tests.
      a8926e95
    • Asad Saeeduddin's avatar
      cc87bda6
    • Oleg Grenrus's avatar
      Correct doctests · aa17b84d
      Oleg Grenrus authored
      It's simpler to assume that base is NoImplicitPrelude,
      otherwise running doctest on `GHC.*` modules would be tricky.
      OTOH, most `GHC.List` (where the most name clashes are) examples
      could be changed to use `import qualified Data.List as L`.
      (GHC.List examples won't show for Foldable methods...).
      
      With these changes majority of doctest examples are GHCi-"faithful",
      my WIP GHC-independent doctest runner reports nice summary:
      
      Examples: 582; Tried: 546; Skipped: 34; Success: 515; Errors: 33; Property Failures 2
      
      Most error cases are *Hangs forever*.
      I have yet to figure out how to demonstrate that in GHCi.
      Some of divergences are actually stack overflows, i.e. caught by
      runtime.
      
      Few errorful cases are examples of infinite output, e.g.
      
          >>> cycle [42]
          [42,42,42,42,42,42,42,42,42,42...
      
      while correct, they confuse doctest.
      
      Another erroneous cases are where expected output has line comment, like
      
          >>> fmap show (Just 1)  --  (a   -> b)      -> f a       -> f b
          Just "1"                --  (Int -> String) -> Maybe Int -> Maybe String
      
      I think I just have to teach doctest to strip comments from expected
      output.
      
      This is a first patch in a series.
      There is plenty of stuff already.
      aa17b84d
    • Hécate Moonlight's avatar
    • Hécate Moonlight's avatar
    • Douglas Wilson's avatar
      rts: update usage text for new -A default · d9788fd2
      Douglas Wilson authored
      d9788fd2
    • Joachim Breitner's avatar
      Docs: Remove reference to `type_applications` in `exts/patterns.rst` · c2a007c7
      Joachim Breitner authored
      it is unclear why it is there, and it is _also_ linked from
      `exts/types.rst`.
      c2a007c7
    • Simon Peyton Jones's avatar
      Establish invariant (GivenInv) · 5650c79e
      Simon Peyton Jones authored
      This patch establishes invariant (GivenInv) from GHC.Tc.Utils.TcType
      Note [TcLevel invariants].  (GivenInv) says that unification variables
      from level 'n' should not appear in the Givens for level 'n'.  See
      Note [GivenInv] in teh same module.
      
      This invariant was already very nearly true, but a dark corner of
      partial type signatures made it false.  The patch re-jigs partial type
      signatures a bit to avoid the problem, and documents the invariant
      much more thorughly
      
      Fixes #18646 along the way: see Note [Extra-constraints wildcards]
      in GHC.Tc.Gen.Bind
      
      I also simplified the interface to tcSimplifyInfer slightly, so that
      it /emits/ the residual constraint, rather than /returning/ it.
      5650c79e
    • Ben Gamari's avatar
      rts/Messages: Relax locked-closure assertion · 87bc458d
      Ben Gamari authored
      In general we are less careful about locking closures when running with
      only a single capability.
      
      Fixes #19075.
      87bc458d
    • Artem Pelenitsyn's avatar
      77c4a15f
    • Sylvain Henry's avatar
      Make proper fixed-width number literals · 85d899c8
      Sylvain Henry authored
      (Progress towards #11953, #17377, #17375)
      
      Besides being nicer to use, this also will allow for better constant
      folding for the fixed-width types, on par with what `Int#` and `Word#`
      have today.
      85d899c8
  5. 31 Dec, 2020 1 commit
    • cgibbard's avatar
      INLINE pragma for patterns (#12178) · 9b563330
      cgibbard authored
      Allow INLINE and NOINLINE pragmas to be used for patterns.
      Those are applied to both the builder and matcher (where applicable).
      9b563330
  6. 28 Dec, 2020 1 commit
    • John Ericson's avatar
      Put hole instantiation typechecking in the module graph and fix driver batch mode backpack edges · 2113a1d6
      John Ericson authored
      Backpack instantiations need to be typechecked to make sure that the
      arguments fit the parameters. `tcRnInstantiateSignature` checks
      instantiations with concrete modules, while `tcRnCheckUnit` checks
      instantiations with free holes (signatures in the current modules).
      
      Before this change, it worked that `tcRnInstantiateSignature` was called
      after typechecking the argument module, see `HscMain.hsc_typecheck`,
      while `tcRnCheckUnit` was called in `unsweep'` where-bound in
      `GhcMake.upsweep`. `tcRnCheckUnit` was called once per each
      instantiation once all the argument sigs were processed. This was done
      with simple "to do" and "already done" accumulators in the fold.
      `parUpsweep` did not implement the change.
      
      With this change, `tcRnCheckUnit` instead is associated with its own
      node in the `ModuleGraph`. Nodes are now:
      ```haskell
      data ModuleGraphNode
        -- | Instantiation nodes track the instantiation of other units
        -- (backpack dependencies) with the holes (signatures) of the current package.
        = InstantiationNode InstantiatedUnit
        -- | There is a module summary node for each module, signature, and boot module being built.
        | ModuleNode ExtendedModSummary
      ```
      instead of just `ModSummary`; the `InstantiationNode` case is the
      instantiation of a unit to be checked. The dependencies of such nodes
      are the same "free holes" as was checked with the accumulator before.
      Both versions of upsweep on such a node call `tcRnCheckUnit`.
      
      There previously was an `implicitRequirements` function which would
      crawl through every non-current-unit module dep to look for all free
      holes (signatures) to add as dependencies in `GHC.Driver.Make`. But this
      is no good: we shouldn't be looking for transitive anything when
      building the graph: the graph should only have immediate edges and the
      scheduler takes care that all transitive requirements are met.
      
      So `GHC.Driver.Make` stopped using `implicitRequirements`, and instead
      uses a new `implicitRequirementsShallow`, which just returns the
      outermost instantiation node (or module name if the immediate dependency
      is itself a signature). The signature dependencies are just treated like
      any other imported module, but the module ones then go in a list stored
      in the `ModuleNode` next to the `ModSummary` as the "extra backpack
      dependencies". When `downsweep` creates the mod summaries, it adds this
      information too.
      
      ------
      
      There is one code quality, and possible correctness thing left: In
      addition to `implicitRequirements` there is `findExtraSigImports`, which
      says something like "if you are an instantiation argument (you are
      substituted or a signature), you need to import its things too".  This
      is a little non-local so I am not quite sure how to get rid of it in
      `GHC.Driver.Make`, but we probably should eventually.
      
      First though, let's try to make a test case that observes that we don't
      do this, lest it actually be unneeded. Until then, I'm happy to leave it
      as is.
      
      ------
      
      Beside the ability to use `-j`, the other major user-visibile side
      effect of this change is that that the --make progress log now includes
      "Instantiating" messages for these new nodes. Those also are numbered
      like module nodes and count towards the total.
      
      ------
      
      Fixes #17188
      
      Updates hackage submomdule
      
      Metric Increase:
          T12425
          T13035
      2113a1d6
  7. 25 Dec, 2020 2 commits
  8. 24 Dec, 2020 4 commits
    • John Ericson's avatar
      Use `hscFrontendHook` again · adaa6194
      John Ericson authored
      In eb629fab I accidentally got rid of it when inlining tons of helpers.
      
      Closes #19004
      adaa6194
    • Adam Gundry's avatar
      Refactor renamer datastructures · 6f8bafb4
      Adam Gundry authored
      This patch significantly refactors key renamer datastructures (primarily Avail
      and GlobalRdrElt) in order to treat DuplicateRecordFields in a more robust way.
      In particular it allows the extension to be used with pattern synonyms (fixes
      where mangled record selector names could be printed instead of field labels
      (e.g. with -Wpartial-fields or hole fits, see new tests).
      
      The key idea is the introduction of a new type GreName for names that may
      represent either normal entities or field labels.  This is then used in
      GlobalRdrElt and AvailInfo, in place of the old way of representing fields
      using FldParent (yuck) and an extra list in AvailTC.
      
      Updates the haddock submodule.
      6f8bafb4
    • Ryan Scott's avatar
    • Simon Peyton Jones's avatar
      Clone the binders of a SAKS where necessary · e7d8e4ee
      Simon Peyton Jones authored
      Given a kind signature
      
         type T :: forall k. k -> forall k. k -> blah
         data T a b = ...
      
      where those k's have the same unique (which is possible;
      see #19093) we were giving the tyConBinders in tycon T the same
      unique, which caused chaos.
      
      Fix is simple: ensure uniqueness when decomposing the kind signature.
      See GHC.Tc.Gen.HsType.zipBinders
      e7d8e4ee
  9. 23 Dec, 2020 8 commits
    • Simon Peyton Jones's avatar
      Document scoping of named wildcard type variables · 79d41f93
      Simon Peyton Jones authored
      See `Note [Scoping of named wildcards]` in GHC.Hs.Type
      
      This lack of documentation came up in #19051.
      79d41f93
    • Douglas Wilson's avatar
      spelling: thead -> thread · cce1514a
      Douglas Wilson authored
      cce1514a
    • Sylvain Henry's avatar
      f59c34b8
    • Sebastian Graf's avatar
      WorkWrap: Unbox constructors with existentials (#18982) · f0ec06c7
      Sebastian Graf authored
      Consider
      
      ```hs
      data Ex where
        Ex :: e -> Int -> Ex
      
      f :: Ex -> Int
      f (Ex e n) = e `seq` n + 1
      ```
      
      Worker/wrapper should build the following worker for `f`:
      
      ```hs
      $wf :: forall e. e -> Int# -> Int#
      $wf e n = e `seq` n +# 1#
      ```
      
      But previously it didn't, because `Ex` binds an existential.
      This patch lifts that condition. That entailed having to instantiate
      existential binders in `GHC.Core.Opt.WorkWrap.Utils.mkWWstr` via
      `GHC.Core.Utils.dataConRepFSInstPat`, requiring a bit of a refactoring
      around what is now `DataConPatContext`.
      
      CPR W/W still won't unbox DataCons with existentials.
      See `Note [Which types are unboxed?]` for details.
      
      I also refactored the various `tyCon*DataCon(s)_maybe` functions in
      `GHC.Core.TyCon`, deleting some of them which are no longer needed
      (`isDataProductType_maybe` and `isDataSumType_maybe`).
      I cleaned up a couple of call sites, some of which weren't very explicit
      about whether they cared for existentials or not.
      
      The test output of `T18013` changed, because we now unbox the `Rule`
      data type. Its constructor carries existential state and will be
      w/w'd now. In the particular example, the worker functions inlines right
      back into the wrapper, which then unnecessarily has a (quite big) stable
      unfolding. I think this kind of fallout is inevitable;
      see also Note [Don't w/w inline small non-loop-breaker things].
      
      There's a new regression test case `T18982`.
      Fixes #18982.
      f0ec06c7
    • Sebastian Graf's avatar
      DmdAnal: Keep alive RULE vars in LetUp (#18971) · 56841432
      Sebastian Graf authored
      I also took the liberty to refactor the logic around `ruleFVs`.
      56841432
    • Adam Sandberg Eriksson's avatar
      mkDocs: address shellcheck issues · 50236ed2
      Adam Sandberg Eriksson authored
      50236ed2
    • Adam Sandberg Eriksson's avatar
    • Andreas Klebinger's avatar
      Increase -A default to 4MB. · 553c59ca
      Andreas Klebinger authored
      This gives a small increase in performance under most circumstances.
      
      For single threaded GC the improvement is on the order of 1-2%.
      
      For multi threaded GC the results are quite noisy but seem to
      fall into the same ballpark.
      
      Fixes #16499
      553c59ca
  10. 22 Dec, 2020 2 commits