1. 06 May, 2020 8 commits
    • 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
      underscore.
      cab1871a
    • Ö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;
      a95e7fe0
    • 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.
      edec6a6c
    • Zubin's avatar
      Allow atomic update of NameCache in readHieFile · 9f3e6884
      Zubin 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
      9f3e6884
    • 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.
      b2d72c75
    • 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.
      740b3b8d
    • 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.
      420b957d
    • 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:
          PmSeriesG
      -------------------------
      7ab6ab09
  2. 05 May, 2020 5 commits
  3. 04 May, 2020 4 commits
  4. 03 May, 2020 4 commits
  5. 01 May, 2020 11 commits
  6. 30 Apr, 2020 8 commits
    • Matthew Pickering's avatar
      Hadrian: Improve tool-args command to support more components · 014ef4a3
      Matthew Pickering authored
      There is a new command to hadrian, tool:path/to/file.hs, which returns
      the options needed to compile that file in GHCi.
      
      This is now used in the ghci script with argument `ghc/Main.hs` but its
      main purpose is to support the new multi-component branch of ghcide.
      014ef4a3
    • Simon Peyton Jones's avatar
      Mark rule args as non-tail-called · 19b701c2
      Simon Peyton Jones authored
      This was just an omission...b I'd failed to call markAllNonTailCall on
      rule args.  I think this bug has been here a long time, but it's quite
      hard to trigger.
      
      Fixes #18098
      19b701c2
    • Simon Peyton Jones's avatar
      Add tests for #17873 · 5bdfdd13
      Simon Peyton Jones authored
      5bdfdd13
    • Alexis King's avatar
    • Alexis King's avatar
      a48cd2a0
    • Alexis King's avatar
      Allow block arguments in arrow control operators · 71484b09
      Alexis King authored
      Arrow control operators have their own entries in the grammar, so they
      did not cooperate with BlockArguments. This was just a minor oversight,
      so this patch adjusts the grammar to add the desired behavior.
      
      fixes #18050
      71484b09
    • Sylvain Henry's avatar
      Unit: split and rename modules · 8bfb0219
      Sylvain Henry authored
      Introduce GHC.Unit.* hierarchy for everything concerning units, packages
      and modules.
      
      Update Haddock submodule
      8bfb0219
    • Sylvain Henry's avatar
      Refactoring unit management code · 10d15f1e
      Sylvain Henry authored
      Over the years the unit management code has been modified a lot to keep
      up with changes in Cabal (e.g. support for several library components in
      the same package), to integrate BackPack, etc. I found it very hard to
      understand as the terminology wasn't consistent, was referring to past
      concepts, etc.
      
      The terminology is now explained as clearly as I could in the Note
      "About Units" and the code is refactored to reflect it.
      
      -------------------
      
      Many names were misleading: UnitId is not an Id but could be a virtual
      unit (an indefinite one instantiated on the fly), IndefUnitId
      constructor may contain a definite instantiated unit, etc.
      
         * Rename IndefUnitId into InstantiatedUnit
         * Rename IndefModule into InstantiatedModule
         * Rename UnitId type into Unit
         * Rename IndefiniteUnitId constructor into VirtUnit
         * Rename DefiniteUnitId constructor into RealUnit
         * Rename packageConfigId into mkUnit
         * Rename getPackageDetails into unsafeGetUnitInfo
         * Rename InstalledUnitId into UnitId
      
      Remove references to misleading ComponentId: a ComponentId is just an
      indefinite unit-id to be instantiated.
      
         * Rename ComponentId into IndefUnitId
         * Rename ComponentDetails into UnitPprInfo
         * Fix display of UnitPprInfo with empty version: this is now used for
           units dynamically generated by BackPack
      
      Generalize several types (Module, Unit, etc.) so that they can be used
      with different unit identifier types: UnitKey, UnitId, Unit, etc.
      
         * GenModule: Module, InstantiatedModule and InstalledModule are now
           instances of this type
         * Generalize DefUnitId, IndefUnitId, Unit, InstantiatedUnit,
           PackageDatabase
      
      Replace BackPack fake "hole" UnitId by a proper HoleUnit constructor.
      
      Add basic support for UnitKey. They should be used more in the future to
      avoid mixing them up with UnitId as we do now.
      
      Add many comments.
      
      Update Haddock submodule
      10d15f1e