1. 12 Mar, 2020 3 commits
    • Sylvain Henry's avatar
      Use a Set to represent Ways · a6989971
      Sylvain Henry authored
      Should make `member` queries faster and avoid messing up with missing
      `nubSort`.
      
      Metric Increase:
          hie002
      a6989971
    • Sylvain Henry's avatar
      Refactor interpreterDynamic and interpreterProfiled · bc41e471
      Sylvain Henry authored
      * `interpreterDynamic` and `interpreterProfiled` now take `Interp`
        parameters instead of DynFlags
      
      * slight refactoring of `ExternalInterp` so that we can read the iserv
        configuration (which is pure) without reading an MVar.
      bc41e471
    • Sylvain Henry's avatar
      Refactor GHC.Driver.Session (Ways and Flags) · 8e6febce
      Sylvain Henry authored
      * extract flags and ways into their own modules (with some renaming)
      
      * remove one SOURCE import of GHC.Driver.Session from GHC.Driver.Phases
      
      * when GHC uses dynamic linking (WayDyn), `interpWays` was only
        reporting WayDyn even if the host was profiled (WayProf).  Now it
        returns both as expected (might fix #16803).
      
      * `mkBuildTag :: [Way] -> String` wasn't reporting a canonical tag for
        differently ordered lists. Now we sort and nub the list to fix this.
      8e6febce
  2. 11 Mar, 2020 7 commits
    • Ömer Sinan Ağacan's avatar
      Zero any slop after compaction in compacting GC · 3aa9b35f
      Ömer Sinan Ağacan authored
      In copying GC, with the relevant debug flags enabled, we release the old
      blocks after a GC, and the block allocator zeroes the space before
      releasing a block. This effectively zeros the old heap.
      
      In compacting GC we reuse the blocks and previously we didn't zero the
      unused space in a compacting generation after compaction. With this
      patch we zero the slop between the free pointer and the end of the block
      when we're done with compaction and when switching to a new block
      (because the current block doesn't have enough space for the next object
      we're shifting).
      3aa9b35f
    • Simon Peyton Jones's avatar
      Deepen call stack for isIn · c61b9b02
      Simon Peyton Jones authored
      I see quite a few warnings like:
      
        WARNING: file compiler/utils/Util.hs, line 593
          Over-long elem in unionLists
      
      But the call stack is uninformative.   Better to add HasDebugCallStack
      to isIn.  Ditto isn'tIn.
      c61b9b02
    • Ben Gamari's avatar
      testsuite: Mark ghci056 and ghcilink004 as fragile in unreg · 336eac7e
      Ben Gamari authored
      As noted in #17018.
      
      Also fix fragile declaration of T13786, which only runs in the normal
      way.
      336eac7e
    • Ryan Scott's avatar
      Re-quantify when generalising over rewrite rule types · 0bc23338
      Ryan Scott authored
      Previously, `tcRules` would check for naughty quantification
      candidates (see `Note [Naughty quantification candidates]` in
      `TcMType`) when generalising over the type of a rewrite rule. This
      caused sensible-looking rewrite rules (like those in #17710) to be
      rejected. A more permissing (and easier-to-implement) approach is to
      do what is described in `Note [Generalising in tcTyFamInstEqnGuts]`
      in `TcTyClsDecls`: just re-quantify all the type variable binders,
      regardless of the order in which the user specified them. After all,
      the notion of type variable specificity has no real meaning in
      rewrite rules, since one cannot "visibly apply" a rewrite rule.
      I have written up this wisdom in
      `Note [Re-quantify type variables in rules]` in `TcRules`.
      
      As a result of this patch, compiling the `ExplicitForAllRules1` test
      case now generates one fewer warning than it used to. As far as I can
      tell, this is benign, since the thing that the disappearing warning
      talked about was also mentioned in an entirely separate warning.
      
      Fixes #17710.
      0bc23338
    • Greg Steuck's avatar
      Fixed a minor typo in codegen.rst · 1daa2029
      Greg Steuck authored
      1daa2029
    • Sylvain Henry's avatar
      Split GHC.Iface.Utils module · 20800b9a
      Sylvain Henry authored
      * GHC.Iface.Recomp: recompilation avoidance stuff
      * GHC.Iface.Make: mkIface*
      
      Moved `writeIfaceFile` into GHC.Iface.Load alongside `readIface` and
      renamed it `writeIface` for consistency.
      20800b9a
    • Ben Gamari's avatar
      rts: Prefer darwin-specific getCurrentThreadCPUTime · bb586f89
      Ben Gamari authored
      macOS Catalina now supports a non-POSIX-compliant version of clock_gettime
      which cannot use the clock_gettime codepath.
      
      Fixes #17906.
      bb586f89
  3. 10 Mar, 2020 9 commits
  4. 09 Mar, 2020 6 commits
  5. 05 Mar, 2020 4 commits
  6. 04 Mar, 2020 1 commit
  7. 02 Mar, 2020 4 commits
    • Sylvain Henry's avatar
    • Roland Senn's avatar
      Set `ImpredicativeTypes` during :print command. (#14828) · 7c0c76fb
      Roland Senn authored
      If ImpredicativeTypes is not enabled, then `:print <term>` will fail if the
      type of <term> has nested `forall`s or `=>`s.
      This is because the GHCi debugger's internals will attempt to unify a
      metavariable with the type of <term> and then display the result, but if the
      type has nested `forall`s or `=>`s, then unification will fail.
      As a result, `:print` will bail out and the unhelpful result will be
      `<term> = (_t1::t1)` (where `t1` is a metavariable).
      
      Beware: <term> can have nested `forall`s even if its definition doesn't use
      RankNTypes! Here is an example from #14828:
      
        class Functor f where
          fmap :: (a -> b) -> f a -> f b
      
      Somewhat surprisingly, `:print fmap` considers the type of fmap to have
      nested foralls. This is because the GHCi debugger sees the type
      `fmap :: forall f. Functor f => forall a b. (a -> b) -> f a -> f b`.
      We could envision deeply instantiating this type to get the type
      `forall f a b. Functor f => (a -> b) -> f a -> f b`,
      but this trick wouldn't work for higher-rank types.
      
      Instead, we adopt a simpler fix: enable `ImpredicativeTypes` when using
      `:print` and friends in the GHCi debugger. This is allows metavariables
      to unify with types that have nested (or higher-rank) `forall`s/`=>`s,
      which makes `:print fmap` display as
      `fmap = (_t1::forall a b. Functor f => (a -> b) -> f a -> f b)`, as expected.
      
      Although ImpredicativeTypes is a somewhat unpredictable from a type inference
      perspective, there is no danger in using it in the GHCi debugger, since all
      of the terms that the GHCi debugger deals with have already been typechecked.
      7c0c76fb
    • Ilias Tsitsimpis's avatar
      Do not define hs_atomic{read,write}64() on non-64bit · dbea7e9d
      Ilias Tsitsimpis authored
      Do not define hs_atomicread64() and hs_atomicwrite64() on machines where
      WORD_SIZE_IN_BITS is less than 64, just like we do with the rest of the atomic
      functions which work on 64-bit values.
      
      Without this, compilation fails on MIPSel and PowerPC with the following error:
      
      /usr/bin/ld: /<<PKGBUILDDIR>>/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3_p.a(atomic.p_o): in function `hs_atomicread64':
      atomic.c:(.text.hs_atomicread64+0x8): undefined reference to `__sync_add_and_fetch_8'
      /usr/bin/ld: /<<PKGBUILDDIR>>/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3_p.a(atomic.p_o): in function `hs_atomicwrite64':
      atomic.c:(.text.hs_atomicwrite64+0x38): undefined reference to `__sync_bool_compare_and_swap_8'
      
      Fixes #17886.
      dbea7e9d
    • Krzysztof Gogolewski's avatar
      Remove dead code · 3cf7303b
      Krzysztof Gogolewski authored
      * The names in PrelName and THNames are no longer used
        since TH merged types and kinds, Typeable is kind-polymorphic,
        .net support was removed
      * unqualQuasiQuote no longer used since 6f8ff0bb
      3cf7303b
  8. 29 Feb, 2020 6 commits
    • Roland Senn's avatar
      Show breakpoint locations of breakpoints which were ignored during :force (#2950) · 3979485b
      Roland Senn authored
      GHCi is split up into 2 major parts: The user-interface (UI)
      and the byte-code interpreter. With `-fexternal-interpreter`
      they even run in different processes. Communication between
      the UI and the Interpreter (called `iserv`) is done using
      messages over a pipe. This is called `Remote GHCI` and
      explained in the Note [Remote GHCi] in `compiler/ghci/GHCi.hs`.
      
      To process a `:force` command the UI sends a `Seq` message
      to the `iserv` process. Then `iserv` does the effective
      evaluation of the value. When during this process a breakpoint
      is hit, the `iserv` process has no additional information to
      enhance the `Ignoring breakpoint` output with the breakpoint
      location.
      
      To be able to print additional breakpoint information,
      there are 2 possible implementation choices:
      1. Store the needed information in the `iserv` process.
      2. Print the `Ignoring breakpoint` from the UI process.
      
      For option 1 we need to store the breakpoint info redundantely
      in 2 places and this is bad. Therfore option 2 was implemented
      in this MR:
      - The user enters a `force` command
      - The UI sends  a `Seq` message to the `iserv` process.
      - If processing of the `Seq` message hits a breakpoint,
        the `iserv` process returns control to the UI process.
      - The UI looks up the source location of the breakpoint,
        and prints the enhanced `Ignoring breakpoint` output.
      - The UI sends a `ResumeSeq` message to the `iserv` process,
        to continue forcing.
      3979485b
    • Ömer Sinan Ağacan's avatar
      Simplify IfaceIdInfo type · 04d30137
      Ömer Sinan Ağacan authored
      IfaceIdInfo type is confusing: there's practically no difference between
      `NoInfo` and `HasInfo []`. The comments say NoInfo is used when
      -fomit-interface-pragmas is enabled, but we don't need to distinguish
      `NoInfo` from `HasInfo []` in when reading the interface so the
      distinction is not important.
      
      This patch simplifies the type by removing NoInfo. When we have no info
      we use an empty list.
      
      With this change we no longer read the info list lazily when reading an
      IfaceInfoItem, but when reading an IfaceId the ifIdInfo field is
      read lazily, so I doubt this is going to be a problem.
      04d30137
    • Sylvain Henry's avatar
      Fix Hadrian's ``--configure`` (fix #17883) · 34c7d230
      Sylvain Henry authored
      34c7d230
    • Jean-Baptiste Mazon's avatar
    • Adam Sandberg Eriksson's avatar
    • Adam Sandberg Eriksson's avatar