- Oct 14, 2016
-
-
Ryan Scott authored
Before, when you attempted to derive an instance for a typeclass, e.g., ``` class C1 (a :: Constraint) where class C2 where deriving instance C1 C2 ``` GHC would complain that `C2`'s data constructors aren't in scope. But that makes no sense, since typeclasses don't have constructors! By refining the checks that GHC performs when deriving, we can make the error message a little more sensible. This also cleans up a related `DeriveAnyClass` infelicity. Before, you wouldn't have been able to compile code like this: ``` import System.IO (Handle) class C a deriving instance C Handle ``` Since GHC was requiring that all data constructors of `Handle` be in scope. But `DeriveAnyClass` doesn't even generate code that mentions any data constructors, so this requirement is silly! Fixes #11509. Test Plan: make test TEST=T11509 Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie, simonpj Differential Revision: https://phabricator.haskell.org/D2558 GHC Trac Issues: #11509
-
Ryan Scott authored
Summary: There are currently three datatypes that are exposed in `base` that have `Monoid` instances, but no `Semigroup` instances: * `IO` * `Event` (from `GHC.Event`) * `Lifetime` (from `GHC.Event`) (There is also `EventLifetime` in `GHC.Event.Internal`, but it is not exported directly, so I didn't bother with it.) Adding the `Semigroup` instances for these types directly in the modules in which they're defined resulted in some horrific import cycles, so I opted to take the easy approach of defining all of these instances in `Data.Semigroup`. (When `Semigroup` becomes a superclass of `Monoid`, these instances will have to be moved somehow.) Fixes #12464. Test Plan: It compiles Reviewers: hvr, ekmett, austin, bgamari Reviewed By: ekmett Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2588 GHC Trac Issues: #12464
-
Ben Gamari authored
-
Ben Gamari authored
-
Ben Gamari authored
There is no reason why this should be a foldr considering we are building a map.
-
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
-
The previous encoding was entropically a bit better, but harder to encode and decode. Now we just split up the integer part of the unique into a bitfield. Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2468
-
- Oct 13, 2016
-
-
Edward Z. Yang authored
Signed-off-by:Edward Z. Yang <ezyang@cs.stanford.edu>
-
Simon Peyton Jones authored
This patch builds on the one for Trac #12124, by dealing properly with out-of-scope "hole" errors. This fixes Trac #12529. The hard error coming from visible type application is still there, but the out-of-scope error is no longer suppressed. (Arguably the VTA message should be suppressed somehow, but that's a battle for another day.)
-
Ryan Scott authored
-
Ryan Scott authored
Commit f352e5cd fixed #12456. Let's add a test to make sure it stays fixed.
-
- Oct 12, 2016
-
-
Ryan Scott authored
Commit af21e388 fixed #12598. Let's add a test to make sure it stays fixed.
-
Ryan Scott authored
The fix for #12584 also fixed the problem in #12411. Let's add a test to ensure that it stays fixed.
-
Ben Gamari authored
-
This fixes #12584, where wildcard patterns were snuck into an expression, which then crashed the typechecker in TcExpr since EWildPats aren't supposed to appear in the AST after renaming. The problem was that `rnTopSpliceDecl` failed to check for errors from `rnSplice` (as done by other callers to `rnSplice`). Thanks to Shayan for reporting this! Reviewers: simonpj, austin Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2539 GHC Trac Issues: #12584
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
This patch implements choice (3) of comment:14 on Trac #12660. It cures an infinite loop (caused by the creation of an infinite type) in in compiling the 'singletons' package. See Note [Add derived shadows only for Wanteds] in TcSMonad.
-
- Oct 11, 2016
-
-
Joachim Breitner authored
A rule with a phase specification trying to match on a constructor with a wrapper will fail to match, as the wrapper will be inlined by then. The fact that it works in the other case is also mostly by accident. (Split into two test cases so that regressions with regard what works so far are caught.)
-
Joachim Breitner authored
which test a few variants of rules involving constructors, including nullary constructors, constructors with wrappers, and unsaturated of constructors. At the moment, all the rules work as expected, despite GHC’s compile time warnings when called with -Wall.
-
- Oct 10, 2016
-
-
Simon Peyton Jones authored
These ones test the variations in coment:15 of the ticket
-
Simon Peyton Jones authored
With my latest commits 76a5477b Move zonking out of tcFamTyPats b255ae7b Orient improvement constraints better perf has improved slightly for T1969: allocs: 733M -> 26M residency: 43M -> 41M I don't know exactly why, but hey, it's good
-
Simon Peyton Jones authored
In tcFamTyPats we were zonking from the TcType world to the Type world, ready to build the results into a CoAxiom (which should have no TcType stuff. But the 'thing_inside' for tcFamTyPats also must be zonked, and that zonking must have the ZonkEnv from the binders zonked tcFamTyPats. Ugh. This caused an assertion failure (with DEBUG on) in RaeBlobPost and TypeLevelVec, both in tests/dependent, as shown in Trac #12682. Why it hasn't shown up before now is obscure to me. So I moved the zonking stuff out of tcFamTyPats to its three call sites, where we can do it all together. Very slightly longer, but much more robust.
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
This patch fixes an infinite loop in the constraint solver, shown up by Trac #12522. The solution is /very/ simple: just reverse the orientation of the derived constraints arising from improvement using type-family injectivity. I'm not very proud of the fix --- it seems fragile --- but it has the very great merit of simplicity, and it works fine. See Note [Improvement orientation] in TcInteract, and some discussion on the Trac ticket.
-
- Oct 09, 2016
-
-
Test Plan: View updated documentation? Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2583 GHC Trac Issues: #12672
-
Nursery chunks help reduce the cost of GC when capabilities are unevenly loaded, by ensuring that we use more of the available nursery. The rationale for enabling this at -A16m is that any negative effects due to loss of cache locality are less likely to be an issue at -A16m and above. It's a conservative guess. If we had a lot of benchmark data we could probably do better. Results for nofib/parallel at -N4 -A32m with and without -n4m: ``` ------------------------------------------------------------------------ Program Size Allocs Runtime Elapsed TotalMem ------------------------------------------------------------------------ blackscholes 0.0% -9.5% -9.0% -15.0% -2.2% coins 0.0% -4.7% -3.6% -0.6% -13.6% mandel 0.0% -0.3% +7.7% +13.1% +0.1% matmult 0.0% +1.5% +10.0% +7.7% +0.1% nbody 0.0% -4.1% -2.9% 0.085 0.0% parfib 0.0% -1.4% +1.0% +1.5% +0.2% partree 0.0% -0.3% +0.8% +2.9% -0.8% prsa 0.0% -0.5% -2.1% -7.6% 0.0% queens 0.0% -3.2% -1.4% +2.2% +1.3% ray 0.0% -5.6% -14.5% -7.6% +0.8% sumeuler 0.0% -0.4% +2.4% +1.1% 0.0% ------------------------------------------------------------------------ Min 0.0% -9.5% -14.5% -15.0% -13.6% Max 0.0% +1.5% +10.0% +13.1% +1.3% Geometric Mean +0.0% -2.6% -1.3% -0.5% -1.4% ``` Not conclusive, but slightly better. This matters a lot more when you have more cores. Test Plan: validate, nofib/paralel Reviewers: niteria, ezyang, nh2, trofi, austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2581 GHC Trac Issues: #9221 -
Setting a -N value that is too large has a dramatic negative effect on performance, but the new -qn flag can mitigate the worst of the effects by limiting the number of GC threads. So now, if you don't explcitly set +RTS -qn, and you set -N larger than the number of cores (or use setNumCapabilities to do the same), we'll default -qn to the number of cores. These are the results from nofib/parallel on my 4-core (2 cores x 2 threads) i7 laptop, comparing -N8 before and after this change. ``` ------------------------------------------------------------------------ Program Size Allocs Runtime Elapsed TotalMem ------------------------------------------------------------------------ blackscholes +0.0% +0.0% -72.5% -72.0% +9.5% coins +0.0% -0.0% -73.7% -72.2% -0.8% mandel +0.0% +0.0% -76.4% -75.4% +3.3% matmult +0.0% +15.5% -26.8% -33.4% +1.0% nbody +0.0% +2.4% +0.7% 0.076 0.0% parfib +0.0% -8.5% -33.2% -31.5% +2.0% partree +0.0% -0.0% -60.4% -56.8% +5.7% prsa +0.0% -0.0% -65.4% -60.4% 0.0% queens +0.0% +0.2% -58.8% -58.8% -1.5% ray +0.0% -1.5% -88.7% -85.6% -3.6% sumeuler +0.0% -0.0% -47.8% -46.9% 0.0% ------------------------------------------------------------------------ Min +0.0% -8.5% -88.7% -85.6% -3.6% Max +0.0% +15.5% +0.7% -31.5% +9.5% Geometric Mean +0.0% +0.6% -61.4% -63.1% +1.4% ``` Test Plan: validate, nofib/parallel benchmarks Reviewers: niteria, ezyang, nh2, austin, erikd, trofi, bgamari Reviewed By: trofi, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2580 GHC Trac Issues: #9221 -
When trying to build arm64-apple-iso, the build fell over `strdup`, as the arm64-apple-ios build did not fall into `darwin_HOST_OS`, and would need `ios_HOST_OS`. This diff tries to clean up PosixSource.h, instead of layering another define on top. As we use `strnlen` in sources that include PosixSource.h, and `strnlen` is defined in POSIX.1-2008, the `_POSIX_C_SOURCE` and `_XOPEN_SOURCE` are increased accordingly. Furthermore the `_DARWIN_C_SOURCE` (required for `u_char`, etc. used in sysctl.h) define is moved into `OSThreads.h` alongside a similar ifdef for freebsd. Test Plan: Build on all supported platforms. Reviewers: austin, simonmar, erikd, kgardas, bgamari Reviewed By: simonmar, erikd, kgardas, bgamari Subscribers: Phyx, hvr, thomie Differential Revision: https://phabricator.haskell.org/D2579 GHC Trac Issues: #12624
-
When trying to profile a plugin, ghc mysteriously segfaulted. Upon closer examination the segfault happend due to a `->prevStack` lookup on a NULL pointer. A new CostCentre: Unknown is introduced that is set, if ccsapp and ccsfn are of equal depth (e.g. 0), and do not have a common CostCentre in their stacks. Reviewers: bgamari, simonmar, austin, erikd Reviewed By: simonmar Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2551
-
Edward Z. Yang authored
Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2585 GHC Trac Issues: #12673
-
- Oct 08, 2016
-
-
- interaction between backpack and export list refactoring introduced a few syntax errors, and constructor arity mismatches - CPP macro used in backpack was not accepted by clang because of extraneous whitespace Signed-off-by:
Csongor Kiss <kiss.csongor.kiss@gmail.com> Reviewers: austin, bgamari, mpickering Reviewed By: mpickering Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2582
-
Matthew Pickering authored -
Matthew Pickering authored
The target of this patch is exports such as: ``` module Foo ( T(A, B, C) ) where ``` Essentially this patch makes sure that we use the correct lookup functions in order to lookup the names in parent-children export lists. This change highlighted the complexity of this small part of GHC which accounts for the scale. This change was motivated by wanting to remove the `PatternSynonym` constructor from `Parent`. As with all these things, it quickly spiraled out of control into a much larger refactor. Reviewers: simonpj, goldfire, bgamari, austin Subscribers: adamgundry, thomie Differential Revision: https://phabricator.haskell.org/D2179 GHC Trac Issues: #11970
-
Edward Z. Yang authored
Signed-off-by: -
Edward Z. Yang authored
Signed-off-by: -
Edward Z. Yang authored
Signed-off-by: -
Edward Z. Yang authored
It turns out that we don't really need to be able to extract a ComponentId from UnitId, except in one case. So compress UnitId into a single FastString. The one case where we do need the ComponentId is when we are compiling an instantiated version of a package; we need the ComponentId to look up the indefinite version of this package from the database. So now we just pass it in as an argument -this-component-id. Also: ghc-pkg now no longer will unregister a package if you register one with the same package name, if the instantiations don't match. Cabal submodule update which tracks the same data type change. Signed-off-by: -
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:
-
