1. 22 Jan, 2017 1 commit
  2. 11 Jan, 2017 5 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
      Improve Backpack support for fixities. · e41c61fa
      Edward Z. Yang authored
      
      
      Summary:
      Two major bug-fixes:
      
          - Check that fixities match between hsig and implementation
      
          - Merge and preserve fixities when merging signatures
      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/D2919
      
      GHC Trac Issues: #13066
      e41c61fa
    • Edward Z. Yang's avatar
      Warn if you explicitly export an identifier with warning attached. · 0bbcf76a
      Edward Z. Yang authored
      
      
      Summary:
      This won't stop people from attempting to use this identifier
      (since it is still always going to be in the export list), but
      having an explicit reference to something people shouldn't
      use is a smell, so warn about it.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2907
      0bbcf76a
    • Edward Z. Yang's avatar
      Attach warnings to non-PVP compatible uses of signatures. · 9f169bcd
      Edward Z. Yang authored
      
      
      Summary:
      If you use an inherited signature from another package in your own code,
      the only valid PVP bound you can specify for this package is an *exact*
      version bound.  This is because the signature is used both covariantly
      (it provides declarations for import) and contravariantly (it specifies
      what is required).  However, this is a bit distressing if you want to
      use a PVP-style bound that allows for upgrading a package.  So there is
      a dichotomy:
      
          1. Any signatures that come from packages with exact bounds
          (this includes, in particular, signature packages, who are
          included solely to make declarations available), can be
          used without problem by modules, but
      
          2. Any signatures that come from packages that are version
          bounded (i.e., any package that also provides modules) must
          NOT be used, because if they were used, they could break
          under a PVP policy that allows relaxations in the needed
          requirements.
      
      To help users avoid situation (2), I've added a warning to all
      signature declarations that come solely from (2).  This is not
      perfect; you might still end up relying on some type identity
      specified by a signature in a version-bounded package, but it
      should help catch major errors.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2906
      9f169bcd
    • 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
  3. 14 Dec, 2016 1 commit
  4. 08 Dec, 2016 2 commits
  5. 17 Nov, 2016 1 commit
    • Edward Z. Yang's avatar
      Test for type synonym loops on TyCon. · 31398fbc
      Edward Z. Yang authored
      
      
      Summary:
      Previously, we tested for type synonym loops by doing
      a syntactic test on the literal type synonym declarations.
      However, in some cases, loops could go through hs-boot
      files, leading to an infinite loop (#12042); a similar
      situation can occur when signature merging.
      
      This commit replaces the syntactic test with a test on
      TyCon, simply by walking down all type synonyms until
      we bottom out, or find we've looped back.  It's a lot
      simpler.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2656
      
      GHC Trac Issues: #12042
      31398fbc
  6. 20 Oct, 2016 1 commit
  7. 08 Oct, 2016 3 commits