1. 17 Nov, 2019 4 commits
  2. 15 Nov, 2019 6 commits
  3. 14 Nov, 2019 1 commit
  4. 13 Nov, 2019 8 commits
  5. 12 Nov, 2019 1 commit
    • Alp Mestanogullari's avatar
      testsuite: don't collect compiler stats in collect_runtime_residency · 643d42fc
      Alp Mestanogullari authored
      We instead want to collect the runtime stats (with collect_stats, instead of
      collect_compiler_stats).
      
      This should fix a number of perf tests failures we have been seeing, where
      we suddenly started measuring metrics we didn't intend to measure, which
      tend to fall outside of the acceptance window.
      
      Metric Decrease:
          lazy-bs-alloc
          T3586
      
      Metric Increase:
          space_leak_001
          T4801
          T5835
          T12791
      643d42fc
  6. 11 Nov, 2019 6 commits
  7. 10 Nov, 2019 3 commits
  8. 09 Nov, 2019 11 commits
    • Brian Wignall's avatar
      Fix incorrect plurals · 3957bdf2
      Brian Wignall authored
      3957bdf2
    • Brian Wignall's avatar
    • Brian Wignall's avatar
      1f911de4
    • Simon Peyton Jones's avatar
      Use the right type in :force · 1f98e47d
      Simon Peyton Jones authored
      A missing prime meant that we were considering the wrong
      type in the GHCi debugger, when doing :force on multiple
      arguments (issue #17431).
      
      The fix is trivial.
      1f98e47d
    • Ben Gamari's avatar
      testsuite: Mark T16219 as fragile on Windows · 011f3121
      Ben Gamari authored
      As noted in #17452, this test produces very long file paths which
      exceed the Windows MAX_PATH limitation. Mark the test as fragile for not
      until we can come up with a better solution.
      011f3121
    • Ben Gamari's avatar
      testsuite: Drop T7995 · b62ca659
      Ben Gamari authored
      This test is quite sensitive to the build configuration as it requires that ghc
      have unfoldings, which isn't true in the quick build flavours. I considered
      various options to make the test more robust but none of them seemed
      particularly appealing. Moreover, Simon PJ was a bit skeptical of the value of
      the test to begin with and I strongly suspect that any regression in #7995
      would be accompanied by failures in our other compiler performance tests.
      
      Closes #17399.
      b62ca659
    • Ben Gamari's avatar
      testsuite: Fix putStrLn in saks028 · a9b14790
      Ben Gamari authored
      Bizarrely, `saks028` previously failed reliably, but only on Windows
      (#17450). The test would exit with a zero exit code but simply didn't
      emit the expected text to stderr.
      
      I believe this was due to the fact that the test used `putStrLn`,
      resulting in the output ending up on stdout. This worked on other
      platforms since (apparently) we redirect stdout to stderr when
      evaluating splices. However, on Windows it seems that the redirected
      output wasn't flushed as it was on other platforms.
      
      Anyways, it seems like the right thing to do here is to be explicit
      about our desire for the output to end up on stderr.
      
      Closes #17450.
      a9b14790
    • Ben Gamari's avatar
      testsuite: Ignore stderr in PartialDownsweep · f73fbd2d
      Ben Gamari authored
      As described in #17449, PartialDownsweep is currently fragile due to its
      dependence on the error messages produced by the C preprocessor. To eliminate
      this dependence we simply ignore stderr output, instead relying on the fact
      that the test will exit with a non-zero exit code on failure.
      
      Fixes #17449.
      f73fbd2d
    • Ben Gamari's avatar
      testsuite: Mark T17414 as fragile on Windows · 4d523cb1
      Ben Gamari authored
      This consistently times out on Windows as described in #17453. I have tried
      increasing the timeout multiplier to two yet it stills fails. Disabling
      until we have time to investigate.
      4d523cb1
    • Ben Gamari's avatar
      testsuite: Remove redundant cleaning logic from T16511 · 1f871e70
      Ben Gamari authored
      The GHCi script for T16511 had some `rm` commands to clean up output
      from previous runs. This should be harmless since stderr was redirected
      to /dev/null; however, it seems that this redirection doesn't work on
      Windows (perhaps because GHCi uses `cmd` to execute the command-line;
      I'm not sure). I tried to fix it but was unable to find a sensible
      solution.
      
      Regardless, the cleaning logic is quite redundant now that we run each
      test in a hermetic environment. Let's just remove it.
      1f871e70
    • Ben Gamari's avatar
      testsuite: Mark T16219 as unbroken · c1f1f3f9
      Ben Gamari authored
      This was previously broken due to #16386 yet it passes for me locally.
      c1f1f3f9