1. 24 Dec, 2019 3 commits
    • Ömer Sinan Ağacan's avatar
      Post-rebase fixups · 3187bb1d
      Ömer Sinan Ağacan authored
    • Ömer Sinan Ağacan's avatar
      Move mkModDetails calls to mkIface call sites · 212e513a
      Ömer Sinan Ağacan authored
      This makes it explicit that there's only one way to make a ModDetails
    • Ömer Sinan Ağacan's avatar
      Generate ModDetails with ModIface, with info from backend · 39659edc
      Ömer Sinan Ağacan authored
      This is a continuation of the previous work (f3cb8c7c) where we moved
      ModIface generation after code generation (after Cmm transformations are
      done, before final code generation). This allowed updating interface
      files with the code gen info. The information would then be available to
      importing modules.
      However because it didn't update ModDetails (used by batch mode) the
      information was only available to importing modules in one-shot mode (an
      With this patch we generate ModIface and ModDetails at the same place,
      allowing updating/generating both with the code gen info.
      This is the final blocker for !1304. I've confirmed by rebasing !1304 on
      top of this branch that this works as expected and fixes the remaining
      issues with !1304.
      This reverts some of the changes in f3cb8c7c as they're no longer needed.
      Specifically PartialModIface stuff is now gone; we keep the parts we
      need in ModGuts for ModDetails and ModIface generation in the new type
      CgModGuts. CgModGuts is basically ModGuts but lacking
      - mg_loc :: SrcSpan
      - mg_rules :: [CoreRule]
      - mg_binds :: CoreProgram
      - mg_foreign :: ForeignStubs
      - mg_foreign_files :: [(ForeignSrcLang, FilePath)]
      - mg_modBreaks :: Maybe ModBreaks
      - mg_inst_env :: InstEnv
      - mg_fam_inst_env :: FamInstEnv
      mg_binds part is especially important to keep the residency low.
  2. 20 Dec, 2019 2 commits
  3. 19 Dec, 2019 2 commits
    • Sylvain Henry's avatar
      Handle large ARR_WORDS in heap census (fix #17572) · 0c114c65
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      We can do a heap census with a non-profiling RTS. With a non-profiling
      RTS we don't zero superfluous bytes of shrunk arrays hence a need to
      handle the case specifically to avoid a crash.
      Revert part of a586b33f
    • Moritz Kiefer's avatar
      Avoid race condition in hDuplicateTo · fad866e0
      Moritz Kiefer authored and Marge Bot's avatar Marge Bot committed
      In our codebase we have some code along the lines of
      newStdout <- hDuplicate stdout
      stderr `hDuplicateTo` stdout
      to avoid stray `putStrLn`s from corrupting a protocol (LSP) that is
      run over stdout.
      On CI we have seen a bunch of issues where `dup2` returned `EBUSY` so
      this fails with `ResourceExhausted` in Haskell.
      I’ve spent some time looking at the docs for `dup2` and the code in
      `base` and afaict the following race condition is being triggered
      1. The user calls `hDuplicateTo stderr stdout`.
      2. `hDuplicateTo` calls `hClose_help stdout_`, this closes the file
      handle for stdout.
      3. The file handle for stdout is now free, so another thread
      allocating a file might get stdout.
      4. If `dup2` is called while `stdout` (now pointing to something
      else) is half-open, it returns EBUSY.
      I think there might actually be an even worse case where `dup2` is run
      after FD 1 is fully open again. In that case, you will end up not just
      redirecting the original stdout to stderr but also the whatever
      resulted in that file handle being allocated.
      As far as I can tell, `dup2` takes care of closing the file handle
      itself so there is no reason to do this in `hDuplicateTo`. So this PR
      replaces the call to `hClose_help` by the only part of `hClose_help`
      that we actually care about, namely, `flushWriteBuffer`.
      I tested this on our codebase fairly extensively and haven’t been able
      to reproduce the issue with this patch.
  4. 18 Dec, 2019 1 commit
    • Sylvain Henry's avatar
      Add GHC-API logging hooks · 58655b9d
      Sylvain Henry authored
      * Add 'dumpAction' hook to DynFlags.
      It allows GHC API users to catch dumped intermediate codes and
      information. The format of the dump (Core, Stg, raw text, etc.) is now
      reported allowing easier automatic handling.
      * Add 'traceAction' hook to DynFlags.
      Some dumps go through the trace mechanism (for instance unfoldings that
      have been considered for inlining). This is problematic because:
      1) dumps aren't written into files even with -ddump-to-file on
      2) dumps are written on stdout even with GHC API
      3) in this specific case, dumping depends on unsafe globally stored
      DynFlags which is bad for GHC API users
      We introduce 'traceAction' hook which allows GHC API to catch those
      traces and to avoid using globally stored DynFlags.
      * Avoid dumping empty logs via dumpAction/traceAction (but still write
      empty files to keep the existing behavior)
  5. 17 Dec, 2019 23 commits
  6. 16 Dec, 2019 2 commits
  7. 12 Dec, 2019 5 commits
  8. 11 Dec, 2019 2 commits
    • Richard Eisenberg's avatar
      Warn on inferred polymorphic recursion · 2d1b9619
      Richard Eisenberg authored and Marge Bot's avatar Marge Bot committed
      Silly users sometimes try to use visible dependent quantification
      and polymorphic recursion without a CUSK or SAK. This causes
      unexpected errors. So we now adjust expectations with a bit
      of helpful messaging.
      Closes #17541 and closes #17131.
      test cases: dependent/should_fail/T{17541{,b},17131}
    • Crazycolorz5's avatar
      rts: Specialize hashing at call site rather than in struct. · f80c4a66
      Crazycolorz5 authored and Marge Bot's avatar Marge Bot committed
      Separate word and string hash tables on the type level, and do not store
      the hashing function.  Thus when a different hash function is desire it
      is provided upon accessing the table. This is worst case the same as
      before the change, and in the majority of cases is better. Also mark the
      functions for aggressive inlining to improve performance.  {F1686506}
      Reviewers: bgamari, erikd, simonmar
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #13165
      Differential Revision: https://phabricator.haskell.org/D4889