1. 22 Jan, 2017 1 commit
  2. 11 Jan, 2017 6 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 the
        method as having a default, and a more relaxed MINIMAL
        pragma can be used (we check if the signature pragma
        implies the final implementation pragma, on the way
        fixing a bug with BooleanFormula.implies, see #13073)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2925
      
      GHC Trac Issues: #13041
      5def07fa
    • 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. 15 Dec, 2016 1 commit
  4. 14 Dec, 2016 1 commit
  5. 13 Dec, 2016 2 commits
  6. 08 Dec, 2016 2 commits
  7. 29 Nov, 2016 1 commit
  8. 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
  9. 12 Nov, 2016 1 commit
  10. 28 Oct, 2016 1 commit
  11. 20 Oct, 2016 3 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Support constraint synonym implementations of abstract classes. · 7e77c4b2
      Edward Z. Yang authored
      Summary:
      
      Test Plan: validate
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2595
      
      GHC Trac Issues: #12679
      7e77c4b2
    • Edward Z. Yang's avatar
      New story for abstract data types in hsig files. · 518f2895
      Edward Z. Yang authored
      
      
      Summary:
      In the old implementation of hsig files, we directly
      reused the implementation of abstract data types from
      hs-boot files.  However, this was WRONG.  Consider the
      following program (an abridged version of bkpfail24):
      
          {-# LANGUAGE GADTs #-}
          unit p where
              signature H1 where
                  data T
              signature H2 where
                  data T
              module M where
                  import qualified H1
                  import qualified H2
      
                  f :: H1.T ~ H2.T => a -> b
                  f x = x
      
      Prior to this patch, M was accepted, because the type
      inference engine concluded that H1.T ~ H2.T does not
      hold (indeed, *presently*, it does not).  However, if
      we subsequently instantiate p with the same module for
      H1 and H2, H1.T ~ H2.T does hold!  Unsound.
      
      The key is that abstract types from signatures need to
      be treated like *skolem variables*, since you can interpret
      a Backpack unit as a record which is universally quantified
      over all of its abstract types, as such (with some fake
      syntax for structural records):
      
          p :: forall t1 t2. { f :: t1 ~ t2 => a -> b }
          p = { f = \x -> x } -- ill-typed
      
      Clearly t1 ~ t2 is not solvable inside p, and also clearly
      it could be true at some point in the future, so we better
      not treat the lambda expression after f as inaccessible.
      
      The fix seems to be simple: do NOT eagerly fail when trying
      to simplify the given constraints.  Instead, treat H1.T ~ H2.T
      as an irreducible constraint (rather than an insoluble
      one); this causes GHC to treat f as accessible--now we will
      typecheck the rest of the function (and correctly fail).
      Per the OutsideIn(X) paper, it's always sound to fail less
      when simplifying givens.
      
      We do NOT apply this fix to hs-boot files, where abstract
      data is also guaranteed to be nominally distinct (since
      it can't be implemented via a reexport or a type synonym.)
      This is a somewhat unnatural state of affairs (there's
      no way to really interpret this in Haskell land) but
      no reason to change behavior.
      
      I deleted "representationally distinct abstract data",
      which is never used anywhere in GHC.
      
      In the process of constructing this fix, I also realized
      our implementation of type synonym matching against abstract
      data was not sufficiently restrictive.  In order for
      a type synonym T to be well-formed type, it must be a
      nullary synonym (i.e., type T :: * -> *, not type T a = ...).
      Furthermore, since we use abstract data when defining
      instances, they must not have any type family applications.
      
      More details in #12680.  This probably deserves some sort
      of short paper report.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2594
      518f2895
  12. 13 Oct, 2016 1 commit
  13. 08 Oct, 2016 2 commits