1. 15 Mar, 2019 5 commits
    • Ryan Scott's avatar
      Update Trac ticket URLs to point to GitLab · 610ec224
      Ryan Scott authored
      This moves all URL references to Trac tickets to their corresponding
      GitLab counterparts.
    • David Eichmann's avatar
    • David Eichmann's avatar
      Hadrian: remove unneeded rpaths. · 4df75772
      David Eichmann authored
      Issue #12770
    • David Eichmann's avatar
      Hadrian: remove unneeded imports. · d10e2368
      David Eichmann authored
    • Ryan Scott's avatar
      Remove the GHCi debugger's panicking isUnliftedType check · 8162eab2
      Ryan Scott authored
      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.
  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
    • Ben Gamari's avatar
      Drop utils/count_lines · 0cd98957
      Ben Gamari authored
      This doesn't appear to be used anywhere in the build system and it
      relies on perl. Drop it.
    • Ben Gamari's avatar
      Rip out perl dependency · b760269c
      Ben Gamari authored
      The object splitter was the last major user of perl. There remain a few
      uses in nofib but we can just rely on the system's perl for this since
      it's not critical to the build.
    • Sylvain Henry's avatar
      NCG: correctly escape path strings on Windows (#16389) · 6b2f0991
      Sylvain Henry authored
      GHC native code generator generates .incbin and .file directives. We
      need to escape those strings correctly on Windows (see #16389).
    • Edward Z. Yang's avatar
      Make bkpcabal01 test compatible with new ordering requirements. · 6e3e537e
      Edward Z. Yang authored
      Previously, our test did something like this:
      1. Typecheck p
      2. Typecheck q (which made use of an instantiated p)
      3. Build instantiated p
      4. Build instantiated q
      Cabal previously permitted this, under the reasoning that during
      typechecking there's no harm in using the instantiated p even if we
      haven't build it yet; we'll just instantiate it on the fly with p.
      However, this is not true!  If q makes use of a Template Haskell
      splice from p, we absolutely must have built the instantiated p
      before we typecheck q, since this typechecking will need to
      run some splices.  Cabal now complains that you haven't done
      it correctly, which we indeed have not!
      Reordering so that we do this:
      1. Typecheck p
      3. Build instantiated p
      2. Typecheck q (which made use of an instantiated p)
      4. Build instantiated q
      Fixes the problem.  If Cabal had managed the ordering itself, it would
      have gotten it right.
      Signed-off-by: Edward Z. Yang's avatarEdward Z. Yang <ezyang@fb.com>
    • Ben Gamari's avatar
      rts: Factor out large bitmap walking · e76ee675
      Ben Gamari authored
      This will be needed by the mark phase of the non-moving collector
      so let's factor it out.
    • Niklas Hambüchen's avatar
    • Niklas Hambüchen's avatar
      compiler: Write .o files atomically. See #14533 · cfbedf17
      Niklas Hambüchen authored
      This issue was reproduced with, and the fix confirmed with,
      the `hatrace` tool for syscall-based fault injection:
      The concrete test case for GHC is at
      A previous, nondeterministic reproducer for the issue was provided by
      Alexey Kuleshevich in
      Signed-off-by: default avatarNiklas Hambüchen <niklas@fpcomplete.com>
      Reviewed-by: default avatarAlexey Kuleshevich <alexey@fpcomplete.com>
    • Simon Peyton Jones's avatar
      Stop inferring over-polymorphic kinds · 1f5cc9dc
      Simon Peyton Jones authored
      Before this patch GHC was trying to be too clever
      (Trac #16344); it succeeded in kind-checking this
      polymorphic-recursive declaration
          data T ka (a::ka) b
            = MkT (T Type           Int   Bool)
                  (T (Type -> Type) Maybe Bool)
      As Note [No polymorphic recursion] discusses, the "solution" was
      horribly fragile.  So this patch deletes the key lines in
      TcHsType, and a wodge of supporting stuff in the renamer.
      There were two regressions, both the same: a closed type family
      decl like this (T12785b) does not have a CUSK:
        type family Payload (n :: Peano) (s :: HTree n x) where
          Payload Z (Point a) = a
          Payload (S n) (a `Branch` stru) = a
      To kind-check the equations we need a dependent kind for
      Payload, and we don't get that any more.  Solution: make it
      a CUSK by giving the result kind -- probably a good thing anyway.
      The other case (T12442) was very similar: a close type family
      declaration without a CUSK.
  7. 08 Mar, 2019 7 commits
    • Roland Senn's avatar
    • Sylvain Henry's avatar
      TH: support raw bytes literals (#14741) · 224a6b86
      Sylvain Henry authored
      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.
    • Simon Peyton Jones's avatar
      Use captureTopConstraints in TcRnDriver calls · 5be7ad78
      Simon Peyton Jones authored
      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.
    • Vladislav Zavialov's avatar
      Testsuite: use 'fragile' instead of 'skip' for T3424, T14697 · 82628254
      Vladislav Zavialov authored
      Also, replace some tabs with spaces to avoid a "mixed indent" warning that vim
      gives me.
    • Andrey Mokhov's avatar
      Hadrian: Drop remaining symlink traversal code from build scripts · 5d744143
      Andrey Mokhov authored
      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.
    • Alp Mestanogullari's avatar
      Hadrian: various improvements around the 'test' rule · 48927a9a
      Alp Mestanogullari authored
      - 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
    • Sebastian Graf's avatar
      Always do the worker/wrapper split for NOINLINEs · 1675d40a
      Sebastian Graf authored
      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: