1. 19 May, 2020 4 commits
  2. 10 May, 2020 2 commits
  3. 08 May, 2020 17 commits
  4. 06 May, 2020 10 commits
    • Ryan Scott's avatar
      Refactoring: Use bindSigTyVarsFV in rnMethodBinds · 9afd9251
      Ryan Scott authored
      `rnMethodBinds` was explicitly using `xoptM` to determine if
      `ScopedTypeVariables` is enabled before bringing type variables
      bound by the class/instance header into scope. However, this `xoptM`
      logic is already performed by the `bindSigTyVarsFV` function. This
      patch uses `bindSigTyVarsFV` in `rnMethodBinds` to reduce the number
      of places where we need to consult if `ScopedTypeVariables` is on.
      This is purely refactoring, and there should be no user-visible
      change in behavior.
    • Sylvain Henry's avatar
    • Sylvain Henry's avatar
      Move LeadingUnderscore into Platform (#17957) · cab1871a
      Sylvain Henry authored
      Avoid direct use of DynFlags to know if symbols must be prefixed by an
    • Ömer Sinan Ağacan's avatar
      ELF linker: increment curSymbol after filling in fields of current entry · a95e7fe0
      Ömer Sinan Ağacan authored
      The bug was introduced in a8b7cef4 which added a field to the
      `symbols` array elements and then updated this code incorrectly:
          - oc->symbols[curSymbol++] = nm;
          + oc->symbols[curSymbol++].name = nm;
          + oc->symbols[curSymbol].addr = symbol->addr;
    • Ryan Scott's avatar
      Make isTauTy detect higher-rank contexts · edec6a6c
      Ryan Scott authored
      Previously, `isTauTy` would only detect higher-rank `forall`s, not
      higher-rank contexts, which led to some minor bugs observed
      in #18127. Easily fixed by adding a case for
      `(FunTy InvisArg _ _)`.
      Fixes #18127.
    • wz1000's avatar
      Allow atomic update of NameCache in readHieFile · 9f3e6884
      wz1000 authored
      The situation arises in ghcide where multiple different threads may need to
      update the name cache, therefore with the older interface it could happen
      that you start reading a hie file with name cache A and produce name cache
      A + B, but another thread in the meantime updated the namecache to A +
      C. Therefore if you write the new namecache you will lose the A' updates
      from the second thread.
      Updates haddock submodule
    • Ben Gamari's avatar
      nonmoving: Fix handling of dirty objects · b2d72c75
      Ben Gamari authored
      Previously we (incorrectly) relied on failed_to_evac to be "precise".
      That is, we expected it to only be true if *all* of an object's fields
      lived outside of the non-moving heap. However, does not match the
      behavior of failed_to_evac, which is true if *any* of the object's
      fields weren't promoted (meaning that some others *may* live in the
      non-moving heap).
      This is problematic as we skip the non-moving write barrier for dirty
      objects (which we can only safely do if *all* fields point outside of
      the non-moving heap).
      Clearly this arises due to a fundamental difference in the behavior
      expected of failed_to_evac in the moving and non-moving collector.
      e.g., in the moving collector it is always safe to conservatively say
      failed_to_evac=true whereas in the non-moving collector the safe value
      is false.
      This issue went unnoticed as I never wrote down the dirtiness
      invariant enforced by the non-moving collector. We now define this
      invariant as
          An object being marked as dirty implies that all of its fields are
          on the mark queue (or, equivalently, update remembered set).
      To maintain this invariant we teach nonmovingScavengeOne to push the
      fields of objects which we fail to evacuate to the update remembered
      set. This is a simple and reasonably cheap solution and avoids the
      complexity and fragility that other, more strict alternative invariants
      would require.
      All of this is described in a new Note, Note [Dirty flags in the
      non-moving collector] in NonMoving.c.
    • Ben Gamari's avatar
      nonmoving: Fix incorrect failed_to_evac value during deadlock gc · 740b3b8d
      Ben Gamari authored
      Previously we would incorrectly set the failed_to_evac flag if we
      evacuated a value due to a deadlock GC. This would cause us to mark more
      things as dirty than strictly necessary. It also turned up a nasty but
      which I will fix next.
    • Ben Gamari's avatar
      rts: Zero block flags with -DZ · 420b957d
      Ben Gamari authored
      Block flags are very useful for determining the state of a block.
      However, some block allocator users don't touch them, leading to
      misleading values. Ensure that we zero then when zero-on-gc is set. This
      is safe and makes the flags more useful during debugging.
    • Richard Eisenberg's avatar
      Refactor hole constraints. · 7ab6ab09
      Richard Eisenberg authored
      Previously, holes (both expression holes / out of scope variables and
      partial-type-signature wildcards) were emitted as *constraints* via
      the CHoleCan constructor. While this worked fine for error reporting,
      there was a fair amount of faff in keeping these constraints in line.
      In particular, and unlike other constraints, we could never change
      a CHoleCan to become CNonCanonical. In addition:
       * the "predicate" of a CHoleCan constraint was really the type
         of the hole, which is not a predicate at all
       * type-level holes (partial type signature wildcards) carried
         evidence, which was never used
       * tcNormalise (used in the pattern-match checker) had to create
         a hole constraint just to extract it again; it was quite messy
      The new approach is to record holes directly in WantedConstraints.
      It flows much more nicely now.
      Along the way, I did some cleaning up of commentary in
      GHC.Tc.Errors.Hole, which I had a hard time understanding.
      This was instigated by a future patch that will refactor
      the way predicates are handled. The fact that CHoleCan's
      "predicate" wasn't really a predicate is incompatible with
      that future patch.
      No test case, because this is meant to be purely internal.
      It turns out that this change improves the performance of
      the pattern-match checker, likely because fewer constraints
      are sloshing about in tcNormalise. I have not investigated
      deeply, but an improvement is not a surprise here:
      Metric Decrease:
  5. 05 May, 2020 5 commits
  6. 04 May, 2020 2 commits