Skip to content

GitLab

Glasgow Haskell Compiler
Glasgow Haskell Compiler
Switch branch/tag
  1. 16 Dec, 2016 1 commit
  3. 22 Oct, 2016 1 commit
    • Duncan Coutts's avatar
      Add and use a new dynamic-library-dirs field in the ghc-pkg info · f41a8a36
      Duncan Coutts authored 
      Summary:
Build systems / package managers want to be able to control the file
layout of installed libraries. In general they may want/need to be able
to put the static libraries and dynamic libraries in different places.
The ghc-pkg library regisrtation needs to be able to handle this.

This is already possible in principle by listing both a static lib dir
and a dynamic lib dir in the library-dirs field (indeed some previous
versions of Cabal did this for shared libs on ELF platforms).

The downside of listing both dirs is twofold. There is a lack of
precision, if we're not careful with naming then we could end up
picking up the wrong library. The more immediate problem however is
that if we list both directories then both directories get included
into the ELF and Mach-O shared object runtime search paths. On ELF this
merely slows down loading of shared libs (affecting prog startup time).
On the latest OSX versions this provokes a much more serious problem:
that there is a rather low limit on the total size of the section
containing the runtime search path (and lib names and related) and thus
listing any unnecessary directories wastes the limited space.

So the solution in this patch is fairly straightforward: split the
static and dynamic library search paths in the ghc-pkg db and its use
within ghc. This is a traditional solution: pkg-config has the same
static / dynamic split (though it describes in in terms of private and
public, but it translates into different behaviour for static and
dynamic linking).

Indeed it would make perfect sense to also have a static/dynamic split
for the list of the libraries to use i.e. to have dynamic variants of
the hs-libraries and extra-libraries fields. These are not immediately
required so this patch does not add it, but it is a reasonable
direction to follow.

To handle compatibility, if the new dynamic-library-dirs field is not
specified then its value is taken from the library-dirs field.

Contains Cabal submodule update.

Test Plan:
Run ./validate

Get christiaanb and carter to test it on OSX Sierra, in combination
with Cabal/cabal-install changes to the default file layout for
libraries.

Reviewers: carter, austin, hvr, christiaanb, bgamari

Reviewed By: christiaanb, bgamari

Subscribers: ezyang, Phyx, thomie

Differential Revision: https://phabricator.haskell.org/D2611

GHC Trac Issues: #12479
      f41a8a36
  5. 08 Oct, 2016 3 commits
  7. 30 Aug, 2016 1 commit
    • Duncan Coutts's avatar
      Fix handling of package-db entries in .ghc.environment files, etc. · ef784c55
      Duncan Coutts authored 
      Previously interpreting the content of the .ghc.env files was done
after the step that loaded the available package dbs. This meant that
setting the package db flags was ineffective. This patch moves
interpreting the env files before loading of the package dbs.

Also, the package-db entries refer to files. Allow spaces in these file
names. Also treat as comments lines beginning with "--".

These are pretty minor fixes in a feature that up 'til now has been
essentially unused (witness no bug report about it), so there's very
low risk here. If we can get this into 8.0.2 then cabal can start
generating the .ghc.environment files, otherwise it cannot as it needs
the working package-db entries, to be able to refer to local package
dbs in the build tree (or cabal nix store).

Test Plan:
Manually create example .ghc.env files
run ghci; :show packages
Done this. It works.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2476
      ef784c55
  9. 16 Jul, 2016 1 commit
  11. 06 Jun, 2016 1 commit
    • niteria's avatar
      Make UnitIdMap a deterministic map · 1937ef1c
      niteria authored 
      This impacts at least the order in which version macros are
generated. It's pretty hard to track what kind of nondeterminism
is benign and this should have no performance impact as the number
of packages should be relatively small.

Test Plan: ./validate

Reviewers: simonmar, austin, bgamari, ezyang

Reviewed By: ezyang

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2308

GHC Trac Issues: #4012
      1937ef1c
  13. 11 Mar, 2016 1 commit
  15. 05 Mar, 2016 1 commit
  17. 01 Feb, 2016 1 commit
    • Edward Z. Yang's avatar
      Simplify ghc-boot database representation with new type class. · 0d601657
      Edward Z. Yang authored 
      Previously, we had an 'OriginalModule' type in ghc-boot which
was basically identical to 'Module', and we had to do a bit of
gyrating to get it converted into the right form.  This commit
introduces a new typeclass, 'DbModuleRep' which represents types
which we know how to serialize to and from the (now renamed) 'DbModule'
type.

The upshot is that we can just store 'Module's DIRECTLY in
the 'InstalledPackageInfo', no conversion needed.

I took the opportunity to clean up ghc-pkg to make its use of
the 'BinaryStringRep' classes more type safe.
Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1811
      0d601657
  19. 18 Jan, 2016 2 commits
    • Edward Z. Yang's avatar
      Switch from -this-package-key to -this-unit-id. · 240ddd7c
      Edward Z. Yang authored 
      A small cosmetic change, but we have to do a bit of work to
actually support it:

    - Cabal submodule update, so that Cabal passes us
      -this-unit-id when we ask for it.  This includes
      a Cabal renaming to be consistent with Unit ID, which
      makes ghc-pkg a bit more scrutable.

    - Build system is updated to use -this-unit-id rather than
      -this-package-key, to avoid deprecation warnings.  Needs
      a version test so I resurrected the old test we had
      (sorry rwbarton!)

    - I've *undeprecated* -package-name, so that we are in the same
      state as GHC 7.10, since the "correct" flag will have only
      entered circulation in GHC 8.0.

    - I removed -package-key.  Since we didn't deprecate -package-id
      I think this should not cause any problems for users; they
      can just change their code to use -package-id.

    - The package database is indexed by UNIT IDs, not component IDs.
      I updated the naming here.

    - I dropped the signatures field from ExposedModule; nothing
      was using it, and instantiatedWith from the package database
      field.

    - ghc-pkg was updated to use unit ID nomenclature, I removed
      the -package-key flags but I decided not to add any new flags
      for now.
Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: 23Skidoo, thomie, erikd

Differential Revision: https://phabricator.haskell.org/D1780
      240ddd7c
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored 
      Summary:
In the past the canonical way for constructing an SDoc string literal was the
composition `ptext . sLit`.  But for some time now we have function `text` that
does the same.  Plus it has some rules that optimize its runtime behaviour.
This patch takes all uses of `ptext . sLit` in the compiler and replaces them
with calls to `text`.  The main benefits of this patch are clener (shorter) code
and less dependencies between module, because many modules now do not need to
import `FastString`.  I don't expect any performance benefits - we mostly use
SDocs to report errors and it seems there is little to be gained here.

Test Plan: ./validate

Reviewers: bgamari, austin, goldfire, hvr, alanz

Subscribers: goldfire, thomie, mpickering

Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
  21. 31 Dec, 2015 1 commit
  23. 27 Dec, 2015 1 commit
    • Edward Z. Yang's avatar
      The -package flag should select match from right-most package db. · 1b000168
      Edward Z. Yang authored 
      The shadowing and default behavior (in the absence of
-hide-all-packages) prefers packages that come from "later" package
databases.  So for example if tmp1.d and tmp2.d both expose p-1.0, then

    ghc -package-db tmp1.d -package-db tmp2.d

brings the p-1.0 from tmp2.d into scope (and if they have the same IPID,
tmp2.d shadows tmp1.d).  HOWEVER, -package flags do NOT respect this
behavior.

    ghc -package-db tmp1.d -package-db tmp2.d -package p-1.0

this will force the p-1.0 from tmp1.d to be exposed!  This is
confusing, so this patch makes the behavior of -package flags
consistent.
Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1709
      1b000168
  25. 22 Dec, 2015 2 commits
    • Edward Z. Yang's avatar
      Implement -hide-all-plugin-packages and -plugin-package(-id), fixing #11244 · 1faf1fca
      Edward Z. Yang authored 
      Summary:
The basic idea is that we have a new set of "exposed modules"
which are /only/ used for plugins, i.e. -fplugin Foo and
--frontend Foo.  You can interact with this namespace
using the flags -plugin-package-id and -plugin-package.
By default, this namespace contains all modules in the
user namespace (as before), but you can toggle that using
-hide-all-plugin-packages.

There is one nasty hack: GhcMake respects -fplugin in
GHC_OPTIONS to make local plugins work correctly.  It also
bails out of you have an import of a module which doesn't
exist locally or in the package database.  The upshot is
that we need to be sure to check in the plugin modules
too, so we don't give a spurious failure when a plugin
is in the plugin namespace but not the main namespace.
A better way to fix this would be to distinguish between
plugin and normal dependencies in ModSummary.

I cheated a little and tweaked a few existing plugins
tests to exercise the new code paths.

TODO: Documentation
Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: bgamari, austin, simonpj, duncan

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1661

GHC Trac Issues: #11244
      1faf1fca
    • Edward Z. Yang's avatar
      Refactor package flags into several distinct types. · 998739df
      Edward Z. Yang authored 
      Summary:
Previously, all package flags (-package, -trust-package,
-ignore-package) were bundled up into a single packageFlags
field in DynFlags, under a single type.  This commit separates
them based on what they do.

This is a nice improvement, because it means that Packages can
then be refactored so that a number of functions are "tighter":

    - We know longer have to partition PackageFlags into
      the ignore flag and other flags; ignore flags are just
      put into their own field.

    - Trust flags modify the package database, but exposed
      flags do not (they modify the visibility map); now
      applyPackageFlag and applyTrustFlag have tighter signatures
      which reflect this.

This patch was motivated by the need to have a separate visibility
map for plugin packages, which will be in a companion patch.
Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin, bgamari, duncan

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1659
      998739df
  27. 17 Dec, 2015 1 commit
  29. 15 Dec, 2015 1 commit
    • thomie's avatar
      DynFlags: remove Opt_Static · 6d9c18cb
      thomie authored 
      There are currently 2 different ways to test for a static or dynamic
build:

    * Test if WayDyn is in ways
    * Test if Opt_Static is set

The problem is that these can easily go out of sync, especially when
using the
GHC API.

This commit replaces all queries of Opt_Static with an equivalent query
of
WayDyn. This would have prevented bug #8294 and fixes #11154.

Reviewers: hvr, austin, bgamari

Reviewed By: austin, bgamari

Differential Revision: https://phabricator.haskell.org/D1607

GHC Trac Issues: #10636
      6d9c18cb
  31. 29 Nov, 2015 1 commit
    • quchen's avatar
      Implement warnings for Semigroups as parent of Monoid · 290def72
      quchen authored 
      This patch is similar to the AMP patch (#8004), which offered two
functions:

  1. Warn when an instance of a class has been given, but the type does
     not have a certain superclass instance
  2. Warn when top-level definitions conflict with future Prelude names

These warnings are issued as part of the new `-Wcompat` warning group.

Reviewers: hvr, ekmett, austin, bgamari

Reviewed By: hvr, ekmett, bgamari

Subscribers: ekmett, thomie

Differential Revision: https://phabricator.haskell.org/D1539

GHC Trac Issues: #11139
      290def72
  33. 30 Oct, 2015 1 commit
    • Edward Z. Yang's avatar
      Reimplement shadowing on a per database basis. · 39b71e81
      Edward Z. Yang authored 
      Summary:
This commit reimplements shadowing on package databases by doing
the shadowing calculation on a per-database basis: specifically,
if a later package database shadows a package from the earlier
databases, we first remove that package (and its transitive
dependencies) before merging the databases together.

This should also fix bootstrapping GHC HEAD with HEAD.
Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: ggreif, bgamari, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1385
      39b71e81
  35. 26 Oct, 2015 1 commit
  37. 15 Oct, 2015 3 commits
  39. 21 Sep, 2015 1 commit
  41. 23 Jul, 2015 1 commit
    • Edward Z. Yang's avatar
      Library names, with Cabal submodule update · f9687caf
      Edward Z. Yang authored 
      A library name is a package name, package version, and hash of the
version names of all textual dependencies (i.e. packages which were included.) A library
name is a coarse approximation of installed package IDs, which are suitable for
inclusion in package keys (you don't want to put an IPID in a package key, since
it means the key will change any time the source changes.)

    - We define ShPackageKey, which is the semantic object which
      is hashed into a PackageKey.  You can use 'newPackageKey'
      to hash a ShPackageKey to a PackageKey

    - Given a PackageKey, we can lookup its ShPackageKey with
      'lookupPackageKey'.  The way we can do this is by consulting
      the 'pkgKeyCache', which records a reverse mapping from
      every hash to the ShPackageKey.  This means that if you
      load in PackageKeys from external sources (e.g. interface
      files), you also need to load in a mapping of PackageKeys
      to their ShPackageKeys so we can populate the cache.

    - We define a 'LibraryName' which encapsulates the full
      depenency resolution that Cabal may have selected; this
      is opaque to GHC but can be used to distinguish different
      versions of a package.

    - Definite packages don't have an interesting PackageKey,
      so we rely on Cabal to pass them to us.

    - We can pretty-print package keys while displaying the
      instantiation, but it's not wired up to anything (e.g.
      the Outputable instance of PackageKey).
Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin, bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1056

GHC Trac Issues: #10566
      f9687caf
  43. 21 Jul, 2015 1 commit
  45. 11 Jun, 2015 1 commit
  47. 17 Apr, 2015 1 commit
  49. 08 Apr, 2015 1 commit
  51. 07 Apr, 2015 2 commits
    • Edward Z. Yang's avatar
      Support for multiple signature files in scope. · a7524eae
      Edward Z. Yang authored 
      Summary:
A common pattern when programming with signatures is to combine multiple
signatures together (signature linking).  We achieve this by making it
not-an-error to have multiple, distinct interface files for the same module
name, as long as they have the same backing implementation.  When a user
imports a module name, they get ALL matching signatures dumped into their
scope.

On the way, I refactored the module finder code, which now distinguishes
between exact finds (when you had a 'Module') and regular finds (when
you had a 'ModuleName').  I also refactored the package finder code to
use a Monoid instance on LookupResult to collect together various results.

ToDo: At the moment, if a signature is declared in the local package,
it completely overrides any remote signatures.  Eventually, we'll want
to also pull in the remote signatures (or even override the local signature,
if the full implementation is available.)  There are bunch of ToDos in the
code for what to do once this is done.

ToDo: At the moment, whenever a module name lookup occurs in GHCi and we
would have seen a signature, we instead continue and return the Module
for the backing implementation.  This is correct for most cases, but there
might be some situations where we want something a little more fine-grained
(e.g. :browse should only list identifiers which are available through
the in-scope signatures, and not ALL of them.)
Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, hvr, austin

Subscribers: carter, thomie

Differential Revision: https://phabricator.haskell.org/D790

GHC Trac Issues: #9252
      a7524eae
    • Edward Z. Yang's avatar
      Don't repeat package key with -dppr-debug when package info is missing. · cf1d9751
      Edward Z. Yang authored 
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D802
      cf1d9751
  53. 17 Mar, 2015 1 commit
  55. 07 Mar, 2015 1 commit
  57. 03 Mar, 2015 1 commit
  59. 10 Feb, 2015 1 commit
    • Duncan Coutts's avatar
      Add a workaround to allow older cabal-install to use ghc-7.10 · a1db53cc
      Duncan Coutts authored 
      Summary:
This should smooth the upgrade process for people and help with testing
the 7.10 RCs. Otherwise people need to first install cabal-install-1.22
before they can use 7.10.

The problem is that older cabal still used file-style package dbs for
the inplace package db when building packages. The workaround is that
both ghc and ghc-pkg will notice when cabal tells them to use a file
style db e.g. "dist/package.conf.inplace" and, so long as that db is
empty (ie content is []) then they'll instead us a dir style db with
the same name but ".d" appended, so in this example that would be
"dist/package.conf.inplace.d". We have to use a separate dir rather
than transparently upgrading because old Cabal really assumes the path
is a file, and if it encounters a dir it will fail.

This seems to be enough for older Cabal to work, and may well be enough
for other scripts that create dbs using "echo [] > package.conf".

Test Plan:
validate and check new and old cabal can sucessfully install things,
including packages that have internal deps (ie using the inplace db)

Reviewers: hvr, tibbe, austin

Reviewed By: tibbe, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D628
      a1db53cc
  61. 19 Jan, 2015 1 commit
    • Edward Z. Yang's avatar
      Respect package visibility when deciding wired in packages. · 1f159519
      Edward Z. Yang authored 
      Summary:
Previously, we would consider ALL versions of a wired-in package,
no matter if they were exposed or not, and pick the latest version.
This patch is a minor refinement on the behavior: now we try to
pick the wired in package from just the list of exposed packages,
and if there are no candidates fall back on the full list.  This
means that if you do:

    -hide-all-packages -package wired-in-OLD-VERSION

it will actually work by default (whereas previously you needed
to *explicitly* -ignore-package the newer version).  This is especially
useful for the 'ghc' package.  Fixes #9955.
Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin

Reviewed By: austin

Subscribers: carter, thomie

Differential Revision: https://phabricator.haskell.org/D603

GHC Trac Issues: #9955
      1f159519
  63. 16 Jan, 2015 1 commit
  65. 13 Jan, 2015 1 commit
    • Edsko de Vries's avatar
      Package environments · 099b7676
      Edsko de Vries authored 
      Summary: Package environments are files with package IDs that indicate which packages should be visible; see entry in user guide for details.

Reviewers: duncan, austin

Reviewed By: duncan, austin

Subscribers: carter, thomie

Differential Revision: https://phabricator.haskell.org/D558
      099b7676