GitLab

in the previous patches in this series

Since ghc-pkg needs a relatively recent version.

The ghc-pkg program of course still depends on Cabal, it's just the
bin-package-db library (shared between ghc and ghc-pkg) that does not.

Also start using the new package db file format properly, by using the
ghc-specific section.

This is the main patch in the series for removing the compiler's dep
on the Cabal lib.

The purpose of the new format is to make it possible for the compiler
to not depend on the Cabal library. The new cache file format contains
more or less the same information duplicated in two different sections
using different representations.

One section is basically the same as what the package db contains now,
a list of packages using the types defined in the Cabal library. This
section is read back by ghc-pkg, and used for things like ghc-pkg dump
which have to produce output using the Cabal InstalledPackageInfo text
representation.

The other section is a ghc-local type which contains a subset of the
information from the Cabal InstalledPackageInfo -- just the bits that
the compiler cares about.

The trick is that the compiler can read this second section without
needing to know the representation (or types) of the first part. The
ghc-pkg tool knows about both representations and writes both.

This patch introduces the new cache file format but does not yet use it
properly. More patches to follow. (As of this patch, the compiler reads
the part intended for ghc-pkg so it still depends on Cabal and the
ghc-local package type is not yet fully defined.)

In particular, report when it's missing, and also report it for ghc-pkg check.
Also make the warning message more explicit, that ghc will not be able to
read these dbs, even though ghc-pkg may be able to.

Historically the package db format was a single text file in Read/Show
format containing [InstalledPackageInfo]. For several years now the
default format has been a directory with one file per package, plus a
binary cache.

The old format cannot be supported under the new scheme where the
compiler will not depend on the Cabal library (because it will not
have access to the InstalledPackageInfo type) so we must drop support.
It would still technically be possible to support a single text file
style db (but containing a different type), but there does not seem to
be any compelling reason to do so.

(Part of preparitory work for removing the compiler's dep on Cabal)

We can serialise directly, without having to convert some fields to
string first.

(Part of preparitory work for removing the compiler's dep on Cabal)

This was previously happening by a fluke -- they were called with those types
in GHC.Real itself -- but my recent changes to specialisation mean that auto
specialisations like these are not necessarily exported.

Losing those specialisations made a huge difference to two performance tests
   perf/should_run/MethSharing
   perf/should_run/T9339

Call sites are much easier to understand than before

I hadn't got the new function trimAutoRules quite right, so we had
a left-over rule which mentioned a local variable whose binding had
been discarded.  (Result: crash when compiling Haddock.)

This patch merges trimAutoRules into an expanded version of
findExternalRules, gets it right, and adds lots of comments.

See Note [Finding external rules].

And indeed in one regression test we get to trim off more rules
(and hence code) than before.

No need to emit (now empty) those special markers.
Markers were needed only in registerised -fvia-C mode.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Signed-off-by: Austin Seipp <austin@well-typed.com>

Signed-off-by: Austin Seipp <austin@well-typed.com>

   ghc-stage2: panic! (the 'impossible' happened)
     (GHC version 7.9.20140828 for x86_64-unknown-linux):
   	nameModule $w$smiddle_sfx6

   make[1]: *** [utils/haddock/dist/build/Haddock/Backends/Xhtml.dyn_o] Error 1

Due to Stephanie Weirich, Dan Licata, John Hughes, Matt Might

'-rdynamic' is currently only a link-time option.
Does not make sense for ghci without major changes.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Known Issue #7297Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

More modular, less code.  No change in behaviour.

* T1969 improves, perhaps because of better specialiation

* T5642 (a bizarre case) worsens, because we get lots and lots
  of specialisations of imported functions for the lots and
  lots of data types T5642 declares

Doing so pushes bindings nearer their use site and hence makes
them more likely to be strict. These bindings might only show
up after the inlining from simplification.  Example in fulsom,
Csg.calc, where an arg of timesDouble thereby becomes strict.

Very few programs are affected, but it's basically good news.

        Program           Size    Allocs   Runtime   Elapsed  TotalMem
--------------------------------------------------------------------------------
            fft          -0.2%     +1.3%      0.06      0.06    -10.0%
         fulsom          -0.0%     -2.6%     -4.3%     -4.7%     -6.7%
         simple          +0.0%     -0.8%      0.0%      0.0%      0.0%
--------------------------------------------------------------------------------
            Min          -0.5%     -2.6%     -4.5%     -4.7%    -10.0%
            Max          +0.1%     +1.3%     +3.3%     +3.4%     +2.6%
 Geometric Mean          -0.0%     -0.0%     -0.6%     -0.6%     -0.2%

The lossage in fft is the loss of detecting a common sub-expression,
and can be fixed by doing earlier CSE.  But that is in any case a bit
of a fluke so I don't mind losing it in exchange for this more reliable
gain.

The new function TidyPgm.trimAutoRules discards bindings and
rules that were useful, but now have served their purpose.

See Note [Trimming auto rules] in TidyPgm

We were missing the free variables of rules etc.  It's correct
for Rec but wrong for NonRec.  I'm not sure how this bug hasn't
bitten us before, but it cropped up when I was doing trimAutoRules.

This flag specialises any imported overloaded function that has an
unfolding, whether or not it was marked INLINEABLE.

We get a lot of orphan SPEC rules as a result, but that doesn't matter
provided we don't treat orphan auto-generated rules as causing the module
itself to be an orphan module.  See Note [Orphans and auto-generated rules]
in MkIface.