1. 24 Sep, 2014 1 commit
    • Edward Z. Yang's avatar
      Update Cabal submodule & ghc-pkg to use new module re-export types · 4b648be1
      Edward Z. Yang authored
      Summary:
      The main change is that Cabal changed the representation of module
      re-exports to distinguish reexports in source .cabal files versus
      re-exports in installed package registraion files.
      
      Cabal now also does the resolution of re-exports to specific installed
      packages itself, so ghc-pkg no longer has to do this. This is a cleaner
      design overall because re-export resolution can fail so it is better to
      do it during package configuration rather than package registration.
      It also simplifies the re-export representation that ghc-pkg has to use.
      
      Add extra ghc-pkg sanity check for module re-exports and duplicates
      
      For re-exports, check that the defining package exists and that it
      exposes the defining module (or for self-rexport exposed or hidden
      modules). Also check that the defining package is actually a direct
      or indirect dependency of the package doing the re-exporting.
      
      Also add a check for duplicate modules in a package, including
      re-exported modules.
      
      Test Plan:
      So far the sanity checks are totally untested. Should add some test
      case to make sure the sanity checks do catch things correctly, and
      don't ban legal things.
      
      Reviewers: austin, duncan
      
      Subscribers: angerman, simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D183
      
      GHC Trac Issues:
      4b648be1
  2. 21 Sep, 2014 1 commit
  3. 15 Sep, 2014 1 commit
  4. 09 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored
      Summary:
      This includes pretty much all the changes needed to make `Applicative`
      a superclass of `Monad` finally. There's mostly reshuffling in the
      interests of avoid orphans and boot files, but luckily we can resolve
      all of them, pretty much. The only catch was that
      Alternative/MonadPlus also had to go into Prelude to avoid this.
      
      As a result, we must update the hsc2hs and haddock submodules.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan: Build things, they might not explode horribly.
      
      Reviewers: hvr, simonmar
      
      Subscribers: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D13
      d94de872
  5. 29 Aug, 2014 8 commits
    • Duncan Coutts's avatar
      616dd87f
    • Duncan Coutts's avatar
      Switch the package id types to use FastString (rather than String) · c72efd7c
      Duncan Coutts authored
      The conversions should now be correct w.r.t Unicode.
      
      Also move a couple instances to avoid orphan instances.
      
      Strictly speaking there's no need for these types to use FastString as
      they do not need the unique feature. They could just use some other
      compact string type, but ghc's internal utils don't have much support
      for such a type, so we just use FastString.
      c72efd7c
    • Duncan Coutts's avatar
      Add a ghc -show-packages mode to display ghc's view of the package env · a4cb9a61
      Duncan Coutts authored
      You can use ghc -show-packages, in addition to any -package -package-conf
      -hide-package, etc flags and see just what ghc's package info looks like.
      The format is much like ghc-pkg show.
      
      Like the existing verbose tracing, but a specific mode.
      Re-introduce pretty printed package info (Cabal handled this previously).
      a4cb9a61
    • Duncan Coutts's avatar
      Remove a TODO that is now done · 8955b5ee
      Duncan Coutts authored
      8955b5ee
    • Duncan Coutts's avatar
      Fix long lines and trailing whitespace · 29f84d30
      Duncan Coutts authored
      in the previous patches in this series
      29f84d30
    • Duncan Coutts's avatar
      Use ghc-local types for packages, rather than Cabal types · 27d6c089
      Duncan Coutts authored
      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.
      27d6c089
    • Duncan Coutts's avatar
      Introduce new file format for the package database binary cache · 8d7a1dcd
      Duncan Coutts authored
      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.)
      8d7a1dcd
    • Duncan Coutts's avatar
      Drop support for single-file style package databases · 557c8b8c
      Duncan Coutts authored
      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)
      557c8b8c
  6. 22 Aug, 2014 1 commit
    • Edward Z. Yang's avatar
      Do not zero out version number when processing wired-in packages. · 22520cd7
      Edward Z. Yang authored
      Summary:
      Previously, GHC would look for instances of wired-in packages in the
      in-memory package database and null out the version number.  This was
      necessary when the sourcePackageId was used to determine the linker
      symbols; however, we now use a package key, so only that needs to be
      updated.
      
      Long-term, we can remove this hack by ensuring that Cabal actually records
      the proper package key in the database.  This will also fix an unrelated
      hack elsewhere.
      
      Keeping version numbers means that wired in packages get rendered differently
      when output by GHC.  This is the source of all the test-case output changes.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: hvr, austin
      
      Subscribers: simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D170
      22520cd7
  7. 05 Aug, 2014 5 commits
    • Edward Z. Yang's avatar
      Thinning and renaming modules from packages on the command line. · 20787529
      Edward Z. Yang authored
      Summary:
      This patch set adds support for extra syntax on -package and related
      arguments which allow you to thin and rename modules from a package.
      For example, this argument:
      
          -package "base (Data.Bool as Bam, Data.List)"
      
      adds two more modules into scope, Bam and Data.List, without adding
      any of base's other modules to scope.
      
      These flags are additive: so, for example, saying:
      
          -hide-all-packages -package base -package "base (Data.Bool as Bam)"
      
      will provide both the normal bindings for modules in base, as well as
      the module Bam.
      
      There is also a new debug flag -ddump-mod-map which prints the state
      of the module mapping database.  H = hidden, E = exposed (so for
      example EH says the module in question is exported, but in a hidden
      package.)
      
      Module suggestions have been minorly overhauled to work better with reexports:
      if you have -package "base (Data.Bool as Bam)" and mispell Bam, GHC
      will suggest "Did you mean Bam (defined via package flags to be
      base:Data.Bool)"; and generally you will get more accurate information.
      Also, fix a bug where we suggest the -package flag when we really need
      the -package-key flag.
      
      NB: The renaming afforded here does *not* affect what wired in
      symbols GHC generates.  (But it does affect implicit prelude!)
      
      ToDo: add 'hiding' functionality, to make it easier to support the alternative
      prelude use-case.
      
      ToDo: Cabal support
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: new tests and validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D113
      
      GHC Trac Issues: #9375
      20787529
    • Edward Z. Yang's avatar
      Refactor PackageFlags so that ExposePackage is a single constructor. · 4accf601
      Edward Z. Yang authored
      You can parametrize over the different selection by using a
      different PackageArg.  This helps reduce code duplication.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      4accf601
    • Edward Z. Yang's avatar
      Refactor package state, also fixing a module reexport bug. · 00b8f8c5
      Edward Z. Yang authored
      Instead of building a multiply indirected data structure and querying
      it on every import, we now have two data structures moduleToPkgConf
      and moduleToPkgConfAll.  moduleToPkgConf is a single-level UniqFM that
      is intended to be used for most valid imports; however, it does not
      contain any information useful for error reporting.  If an error is
      occurred, we then query moduleToPkgConfAll, which contains a more
      comprehensive view of the package database.  This field is lazily
      initialized (so this means we're retaining the package database list,
      but this should be fine because we're already maintaining the entries
      of the list.)  Additionally, the full view doesn't keep track of a boolean
      toggle for visibility/exposure anymore, but instead tracks the *provenance*
      of how the module binding came to be (the ModuleOrigin data type).
      
      Additionally, we move the logic for determining if a module is exposed
      or not from Finder.lhs and put it in Packages.lhs; this information is
      communicated via the LookupResult data type.  Unfortunately, we can't
      directly return a FindResult, because this data type is defined in
      HscTypes which depends on Packages.  This is going to change some more
      in the near future when I add thinning/renaming to package flags; the
      error messages will need to be more flexible.
      
      I've also slightly changed the semantics of error messages for package
      qualified imports.  Previously, if we didn't find any package qualified
      imports, but there were hidden modules in a *different* package, the error
      message would prefer mentioning those as opposed to providing suggestions.
      Now, if a module is hidden but in the wrong package, we won't mention it;
      instead, it will get mentioned with the other module suggestions.  I
      was too lazy to write a test, but I can add one if people would like.
      
      The module reexport bug was, package q reexported p:P as Conflict,
      and package r reexported p:P2 as Conflict, this was *not* reported as
      a conflict, because the old logic incorrectly decided that P and P2 were
      the same module on account of being from the same package.  The logic here
      has been corrected.
      
      Contains haddock submodule update.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      00b8f8c5
    • Edward Z. Yang's avatar
      Make PackageState an abstract type. · de3f0644
      Edward Z. Yang authored
      Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D107
      de3f0644
    • Edward Z. Yang's avatar
      Package keys (for linking/type equality) separated from package IDs. · 66218d15
      Edward Z. Yang authored
      This patch set makes us no longer assume that a package key is a human
      readable string, leaving Cabal free to "do whatever it wants" to allocate
      keys; we'll look up the PackageId in the database to display to the user.
      This also means we have a new level of qualifier decisions to make at the
      package level, and rewriting some Safe Haskell error reporting code to DTRT.
      
      Additionally, we adjust the build system to use a new ghc-cabal output
      Make variable PACKAGE_KEY to determine library names and other things,
      rather than concatenating PACKAGE/VERSION as before.
      
      Adds a new `-this-package-key` flag to subsume the old, erroneously named
      `-package-name` flag, and `-package-key` to select packages by package key.
      
      RFC: The md5 hashes are pretty tough on the eye, as far as the file
      system is concerned :(
      
      ToDo: safePkg01 test had its output updated, but the fix is not really right:
      the rest of the dependencies are truncated due to the fact the we're only
      grepping a single line, but ghc-pkg is wrapping its output.
      
      ToDo: In a later commit, update all submodules to stop using -package-name
      and use -this-package-key.  For now, we don't do it to avoid submodule
      explosion.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D80
      66218d15
  8. 04 Aug, 2014 1 commit
  9. 26 Jul, 2014 2 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Module reexports, fixing #8407. · 7f5c1086
      Edward Z. Yang authored
      The general approach is to add a new field to the package database,
      reexported-modules, which considered by the module finder as possible
      module declarations.  Unlike declaring stub module files, multiple
      reexports of the same physical package at the same name do not
      result in an ambiguous import.
      
      Has submodule updates for Cabal and haddock.
      
      NB: When a reexport renames a module, that renaming is *not* accessible
      from inside the package.  This is not so much a deliberate design choice
      as for implementation expediency (reexport resolution happens only when
      a package is in the package database.)
      
      TODO: Error handling when there are duplicate reexports/etc is not very
      well tested.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Conflicts:
      	compiler/main/HscTypes.lhs
      	testsuite/.gitignore
      	utils/haddock
      7f5c1086
  10. 21 Jul, 2014 2 commits
    • Edward Z. Yang's avatar
      Rename PackageId to PackageKey, distinguishing it from Cabal's PackageId. · 4bebab25
      Edward Z. Yang authored
      Summary:
      Previously, both Cabal and GHC defined the type PackageId, and we expected
      them to be roughly equivalent (but represented differently).  This refactoring
      separates these two notions.
      
      A package ID is a user-visible identifier; it's the thing you write in a
      Cabal file, e.g. containers-0.9.  The components of this ID are semantically
      meaningful, and decompose into a package name and a package vrsion.
      
      A package key is an opaque identifier used by GHC to generate linking symbols.
      Presently, it just consists of a package name and a package version, but
      pursuant to #9265 we are planning to extend it to record other information.
      Within a single executable, it uniquely identifies a package.  It is *not* an
      InstalledPackageId, as the choice of a package key affects the ABI of a package
      (whereas an InstalledPackageId is computed after compilation.)  Cabal computes
      a package key for the package and passes it to GHC using -package-name (now
      *extremely* misnamed).
      
      As an added bonus, we don't have to worry about shadowing anymore.
      
      As a follow on, we should introduce -current-package-key having the same role as
      -package-name, and deprecate the old flag.  This commit is just renaming.
      
      The haddock submodule needed to be updated.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D79
      
      Conflicts:
      	compiler/main/HscTypes.lhs
      	compiler/main/Packages.lhs
      	utils/haddock
      4bebab25
    • Edward Z. Yang's avatar
      Make 'ghc' a wired in package. · bb06e2a8
      Edward Z. Yang authored
      Summary:
      Previously, the GHC API was "semi" wired-in: it was installed with a
      version number, but that version number was hard-coded into the compiler
      and it wasn't really possible to install other copies of the GHC API.
      This patch makes the GHC API more similar to existing wired-in packages
      such as ghc-prim, and will be helpful when we start extending the amount
      of information passed to -package-name.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonmar, simonpj, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D78
      bb06e2a8
  11. 22 Jun, 2014 1 commit
    • Edward Z. Yang's avatar
      Simplify package dump for -v4 · b6352c99
      Edward Z. Yang authored
      Summary:
      Previously, on -v4  and greater, we dumped out the entire package
      database, including lots of metadata that GHC doesn't really care about,
      and is guaranteed to correspond to the equivalent in the local/global
      package databases on disk.  So, to make this output more useful, on -v4
      we instead just print package IDs, and the exposed and trusted flags
      (E and T, which can be tweaked at runtime).
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: successful validate
      
      Reviewers: simonpj
      
      Subscribers: simonmar, relrod
      
      Differential Revision: https://phabricator.haskell.org/D24
      b6352c99
  12. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  13. 24 Feb, 2014 1 commit
  14. 02 Dec, 2013 1 commit
  15. 01 Dec, 2013 1 commit
  16. 21 Nov, 2013 1 commit
  17. 28 Aug, 2013 1 commit
    • thoughtpolice's avatar
      Rework how iOS does linking (#8127) · 98b0d05d
      thoughtpolice authored
      iOS has some particular constraints about how applications can be built:
      
       * We must generate a static library (.a) since XCode does the final
         link.
       * We need to carefully give the right set of arguments to libtool in
         the case we're generating an archive.
       * Dynamic linking isn't supported.
       * It can only be done on OS X.
      
      This patch cleans up all of the above. We add a new flag `-staticlib`
      (only supported on Darwin) that allows us to produce archive files using
      libtool, and a -pgmlibtool flag to control which 'libtool' executable to
      use.
      
      This fixes #8127. I believe this is the last piece missing from the iOS
      cross compiler.
      Authored-by: lukexi's avatarLuke Iannini <lukexi@me.com>
      Authored-by: maxs's avatarMaxwell Swadling <maxwellswadling@gmail.com>
      Authored-by: default avatarStephen Blackheath <...@blacksapphire.com>
      Signed-off-by: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
      98b0d05d
  18. 14 May, 2013 1 commit
    • ian@well-typed.com's avatar
      Fix the GHC package DLL-splitting · 60b86b04
      ian@well-typed.com authored
      There's now an internal -dll-split flag, which we use to tell GHC how
      the GHC package is split into 2 separate DLLs. This is used by
      Packages.isDllName to determine whether a call is within the same
      DLL, or whether it is a call to another DLL.
      60b86b04
  19. 23 Mar, 2013 1 commit
    • ian@well-typed.com's avatar
      Change how we handle libffi · b30015e7
      ian@well-typed.com authored
      I think overall the new approach is simpler. Rather than unpacking
      the libffi.a and putting the .o files into our libHSrts.a, we just
      use the libffi.a.
      
      This change also means that when compiling programs for the dyn
      way, they get explicitly linked against libffi.so (rather than
      relying on librts.so being linked against it). This might
      fix a problem on FreeBSD, where programs cannot find libffi.so.
      b30015e7
  20. 30 Jan, 2013 1 commit
  21. 29 Nov, 2012 1 commit
  22. 16 Oct, 2012 2 commits
  23. 03 Sep, 2012 2 commits
  24. 02 Jul, 2012 1 commit
    • Simon Marlow's avatar
      -package P was loading all versions of P in GHCi (#7030) · 62164cf5
      Simon Marlow authored
      -package P means "the latest version of P" if multiple versions are
      installed.  It was working as advertised, but we were
      eagerly *linking* all versions of P, which might cause an error if the
      package has some C code, because we can't link multiple instances of
      the same symbol.
      62164cf5
  25. 12 Jun, 2012 1 commit