- 22 Jan, 2017 1 commit
-
-
Edward Z. Yang authored
Forgot to handle these! In they go, plus a test case. Signed-off-by:Edward Z. Yang <ezyang@cs.stanford.edu>
-
- 11 Jan, 2017 6 commits
-
-
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:
-
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: -
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: -
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:
-
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: -
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:
-
- 15 Dec, 2016 1 commit
-
-
Ben Gamari authoredUpdates a number of submodules.
-
- 14 Dec, 2016 1 commit
-
-
Edward Z. Yang authored
Summary: If we didn't load the orphans, we might conclude an instance is not implemented when it is. See test bkp42. Signed-off-by:
-
- 13 Dec, 2016 2 commits
-
-
Edward Z. Yang authored
Summary: Previously, we only checked to recompile if a signature we previously depended on changed; however, if the -unit-id settings changed, this could have resulted in more or less signatures needing to be merged in; we weren't checking for this case. (Note that this logic is irrelevant for normal module imports, which we also check using -unit-id, as we record each import and redo it, forcing a recompile if the result changed.) Signed-off-by:
-
Edward Z. Yang authored
Summary: Previously we would just let compilation proceed along until we tried to pull up the Module for the hsig file, and get main:A instead of <A>, and get a mysterious error. Check for this earlier! Fixes #12955. Signed-off-by:
-
- 08 Dec, 2016 2 commits
-
-
Edward Z. Yang authored
Summary: Previously, we always qualified names, even if they were defined in the modules we were matching. Adding the exports of the implementing module into the RdrEnv greatly reduces the amount of qualification (although we still can't qualify things that the signature *imported*.) Signed-off-by:
-
Edward Z. Yang authored
Summary: Previously, we updated tcg_imports after doing all of the actual matching, which was fine for outputting the interface, but not good enough for checking if all type classes were implemented; we weren't treating orphans as visible (when they needed to be.) Fixes #12945. Signed-off-by:
-
- 29 Nov, 2016 1 commit
-
-
This patch reverts the change introduced with 587dcccf and restores the previous default output of GHC (i.e., show source path and object path for each compiled module). The -fhide-source-paths flag can be used to hide these paths and reduce the line noise. Reviewers: gracjan, nomeata, austin, bgamari, simonmar, hvr Reviewed By: hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2728 GHC Trac Issues: #12851
-
- 17 Nov, 2016 1 commit
-
-
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:
-
- 12 Nov, 2016 1 commit
-
-
Reviewers: simonmar, mpickering, austin, bgamari Reviewed By: bgamari Subscribers: mpickering, nomeata, thomie Differential Revision: https://phabricator.haskell.org/D2679 GHC Trac Issues: #12807
-
- 28 Oct, 2016 1 commit
-
-
Edward Z. Yang authored
Signed-off-by:
-
- 20 Oct, 2016 3 commits
-
-
Edward Z. Yang authored
Signed-off-by: -
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
-
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:
-
- 13 Oct, 2016 1 commit
-
-
Edward Z. Yang authored
Signed-off-by:
-
- 08 Oct, 2016 2 commits
-
-
Edward Z. Yang authored
Signed-off-by: -
Edward Z. Yang authored
Summary: This patch implements Backpack for GHC. It's a big patch but I've tried quite hard to keep things, by-in-large, self-contained. The user facing specification for Backpack can be found at: https://github.com/ezyang/ghc-proposals/blob/backpack/proposals/0000-backpack.rst A guide to the implementation can be found at: https://github.com/ezyang/ghc-proposals/blob/backpack-impl/proposals/0000-backpack-impl.rst Has a submodule update for Cabal, as well as a submodule update for filepath to handle more strict checking of cabal-version. Signed-off-by:
-
