- 26 Oct, 2016 5 commits
-
-
Michal Terepeta authored
This commit: - Moves the remaining few methods concerned with dataflow analysis from `CmmUtils` to `Hoopl.Dataflow`. - Refactors the code to not use `FwdPass` and simply pass `FwdTransfer` and `DataflowLattice` directly. Signed-off-by:
Michal Terepeta <michal.terepeta@gmail.com> Test Plan: validate Reviewers: austin, simonmar, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2634
-
Matthew Pickering authored
The flag was: 1. Not documented. 2. Only used as a boolean flag. 3. Has overlapping functionality with -dno-debug-output 4. My poll of #ghc concluded that people didn't know it existed. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2627 GHC Trac Issues: #12691
-
Matthew Pickering authored
For a nullary pattern synonym we add an extra void argument to the matcher in order to preserve laziness. The check in buildPatSyn wasn't aware of this special case which was causing the assertion to fail. Reviewers: austin, simonpj, bgamari Reviewed By: simonpj, bgamari Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2624 GHC Trac Issues: #12746
-
Matthew Pickering authored
Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2586 GHC Trac Issues: #12617
-
Simon Peyton Jones authored
The functional-dependency improvement functions, improveFromAnother improveFromInstEnv had a side-condition that said the type class has to have at least two arguments. But not so, as Trac #12763 shows: class C a | -> a where ... is perfectly legal, albeit a bit of a corner case.
-
- 24 Oct, 2016 3 commits
-
-
Simon Peyton Jones authored
One of the ASSERT failures in Trac #12762, namely the one for T4439, showed that I had not dealt correctly with promoting the kind of a type in promoteTcType. Happily I could fix this by simplifying InferRes (eliminating the ir_kind field), so things get better. And the ASSERT is fixed.
-
Simon Peyton Jones authored
Fixes most of the cases in Trac #12762
-
Simon Peyton Jones authored
This patch fixes Trac #12734 by prioritising the class-level variants of equality constraints, namely (a~b) and (a~~b). See comment:10 of Trac #12734 for a description of what went wrong, and Note [Prioritise class equalities] in TcSMonad. The fix is still not great, but it's a definite step forward, and cures the particular problem. Worth merging to 8.0.
-
- 22 Oct, 2016 5 commits
-
-
Matthew Pickering authored
[skip ci]
-
Michal Terepeta authored
This doesn't have any functional changes, it simply removes one unnecessary top binding and improves the comments. Signed-off-by:
Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: austin, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2619
-
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
-
Erik de Castro Lopo authored
When enabled, this new warning flag passes `-Wundef` to the C pre-processor which causes the pre-processor to warn on uses of the `#if` directive on undefined identifiers. It is not currently enabled in any of the standard warning groups. Test Plan: Make sure the two tests pass on all major platforms. Reviewers: hvr, carter, Phyx, bgamari, austin Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2626 GHC Trac Issues: #12752
-
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
-
- 21 Oct, 2016 8 commits
-
-
Simon Peyton Jones authored
When debugging something else I noticed that these functions were emitting constraints like [W] a ~ a which is plain stupid. So I fixed it not to do that. Should result in fewer constraints getting generated.
-
Simon Peyton Jones authored
This is just a minor refactoring
-
Simon Peyton Jones authored
This patch does two related things * Combines the occurrence-check logic in the on-the-fly unifier with that in the constraint solver. They are both doing the same job, after all. The resulting code is now in TcUnify: metaTyVarUpdateOK occCheckExpand occCheckForErrors (called in TcErrors) * In doing this I disovered checking for family-free-ness and foralls can be unnecessarily inefficient, because it expands type synonyms. It's easy just to cache this info in the type syononym TyCon, which I am now doing.
-
Simon Peyton Jones authored
This patch does a raft of useful tidy-ups in the type checker. I've been meaning to do this for some time, and finally made time to do it en route to ICFP. 1. Modify TcType.ExpType to make a distinct data type, InferResult for the Infer case, and consequential refactoring. 2. Define a new function TcUnify.fillInferResult, to fill in an InferResult. It uses TcMType.promoteTcType to promote the type to the level of the InferResult. See TcMType Note [Promoting a type] This refactoring is in preparation for an improvement to typechecking pattern bindings, coming next. I flirted with an elaborate scheme to give better higher rank inference, but it was just too complicated. See TcMType Note [Promotion and higher rank types] 3. Add to InferResult a new field ir_inst :: Bool to say whether or not the type used to fill in the InferResult should be deeply instantiated. See TcUnify Note [Deep instantiation of InferResult]. 4. Add a TcLevel to SkolemTvs. This will be useful generally - it's a fast way to see if the type variable escapes when floating (not used yet) - it provides a good consistency check when updating a unification variable (TcMType.writeMetaTyVarRef, the level_check_ok check) I originally had another reason (related to the flirting in (2), but I left it in because it seems like a step in the right direction. 5. Reduce and simplify the plethora of uExpType, tcSubType and related functions in TcUnify. It was such an opaque mess and it's still not great, but it's better. 6. Simplify the uo_expected field of TypeEqOrigin. Richard had generatlised it to a ExpType, but it was almost always a Check type. Now it's back to being a plain TcType which is much, much easier. 7. Improve error messages by refraining from skolemisation when it's clear that there's an error: see TcUnify Note [Don't skolemise unnecessarily] 8. Type.isPiTy and isForAllTy seem to be missing a coreView check, so I added it 9. Kill off tcs_used_tcvs. Its purpose is to track the givens used by wanted constraints. For dictionaries etc we do that via the free vars of the /bindings/ in the implication constraint ic_binds. But for coercions we just do update-in-place in the type, rather than generating a binding. So we need something analogous to bindings, to track what coercions we have added. That was the purpose of tcs_used_tcvs. But it only worked for a /single/ iteration, whereas we may have multiple iterations of solving an implication. Look at (the old) 'setImplicationStatus'. If the constraint is unsolved, it just drops the used_tvs on the floor. If it becomes solved next time round, we'll pick up coercions used in that round, but ignore ones used in the first round. There was an outright bug. Result = (potentialy) bogus unused-constraint errors. Constructing a case where this actually happens seems quite trick so I did not do so. Solution: expand EvBindsVar to include the (free vars of the) coercions, so that the coercions are tracked in essentially the same way as the bindings. This turned out to be much simpler. Less code, more correct. 10. Make the ic_binds field in an implication have type ic_binds :: EvBindsVar instead of (as previously) ic_binds :: Maybe EvBindsVar This is notably simpler, and faster to use -- less testing of the Maybe. But in the occaional situation where we don't have anywhere to put the bindings, the belt-and-braces error check is lost. So I put it back as an ASSERT in 'setImplicationStatus' (see the use of 'termEvidenceAllowed') All these changes led to quite bit of error message wibbling
-
Simon Peyton Jones authored
Make the TcLevel of a flatten-meta-var be always zero. See TcType.fmvTcLevel. This allows the levels of implication constraints to to up by 1 each time instead of 2, which is less confusing. This change has no effect on type checking.
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
This patch fixes a regression introduced, post 8.0.1, by this major commit: commit 15b9bf4b Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Sat Jun 11 23:49:27 2016 +0100 Improve typechecking of let-bindings This major commit was initially triggered by #11339, but it spiraled into a major review of the way in which type signatures for bindings are handled, especially partial type signatures. I didn't get the typechecking of pattern bindings right, leading to Trac #12427. In fixing this I found that this program doesn't work: data T where T :: a -> ((forall b. [b]->[b]) -> Int) -> T h1 y = case y of T _ v -> v Works in 7.10, but not in 8.0.1. There's a happy ending. I found a way to fix this, and improve pattern bindings too. Not only does this fix #12427, but it also allows In particular,we now can accept data T where MkT :: a -> Int -> T ... let { MkT _ q = t } in ... Previously this elicited "my head exploded" but it's really fine since q::Int. The approach is described in detail in TcBinds Note [Typechecking pattern bindings] Super cool. And not even a big patch!
-
Gabor Greif authored
-
- 20 Oct, 2016 4 commits
-
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Summary: Previously, we deleted if the heads matched, which meant that we effectively were picking an arbitrary instance if there were incompatible instances. The new behavior makes more sense, although without incoherent instances you are unlikely to be able to do anything useful with the instances. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2596
-
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:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: goldfire, simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2594
-
- 19 Oct, 2016 4 commits
-
-
Peter Trommler authored
On architectures with weak memory consistency a write barrier is needed before the write to the pointer array. Fixes #12469 Test Plan: rebuilt Stackage nightly twice on powerpc64le Reviewers: hvr, rrnewton, erikd, austin, simonmar, bgamari Reviewed By: erikd, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2525 GHC Trac Issues: #12469
-
Simon Peyton Jones authored
Newtypes cannot (currently) have an unboxed argument type. But Trac #12729 showed that this was only being checked for newtypes in H98 syntax; in GADT snytax they were let through. This patch moves the test to checkValidDataCon, where it properly belongs.
-
Michal Terepeta authored
We had *a lot* of code copied from Hoopl that is for rewriting. But GHC doesn't use it (it only uses some forked Hoopl code for analysis). So we can safely kill all this code and make it much easier to refactor and improve the parts that we do use. Signed-off-by:
Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2612
-
Edward Z. Yang authored
Previously we pruned out orphan modules from external packages but this was wrong. Fixes #12733 (which has more discussion.) Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2610 GHC Trac Issues: #12733
-
- 18 Oct, 2016 2 commits
-
-
Ömer Sinan Ağacan authored
-
Edward Z. Yang authored
Summary: I also added some more comments about the orphan and family instance hashing business. Fixes #12723. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2607 GHC Trac Issues: #12723
-
- 17 Oct, 2016 9 commits
-
-
Simon Peyton Jones authored
This adds a line I deleted by mistake in commit db71d971 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Fri Oct 14 17:40:51 2016 +0100 Reduce trace output slightly Sorry about that!
-
Gabor Greif authored
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
The wrappers in matchExpectedConTy were being composed back to front, resulting in a Core Lint error. Yikes! This has been here a long time. Fixes Trac #12676.
-
Simon Peyton Jones authored
Trac #12698 exposed a nasty bug in the typechecking for pattern synonmys: the existential type variables weren't being put in properly-scoped order. For some reason TcPatSyn.tcCollectEx was colleting them as a set, not as a list! Easily fixed.
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
This bug, exposed by Trac #12562 was very obscure, and has been lurking for a long time. What happened was that, in the worker/wrapper split a tyvar binder for a worker function accidentally shadowed an in-scope term variable that was mentioned in the body of the function It's jolly hard to provoke, so I have not even attempted to make a test case. There's a Note [Freshen WW arguments] to explain. Interestingly, fixing the bug (which meant fresher type variables) revealed a second lurking bug: I'd failed to apply the substitution to the coercion in the second last case of mkWWArgs, which introduces a Cast.
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
-