1. 03 Feb, 2017 1 commit
    • Sylvain Henry's avatar
      Ditch static flags · bbd3c399
      Sylvain Henry authored
      This patch converts the 4 lasting static flags (read from the command
      line and unsafely stored in immutable global variables) into dynamic
      flags. Most use cases have been converted into reading them from a DynFlags.
      
      In cases for which we don't have easy access to a DynFlags, we read from
      'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'.
      It's not perfect (not thread-safe) but it is still better as we can
      set/unset these 4 flags before each run when using GHC API.
      
      Updates haddock submodule.
      
      Rebased and finished by: bgamari
      
      Test Plan: validate
      
      Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2839
      
      GHC Trac Issues: #8440
      bbd3c399
  2. 01 Feb, 2017 1 commit
  3. 26 Jan, 2017 1 commit
  4. 22 Jan, 2017 1 commit
    • Edward Z. Yang's avatar
      Rewrite Backpack comments on never-exported TyThings. · bbe8956f
      Edward Z. Yang authored
      
      
      Summary:
      While thesing, I realized this part of the implementation
      didn't make very much sense, so I started working on some
      documentation updates to try to make things more explainable.
      
      The new docs are organized around the idea of a
      "never exported TyThing" (a non-implicit TyThing that never
      occurs in the export list of a module).  I also removed
      some outdated information that predated the change of
      ModIface to store Names rather than OccNames.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Reviewers: simonpj, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2989
      bbe8956f
  5. 11 Jan, 2017 3 commits
    • Edward Z. Yang's avatar
      Fix handling of closed type families in Backpack. · f59aad68
      Edward Z. Yang authored
      
      
      Summary:
      A few related problems:
      
      - CoAxioms, like DFuns, are implicit and never exported,
        so we have to make sure we treat them the same way as
        DFuns: in RnModIface we need to rename references to
        them with rnIfaceImplicit and in mergeSignatures we need
        to NOT check them directly for compatibility (the
        test on the type family will do this check for us.)
      
      - But actually, we weren't checking if the axioms WERE
        consistent.  This is because we were forwarding all
        embedded CoAxiom references in the type family TyThing
        to the merged version, but that reference was what
        checkBootDeclM was using as a comparison point.
        This is similar to a problem we saw with DFuns.
      
        To fix this, I refactored the handling of implicit entities in TcIface
        for Backpack.  See Note [The implicit TypeEnv] for the gory details.
        Instead of passing the TypeEnv around explicitly, we stuffed it in
        IfLclEnv.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: bgamari, simonpj, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2928
      f59aad68
    • Edward Z. Yang's avatar
      Revamp Backpack/hs-boot handling of type class signatures. · 5def07fa
      Edward Z. Yang authored
      Summary:
      A basket of fixes and improvements:
      
      - The permissible things that one can write in a type
        class definition in an hsig file has been reduced
        to encompass the following things:
      
          - Methods
          - Default method signatures (but NOT implementation)
          - MINIMAL pragma
      
        It is no longer necessary nor encouraged to specify
        that a method has a default if it is mentioned in
        a MINIMAL pragma; the MINIMAL pragma is assumed to
        provide the base truth as to what methods need to
        be implemented when writing instances of a type
        class.
      
      - Handling of default method signatures in hsig was
        previously buggy, as these identifiers were not exported,
        so we now treat them similarly to DFuns.
      
      - Default methods are merged, where methods with defaults
        override those without.
      
      - MINIMAL pragmas are merged by ORing together pragmas.
      
      - Matching has been relaxed: a method with a default can
        be used to fill a signature which did not declare ...
      5def07fa
    • Edward Z. Yang's avatar
      Support for using only partial pieces of included signatures. · 5f9c6d2a
      Edward Z. Yang authored
      
      
      Summary:
      Generally speaking, it's not possible to "hide" a requirement from a
      package you include, because if there is some module relying on that
      requirement, well, you can't just wish it out of existence.
      
      However, some packages don't have any modules.  For these, we can
      validly thin out requirements; indeed, this is very convenient if
      someone has published a large signature package but you only want
      some of the definitions.
      
      This patchset tweaks the interpretation of export lists in
      signatures: in particular, they no longer need to refer to
      entities that are defined locally; they range over both the current
      signature as well as any signatures that were inherited from
      signature packages (defined by having zero exposed modules.)
      
      In the process of doing this, I cleaned up a number of other
      things:
      
      * rnModIface and rnModExports now report errors that occurred
        during renaming and can propagate these to the TcM monad.
        This is important because in the current semantics, you can
        thin out a type which is referenced by a value you keep;
        in this situation, we need to error (to ensure that all
        types in signatures are rooted, so that we can determine
        their identities).
      
      * I ended up introducing a new construct 'dependency signature;
        to bkp files, to make it easier to tell if we were depending
        on a signature package.  It's not difficult for Cabal to
        figure this out (I already have a patch for it.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2904
      
      GHC Trac Issues: #12994
      5f9c6d2a
  6. 21 Dec, 2016 1 commit
    • Edward Z. Yang's avatar
      Support for abi-depends for computing shadowing. · ee4e1654
      Edward Z. Yang authored
      
      
      Summary:
      This is a complete fix based off of
      ed7af26606b3a605a4511065ca1a43b1c0f3b51d for handling
      shadowing and out-of-order -package-db flags simultaneously.
      
      The general strategy is we first put all databases together,
      overriding packages as necessary.  Once this is done, we successfully
      prune out broken packages, including packages which depend on a package
      whose ABI differs from the ABI we need.
      
      Our check gracefully degrades in the absence of abi-depends, as
      we only check deps which are recorded in abi-depends.
      
      Contains time and Cabal submodule update.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: niteria, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2846
      
      GHC Trac Issues: #12485
      ee4e1654
  7. 25 Nov, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve pretty-printing of types · 5f349fe2
      Simon Peyton Jones authored
      In this commit
         commit 6c0f10fa
         Author: Ben Gamari <bgamari.foss@gmail.com>
         Date:   Sun Nov 13 16:17:37 2016 -0500
      
          Kill Type pretty-printer
      
      we switched to pretty-printing a type by converting it to an
      IfaceType and pretty printing that.  Very good.
      
      This patch fixes two things
      
      * The new story is terrible for debug-printing with -ddump-tc-trace,
        because all the extra info in an open type was discarded ty the
        conversion to IfaceType.
      
        This patch adds IfaceTcTyVar to IfaceType, to carry a TcTyVar in
        debug situations.  Quite an easy change, happily.  These things
        never show up in interface files.
      
      * Now that we are going via IfaceType, it's essential to tidy before
        converting; otherwise
           forall k_23 k_34. blah
        is printed as
           forall k k. blah
        which is very unhelpful.  Again this only shows up in debug
        printing.
      5f349fe2
  8. 03 Nov, 2016 1 commit
  9. 30 Oct, 2016 1 commit
  10. 22 Oct, 2016 2 commits
    • Matthew Pickering's avatar
      Refactoring: Delete copied function in backpack/NameShape · 6e9a51c0
      Matthew Pickering authored
      Also moved a few utility functions which work with Avails into
      the Avail module to avoid import loops and increase discoverability.
      
      Reviewers: austin, bgamari, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2629
      6e9a51c0
    • 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
  11. 20 Oct, 2016 1 commit
  12. 14 Oct, 2016 1 commit
    • Ben Gamari's avatar
      Clean up handling of known-key Names in interface files · 34d933d6
      Ben Gamari authored
      Previously BinIface had some dedicated logic for handling tuple names in
      the symbol table. As it turns out, this logic was essentially dead code
      as it was superceded by the special handling of known-key things. Here
      we cull the tuple code-path and use the known-key codepath for all
      tuple-ish things.
      
      This had a surprising number of knock-on effects,
      
       * constraint tuple datacons had to be made known-key (previously they
         were not)
      
       * IfaceTopBndr was changed from being a synonym of OccName to a
         synonym of Name (since we now need to be able to deserialize Names
         directly from interface files)
      
       * the change to IfaceTopBndr complicated fingerprinting, since we need
         to ensure that we don't go looking for the fingerprint of the thing
         we are currently fingerprinting in the fingerprint environment (see
         notes in MkIface). Handling this required distinguishing between
         binding and non-binding Name occurrences in the Binary serializers.
      
       * the original name cache logic which previously lived in IfaceEnv has
         been moved to a new NameCache module
      
       * I ripped tuples and sums out of knownKeyNames since they introduce a
         very large number of entries. During interface file deserialization
         we use static functions (defined in the new KnownUniques module) to
         map from a Unique to a known-key Name (the Unique better correspond
         to a known-key name!) When we need to do an original name cache
         lookup we rely on the parser implemented in isBuiltInOcc_maybe.
      
       * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames.
      
       * Lots of comments were sprinkled about describing the new scheme.
      
      Updates haddock submodule.
      
      Test Plan: Validate
      
      Reviewers: niteria, simonpj, austin, hvr
      
      Reviewed By: simonpj
      
      Subscribers: simonmar, niteria, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2467
      
      GHC Trac Issues: #12532, #12415
      34d933d6
  13. 08 Oct, 2016 4 commits
  14. 10 Oct, 2015 1 commit
  15. 22 Sep, 2015 1 commit
    • niteria's avatar
      Make derived names deterministic · d4d34a73
      niteria authored
      The names of auxiliary bindings end up in the interface file, and since uniques
      are nondeterministic, we end up with nondeterministic interface files.
      
      This uses the package and module name in the generated name, so I believe it
      should avoid problems from #7947 and be deterministic as well.
      
      The generated names look like this now:
      
        `$cLrlbmVwI3gpI8G2E6Hg3mO`
      
      and with `-ppr-debug`:
      
        `$c$aeson_70dylHtv1FFGeai1IoxcQr$Data.Aeson.Types.Internal$String`.
      
      Reviewed By: simonmar, austin, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D1133
      
      GHC Trac Issues: #4012
      d4d34a73
  16. 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