1. 30 Oct, 2015 1 commit
  2. 15 Oct, 2015 1 commit
    • Edward Z. Yang's avatar
      Update Cabal to HEAD, IPID renamed to Component ID. · 5b0191f7
      Edward Z. Yang authored
      
      
      This commit contains a Cabal submodule update which unifies installed
      package IDs and package keys under a single notion, a Component ID.
      We update GHC to keep follow this unification.  However, this commit
      does NOT rename installed package ID to component ID and package key to
      unit ID; the plan is to do that in a companion commit.
      
          - Compiler info now has "Requires unified installed package IDs"
      
          - 'exposed' is now expected to contain unit keys, not IPIDs.
      
          - Shadowing is no more.  We now just have a very simple strategy
            to deal with duplicate unit keys in combined package databases:
            if their ABIs are the same, use the latest one; otherwise error.
            Package databases maintain the invariant that there can only
            be one entry of a unit ID.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, hvr, goldfire
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1184
      
      GHC Trac Issues: #10714
      5b0191f7
  3. 23 Sep, 2015 1 commit
  4. 21 Sep, 2015 1 commit
  5. 02 Sep, 2015 1 commit
    • Eric Seidel's avatar
      Use IP based CallStack in error and undefined · 6740d70d
      Eric Seidel authored
      This patch modifies `error`, `undefined`, and `assertError` to use
      implicit call-stacks to provide better error messages to users.
      
      There are a few knock-on effects:
      
      - `GHC.Classes.IP` is now wired-in so it can be used in the wired-in
        types for `error` and `undefined`.
      
      - `TysPrim.tyVarList` has been replaced with a new function
        `TysPrim.mkTemplateTyVars`. `tyVarList` made it easy to introduce
        subtle bugs when you need tyvars of different kinds. The naive
      
        ```
        tv1 = head $ tyVarList kind1
        tv2 = head $ tyVarList kind2
        ```
      
        would result in `tv1` and `tv2` sharing a `Unique`, thus substitutions
        would be applied incorrectly, treating `tv1` and `tv2` as the same
        tyvar. `mkTemplateTyVars` avoids this pitfall by taking a list of kinds
        and producing a single tyvar of each kind.
      
      - The types `GHC.SrcLoc.SrcLoc` and `GHC.Stack.CallStack` now live in
        ghc-prim.
      
      - The type `GHC.Exception.ErrorCall` has a new constructor
        `ErrorCallWithLocation` that takes two `String`s instead of one, the
        2nd one being arbitrary metadata about the error (but usually the
        call-stack). A bi-directional pattern synonym `ErrorCall` continues to
        provide the old API.
      
      Updates Cabal, array, and haddock submodules.
      
      Reviewers: nh2, goldfire, simonpj, hvr, rwbarton, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, rodlogic, goldfire, maoe, simonmar, carter,
      liyang, bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D861
      
      GHC Trac Issues: #5273
      6740d70d
  6. 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
  7. 21 Jul, 2015 1 commit
  8. 13 Jul, 2015 1 commit
  9. 24 Jun, 2015 1 commit
  10. 11 Jun, 2015 1 commit
  11. 25 Apr, 2015 1 commit
  12. 07 Apr, 2015 1 commit
    • 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
  13. 23 Mar, 2015 1 commit
  14. 06 Dec, 2014 1 commit
  15. 27 Nov, 2014 1 commit
  16. 15 Nov, 2014 1 commit
    • Edward Z. Yang's avatar
      Generalize exposed-modules field in installed package database · e14a9732
      Edward Z. Yang authored
      
      
      Summary:
      Instead of recording exposed-modules and reexported-modules as seperate
      fields in the installed package database, this commit merges them into
      a single field (exposed-modules).  The motivation for this change is
      in preparation for the inclusion of *signatures* into the installed
      package database, which may also be reexported.  Merging the representation
      means that we can treat reexports uniformly, no matter if they're a normal
      module or a signature.
      
      This commit adds a stub for signatures, but that code isn't wired up to
      anything yet.
      
      Contains Cabal submodule update to accommodate these changes.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, duncan, austin
      
      Subscribers: thomie, carter, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D421
      e14a9732
  17. 30 Oct, 2014 1 commit
  18. 28 Oct, 2014 1 commit
  19. 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
  20. 09 Sep, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Bump `base` version to 4.8.0.0 for real · c6f502b2
      Herbert Valerio Riedel authored
      This commit updates several submodules in order to bump
      the upper bounds on `base` of most boot packages
      
      Moreover, this updates some of the test-suite cases which have
      version numbers hardcoded within.
      
      However, I'm not sure if this commit didn't introduce the following
      two test-failures
      
         ghc-api  T8628 [bad stdout] (normal)
         ghc-api  T8639_api [bad stdout] (normal)
      
      This needs investigation
      c6f502b2
  21. 01 Sep, 2014 2 commits
  22. 05 Aug, 2014 2 commits
    • 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
      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
  23. 28 Jul, 2014 1 commit
  24. 26 Jul, 2014 1 commit
    • 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
  25. 21 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      [ghc-pkg] Fix #5442 by using the flag db stack to modify packages. · d7c807f7
      Edward Z. Yang authored
      
      
      Summary:
      Previously, the full database stack was used for ghc-pkg to
      modify packages, which meant that commands like
      'ghc-pkg unregister --user' worked the same as 'ghc-pkg unregister'.
      Since package modification is a "read and write" operation, we
      should use the flag db stack (which is currently used for reads)
      to determine which database to update.
      
      There is also a new flag --user-package-db, which lets you explicitly
      set the user database (as seen by --user).  This was mostly added
      to aid in testing, but could be useful for end users as well.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D84
      d7c807f7
  26. 17 Apr, 2014 1 commit
  27. 22 Mar, 2014 1 commit
  28. 05 Feb, 2013 2 commits
  29. 25 Jan, 2013 1 commit
  30. 31 Oct, 2012 1 commit
  31. 25 Oct, 2012 1 commit
  32. 12 Oct, 2012 1 commit
  33. 04 Oct, 2012 1 commit
  34. 23 Aug, 2012 1 commit
  35. 15 May, 2012 1 commit
  36. 01 May, 2012 1 commit
  37. 26 Oct, 2011 1 commit