1. 22 Nov, 2018 4 commits
    • Sylvain Henry's avatar
      Rename literal constructors · 13bb4bf4
      Sylvain Henry authored and Ben Gamari's avatar Ben Gamari committed
      In a previous patch we replaced some built-in literal constructors
      (MachInt, MachWord, etc.) with a single LitNumber constructor.
      
      In this patch we replace the `Mach` prefix of the remaining constructors
      with `Lit` for consistency (e.g., LitChar, LitLabel, etc.).
      
      Sadly the name `LitString` was already taken for a kind of FastString
      and it would become misleading to have both `LitStr` (literal
      constructor renamed after `MachStr`) and `LitString` (FastString
      variant). Hence this patch renames the FastString variant `PtrString`
      (which is more accurate) and the literal string constructor now uses the
      least surprising `LitString` name.
      
      Both `Literal` and `LitString/PtrString` have recently seen breaking
      changes so doing this kind of renaming now shouldn't harm much.
      
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers
      
      Subscribers: tdammers, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4881
      13bb4bf4
    • Ben Gamari's avatar
      users guide: We no longer build libraries with -split-objs · f5fbecc8
      Ben Gamari authored
      We now generally use split-sections instead.
      f5fbecc8
    • Gabor Greif's avatar
      Minor performance optimisation · 8707911a
      Gabor Greif authored
      only concat once
      8707911a
    • Gabor Greif's avatar
      another minor refactoring · 4343d5af
      Gabor Greif authored
      4343d5af
  2. 21 Nov, 2018 1 commit
    • Ömer Sinan Ağacan's avatar
      Fix heap corruption during stable name allocation · 691aa715
      Ömer Sinan Ağacan authored
      See #15906 for the problem. To fix we simply call `allocate()` instead of
      `ALLOC_PRIM()`. `allocate()` does not trigger GC when the nursery is full,
      instead it extends it.
      
      Test Plan:
      This validates. memo001 now passes with `-debug` compile parameter. I'll add
      another test that runs memo001 with `-debug` once I figure out how to use
      stdout files for multiple tests.
      
      Reviewers: simonmar, bgamari, erikd
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15906
      
      Differential Revision: https://phabricator.haskell.org/D5342
      691aa715
  3. 20 Nov, 2018 1 commit
  4. 19 Nov, 2018 4 commits
    • Sebastian Graf's avatar
      Don't track free variables in STG syntax by default · 47bbc709
      Sebastian Graf authored
      Summary:
      Currently, `CoreToStg` annotates `StgRhsClosure`s with their set of non-global
      free variables.  This free variable information is only needed in the final
      code generation step (i.e. `StgCmm.codeGen`), which leads to transformations
      such as `StgCse` and `StgUnarise` having to maintain this information.
      
      This is tiresome and unnecessary, so this patch introduces a trees-to-grow-like
      approach that only introduces the free variable set into the syntax tree in the
      code gen pass, along with a free variable analysis on STG terms to generate
      that information.
      
      Fixes #15754.
      
      Reviewers: simonpj, osa1, bgamari, simonmar
      
      Reviewed By: osa1
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15754
      
      Differential Revision: https://phabricator.haskell.org/D5324
      47bbc709
    • Alp Mestanogullari's avatar
      hadrian: make it possible to run the testsuite with quickest and quick · cc615c69
      Alp Mestanogullari authored
      More generally, we so far assumed that the testsuite would be executed
      with a flavour that's as comprehensive as perf in terms of available RTS
      and library flavours (at least vanilla + dynamic + prof). This would
      manifest itself concretely by needing 3 "ways" of the iserv program,
      unconditionally.
      
      We now only require the ways among vanilla, dynamic and prof that we
      can find in our current Flavour's rtsWays.
      
      Test Plan:
      hadrian/build.sh --flavour={quick, quickest} test now goes through
      (with a few failing tests, of course).
      
      Reviewers: bgamari, tdammers
      
      Reviewed By: tdammers
      
      Subscribers: mpickering, RyanGlScott, rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5355
      cc615c69
    • Matthew Pickering's avatar
      eventlog: Log the current stack size when stack overflows · 7e570676
      Matthew Pickering authored
      Reviewers: maoe, bgamari, erikd, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, carter, sjorn3
      
      Differential Revision: https://phabricator.haskell.org/D5287
      7e570676
    • Ömer Sinan Ağacan's avatar
      Tiny refactor in exitScheduler · 348ea161
      Ömer Sinan Ağacan authored
      348ea161
  5. 18 Nov, 2018 1 commit
  6. 17 Nov, 2018 14 commits
  7. 16 Nov, 2018 3 commits
  8. 15 Nov, 2018 4 commits
    • Simon Peyton Jones's avatar
      Smarter HsType pretty-print for promoted datacons · ae2c9b40
      Simon Peyton Jones authored
      Fix Trac #15898, by being smarter about when to print
      a space before a promoted data constructor, in a HsType.
      I had to implement a mildly tiresome function
          HsType.lhsTypeHasLeadingPromotionQuote
      It has multiple cases, of course, but it's very simple.
      
      The patch improves the error-message output in a bunch of
      cases, and (to my surprise) actually fixes a bug in the
      output of T14343 (Trac #14343), thus
      
        -  In the expression: _ :: Proxy '('( 'True,  'False),  'False)
        +  In the expression: _ :: Proxy '( '( 'True, 'False), 'False)
      
      I discovered that there were two copies of the PromotionFlag
      type (a boolean, with helpfully named data cons), one in
      IfaceType and one in HsType.  So I combined into one,
      PromotionFlag, and moved it to BasicTypes.  That's why
      quite a few files are touched, but it's all routine.
      ae2c9b40
    • Simon Peyton Jones's avatar
      0ce66be9
    • Simon Peyton Jones's avatar
      Comments only, about polykinded TyConApps · fe057642
      Simon Peyton Jones authored
      See Trac #15704 comment:8ff
      fe057642
    • Simon Marlow's avatar
      Fix a bug in SRT generation (#15892) · eb46345d
      Simon Marlow authored and Ömer Sinan Ağacan's avatar Ömer Sinan Ağacan committed
      Summary:
      The logic in `Note [recursive SRTs]` was correct. However, my
      implementation of it wasn't: I got the associativity of
      `Set.difference` wrong, which led to an extremely subtle and difficult
      to find bug.
      
      Fortunately now we have a test case. I was able to cut down the code
      to something manageable, and I've added it to the test suite.
      
      Test Plan:
      Before (using my stage 1 compiler without the fix):
      
      ```
      ====> T15892(normal) 1 of 1 [0, 0, 0]
      cd "T15892.run" &&  "/home/smarlow/ghc/inplace/bin/ghc-stage1" -o T15892
      T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
      -fno-warn-missed-specialisations -fshow-warning-groups
      -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat
      -dno-debug-output  -O
      cd "T15892.run" && ./T15892  +RTS -G1 -A32k -RTS
      Wrong exit code for T15892(normal)(expected 0 , actual 134 )
      Stderr ( T15892 ):
      T15892: internal error: evacuate: strange closure type 0
          (GHC version 8.7.20181113 for x86_64_unknown_linux)
          Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
      Aborted (core dumped)
      *** unexpected failure for T15892(normal)
      =====> T15892(g1) 1 of 1 [0, 1, 0]
      cd "T15892.run" &&  "/home/smarlow/ghc/inplace/bin/ghc-stage1" -o T15892
      T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
      -fno-warn-missed-specialisations -fshow-warning-groups
      -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat
      -dno-debug-output  -O
      cd "T15892.run" && ./T15892 +RTS -G1 -RTS +RTS -G1 -A32k -RTS
      Wrong exit code for T15892(g1)(expected 0 , actual 134 )
      Stderr ( T15892 ):
      T15892: internal error: evacuate: strange closure type 0
          (GHC version 8.7.20181113 for x86_64_unknown_linux)
          Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
      Aborted (core dumped)
      ```
      
      After (using my stage 2 compiler with the fix):
      
      ```
      =====> T15892(normal) 1 of 1 [0, 0, 0]
      cd "T15892.run" &&  "/home/smarlow/ghc/inplace/test   spaces/ghc-stage2"
      -o T15892 T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
      -fno-warn-missed-specialisations -fshow-warning-groups
      -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat
      -dno-debug-output
      cd "T15892.run" && ./T15892  +RTS -G1 -A32k -RTS
      =====> T15892(g1) 1 of 1 [0, 0, 0]
      cd "T15892.run" &&  "/home/smarlow/ghc/inplace/test   spaces/ghc-stage2"
      -o T15892 T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
      -fno-warn-missed-specialisations -fshow-warning-groups
      -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat
      -dno-debug-output
      cd "T15892.run" && ./T15892 +RTS -G1 -RTS +RTS -G1 -A32k -RTS
      ```
      
      Reviewers: bgamari, osa1, erikd
      
      Reviewed By: osa1
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15892
      
      Differential Revision: https://phabricator.haskell.org/D5334
      eb46345d
  9. 14 Nov, 2018 1 commit
  10. 13 Nov, 2018 1 commit
    • Sebastian Graf's avatar
      Make `UniqDSet` a newtype · 5b98a38a
      Sebastian Graf authored
      Summary:
      This brings the situation of `UniqDSet` in line with `UniqSet`.
      
      @dfeuer said in D3146#92820 that he would do this, but probably
      never got around to it.
      
      Validated locally.
      
      Reviewers: AndreasK, mpickering, bgamari, dfeuer, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, carter, dfeuer
      
      GHC Trac Issues: #15879, #13114
      
      Differential Revision: https://phabricator.haskell.org/D5313
      5b98a38a
  11. 12 Nov, 2018 5 commits
    • Ben Gamari's avatar
    • Shao Cheng's avatar
      Correct link to GHC API in docs index. · 89bf7d54
      Shao Cheng authored and Ben Gamari's avatar Ben Gamari committed
      89bf7d54
    • Alp Mestanogullari's avatar
      compareByPreference: handle the integer-gmp vs -simple case · 86ee74dc
      Alp Mestanogullari authored
      Currently, it assumes the package names are identical and this
      breaks in the case where integer-gmp is in one package db and
      integer-simple in another. This became a problem with
      the commit: fc2ff6dd.
      
      Instead of following the precedence information, leading to
      the right choice, the current code would compare the
      integer-gmp and integer-simple versions and pick integer-gmp
      because it happened to have a greater version, despite having
      a lower precedence. See
      https://github.com/snowleopard/hadrian/issues/702 for
      a comprehensive report about the problem.
      
      This effectively un-breaks integer-simple builds with hadrian.
      
      Test Plan: hadrian/build.sh --integer-simple
      
      Reviewers: snowleopard, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: snowleopard, rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5266
      86ee74dc
    • Ömer Sinan Ağacan's avatar
      Remove StgBinderInfo and related computation in CoreToStg · d30352ad
      Ömer Sinan Ağacan authored
      - The StgBinderInfo type was never used in the code gen, so the type, related
        computation in CoreToStg, and some comments about it are removed. See #15770
        for more details.
      
      - Simplified CoreToStg after removing the StgBinderInfo computation: removed
        StgBinderInfo arguments and mfix stuff.
      
      The StgBinderInfo values were not used in the code gen, but I still run nofib
      just to make sure: 0.0% change in allocations and binary sizes.
      
      Test Plan: Validated locally
      
      Reviewers: simonpj, simonmar, bgamari, sgraf
      
      Reviewed By: sgraf
      
      Subscribers: AndreasK, sgraf, rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5232
      d30352ad
    • Edward Z. Yang's avatar
      Fix #15594 (--abi-hash with Backpack sometimes fails) · 13ff0b7c
      Edward Z. Yang authored
      Summary:
      For holes, its necessary to "see through" the instantiation
      of the hole to get accurate family instance dependencies.
      For example, if B imports <A>, and <A> is instantiated with
      F, we must grab and include all of the dep_finsts from
      F to have an accurate transitive dep_finsts list.
      
      However, we MUST NOT do this for regular modules.
      First, for efficiency reasons, doing this
      bloats the the dep_finsts list, because we *already* had
      those modules in the list (it wasn't a hole module, after
      all). But there's a second, more important correctness
      consideration: we perform module renaming when running
      --abi-hash.  In this case, GHC's contract to the user is that
      it will NOT go and read out interfaces of any dependencies
      (https://github.com/haskell/cabal/issues/3633);
      
       the point of
      --abi-hash is just to get a hash of the on-disk interfaces
      for this *specific* package.  If we go off and tug on the
      interface for /everything/ in dep_finsts, we're gonna have a
      bad time.  (It's safe to do do this for hole modules, though,
      because the hmap for --abi-hash is always trivial, so the
      interface we request is local.  Though, maybe we ought
      not to do it in this case either...)
      Signed-off-by: Edward Z. Yang's avatarEdward Z. Yang <ezyang@fb.com>
      
      Test Plan: validate
      
      Reviewers: alexbiehl, goldfire, bgamari
      
      Subscribers: ppk, shlevy, rwbarton, carter
      
      GHC Trac Issues: #15594
      
      Differential Revision: https://phabricator.haskell.org/D5123
      13ff0b7c
  12. 11 Nov, 2018 1 commit