1. 15 Mar, 2019 5 commits
    • Ryan Scott's avatar
      Update Trac ticket URLs to point to GitLab · 610ec224
      Ryan Scott authored and Marge Bot's avatar Marge Bot committed
      This moves all URL references to Trac tickets to their corresponding
      GitLab counterparts.
      610ec224
    • David Eichmann's avatar
      Git ignore .hadrian_ghci (generated by the ./hadrian/ghci.sh) · afc80730
      David Eichmann authored and Marge Bot's avatar Marge Bot committed
      [skip ci]
      afc80730
    • David Eichmann's avatar
      Hadrian: remove unneeded rpaths. · 4df75772
      David Eichmann authored and Marge Bot's avatar Marge Bot committed
      Issue #12770
      4df75772
    • David Eichmann's avatar
      Hadrian: remove unneeded imports. · d10e2368
      David Eichmann authored and Marge Bot's avatar Marge Bot committed
      d10e2368
    • Ryan Scott's avatar
      Remove the GHCi debugger's panicking isUnliftedType check · 8162eab2
      Ryan Scott authored and Marge Bot's avatar Marge Bot committed
      The GHCi debugger has never been that robust in the face of
      higher-rank types, or even types that are _interally_ higher-rank,
      such as the types of many class methods (e.g., `fmap`). In GHC 8.2,
      however, things became even worse, as the debugger would start to
      _panic_ when a user tries passing the name of a higher-rank thing
      to `:print`. This all ties back to a strange `isUnliftedType` check
      in `Debugger` that was mysteriously added 11 years ago
      (in commit 4d71f5ee) with no
      explanation whatsoever.
      
      After some experimentation, no one is quite sure what this
      `isUnliftedType` check is actually accomplishing. The test suite
      still passes if it's removed, and I am unable to observe any
      differences in debugger before even with data types that _do_ have
      fields of unlifted types (e.g., `data T = MkT Int#`). Given that
      this is actively causing problems (see #14828), the prudent thing
      to do seems to be just removing this `isUnliftedType` check, and
      waiting to see if anyone shouts about it. This patch accomplishes
      just that.
      
      Note that this patch fix the underlying issues behind #14828, as the
      debugger will still print unhelpful info if you try this:
      
      ```
      λ> f :: (forall a. a -> a) -> b -> b; f g x = g x
      λ> :print f
      f = (_t1::t1)
      ```
      
      But fixing this will require much more work, so let's start with the
      simple stuff for now.
      8162eab2
  2. 14 Mar, 2019 1 commit
  3. 13 Mar, 2019 3 commits
  4. 12 Mar, 2019 13 commits
  5. 11 Mar, 2019 3 commits
  6. 09 Mar, 2019 8 commits
  7. 08 Mar, 2019 7 commits
    • Roland Senn's avatar
      Fix #13839: GHCi warnings do not respect the default module header · 2762f94d
      Roland Senn authored and Marge Bot's avatar Marge Bot committed
      2762f94d
    • Sylvain Henry's avatar
      TH: support raw bytes literals (#14741) · 224a6b86
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      GHC represents String literals as ByteString internally for efficiency
      reasons. However, until now it wasn't possible to efficiently create
      large string literals with TH (e.g. to embed a file in a binary, cf #14741):
      TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack
      into a ByteString.
      
      This patch adds the possibility to efficiently create a "string" literal
      from raw bytes. We get the following compile times for different sizes
      of TH created literals:
      
      || Size || Before || After  || Gain ||
      || 30K  || 2.307s || 2.299  || 0%   ||
      || 3M   || 3.073s || 2.400s || 21%  ||
      || 30M  || 8.517s || 3.390s || 60%  ||
      
      Ticket #14741 can be fixed if the original code uses this new TH feature.
      224a6b86
    • Simon Peyton Jones's avatar
      Use captureTopConstraints in TcRnDriver calls · 5be7ad78
      Simon Peyton Jones authored and Marge Bot's avatar Marge Bot committed
      Trac #16376 showed the danger of failing to report an error
      that exists only in the unsolved constraints, if an exception
      is raised (via failM).
      
      Well, the commit 5c1f268e (Fail fast in solveLocalEqualities)
      did just that -- i.e. it found errors in the constraints, and
      called failM to avoid a misleading cascade.
      
      So we need to be sure to call captureTopConstraints to report
      those insolubles.  This was wrong in TcRnDriver.tcRnExpr and
      in TcRnDriver.tcRnType.
      
      As a result the error messages from test T13466 improved slightly,
      a happy outcome.
      5be7ad78
    • Vladislav Zavialov's avatar
      Testsuite: use 'fragile' instead of 'skip' for T3424, T14697 · 82628254
      Vladislav Zavialov authored and Marge Bot's avatar Marge Bot committed
      Also, replace some tabs with spaces to avoid a "mixed indent" warning that vim
      gives me.
      82628254
    • Andrey Mokhov's avatar
      Hadrian: Drop remaining symlink traversal code from build scripts · 5d744143
      Andrey Mokhov authored and Marge Bot's avatar Marge Bot committed
      This partly resolves #16325 (https://ghc.haskell.org/trac/ghc/ticket/16325).
      
      As previously discussed in https://github.com/snowleopard/hadrian/issues/667,
      we do not need the symlink traversal code in build scripts. However, it
      appears we forgot to delete this code from our Stack-based build scripts,
      which led to placing all build artefacts in an unexpected location when
      using Hadrian in combination with symlink trees. This commit fixes this.
      5d744143
    • Alp Mestanogullari's avatar
      Hadrian: various improvements around the 'test' rule · 48927a9a
      Alp Mestanogullari authored and Marge Bot's avatar Marge Bot committed
      - introduce a -k/--keep-test-files flag to prevent cleanup
      - add -dstg-lint to the options that are always passed to tests
      - infer library ways from the compiler to be tested instead of getting them
        from the flavour (like make)
      - likewise for figuring out whether the compiler to be tested is "debugged"
      - specify config.exeext
      - correctly specify config.in_tree_compiler, instead of always passing True
      - fix formatting of how we pass a few test options
      - add (potential) extensions to check-* program names
      - build check-* programs with the compiler to be tested
      - set TEST_HC_OPTS_INTERACTIVE and PYTHON env vars when running tests
      48927a9a
    • Sebastian Graf's avatar
      Always do the worker/wrapper split for NOINLINEs · 1675d40a
      Sebastian Graf authored and Marge Bot's avatar Marge Bot committed
      Trac #10069 revealed that small NOINLINE functions didn't get split
      into worker and wrapper. This was due to `certainlyWillInline`
      saying that any unfoldings with a guidance of `UnfWhen` inline
      unconditionally. That isn't the case for NOINLINE functions, so we
      catch this case earlier now.
      
      Nofib results:
      
      --------------------------------------------------------------------------------
              Program         Allocs    Instrs
      --------------------------------------------------------------------------------
       fannkuch-redux          -0.3%      0.0%
                   gg          +0.0%     +0.1%
             maillist          -0.2%     -0.2%
              minimax           0.0%     -0.8%
      --------------------------------------------------------------------------------
                  Min          -0.3%     -0.8%
                  Max          +0.0%     +0.1%
       Geometric Mean          -0.0%     -0.0%
      
      Fixes #10069.
      
      -------------------------
      Metric Increase:
          T9233
      -------------------------
      1675d40a