 06 Sep, 2017 1 commit


Ben Gamari authored

 05 Sep, 2017 13 commits


Ryan Scott authored
Summary: Before, there was a discrepancy in how GHC renamed type synonyms as opposed to type family instances. That is, GHC would accept definitions like this one: ```lang=haskell type T = (Nothing :: Maybe a) ``` However, it would not accept a very similar type family instance: ```lang=haskell type family T :: Maybe a type instance T = (Nothing :: Maybe a) ``` The primary goal of this patch is to bring the renaming of type family instances up to par with that of type synonyms, causing the latter definition to be accepted, and fixing #14131. In particular, we now allow kind variables on the righthand sides of type (and data) family instances to be //implicitly// bound by LHS type (or kind) patterns (as opposed to type variables, which must always be explicitly bound by LHS type patterns only). As a consequence, this allows programs reported in #7938 and #9574 to typecheck, whereas before they would have been rejected. Implementationwise, there isn't much trickery involved in making this happen. We simply need to bind additional kind variables from the RHS of a type family in the right place (in particular, see `RnSource.rnFamInstEqn`, which has undergone a minor facelift). While doing this has the upside of fixing #14131, it also made it easier to trigger #13985, so I decided to fix that while I was in town. This was accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13985, #14131 Differential Revision: https://phabricator.haskell.org/D3872

Ben Gamari authored
Test Plan: Build, program with `eventlog`, try running with `+RTS h` Reviewers: austin, erikd, simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #14096 Differential Revision: https://phabricator.haskell.org/D3922

Ben Gamari authored
Reviewers: austin, erikd, simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #14096 Differential Revision: https://phabricator.haskell.org/D3923

Ben Gamari authored
Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3921

alekzcb authored
Summary: Fixes #8532 Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #8532 Differential Revision: https://phabricator.haskell.org/D3916

Ben Gamari authored
Previously SetLevels.lvlMFE would fail to substitute in ticks, unlike lvlExpr. This lead to #13481. Fix this. Test Plan: `make test TEST=T12622 WAY=ghci` Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13481 Differential Revision: https://phabricator.haskell.org/D3920

Tamar Christina authored
When doing profiling on startup time of ghci on Windows, both cold and startup loading static LLVM libs, the profiler is showing a glaring red spot on the division operation of the the hashStr function. In fact profiling shows 14% of the time is spent hashing the keys. So I am replacing the hash function with xxHash which is a very fast noncrypto hash. It's faster than MurMurHash which node etc use. It also passes SMHasher. I can provide if required the collected raw data. But from analysis done on the keys, xxHash does not introduce more collisions than before, the amount splits seem about the same and the distributions among the buckets are slightly more uniform than before. However the runtime dropped enough to remove the function completely from the profiler's report. There's also a noticeable improvement in responsiveness. xxHash is BSD licensed and can be found https://github.com/Cyan4973/xxHash Test Plan: ./validate Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13165 Differential Revision: https://phabricator.haskell.org/D3909

Ben Gamari authored
This fixes #12502 by using the `find` utility found by FP_PROG_FIND instead of the first one in PATH. Test Plan: Validate on Windows Reviewers: Phyx, austin, hvr Reviewed By: Phyx Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #12502 Differential Revision: https://phabricator.haskell.org/D3907

Ben Gamari authored
The script appears to use the local keyword, which I'm fairly certain is a feature of bash and not sh. Reviewers: Phyx, austin Reviewed By: Phyx Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3906

Ryan Scott authored
`RnTypes` contains a fairly intricate algorithm to extract the kind and type variables of an HsType. This algorithm carefully maintains the separation between type variables and kind variables so that the difference between `XPolyKinds` and `XTypeInType` can be respected. But after doing all this, `rmDupsInRdrTyVars` stupidly just concatenated the lists of type and kind variables at the end. If a variable were used as both a type and a kind, the algorithm would produce *both*! This led to all kinds of problems, including #13988. This is mostly Richard Eisenberg's patch. The only original contribution I made was adapting call sites of `rnImplicitBndrs` to work with the new definition of `rmDupsInRdrTyVars`. That is, `rnImplicitBndrs` checks for variables that are illegally used in both type and kind positions without using `XTypeInType`, but in order to check this, one cannot have filtered duplicate variables out before passing them to `rnImplicitBndrs`. To accommodate for this, I needed to concoct variations on the existing `extract` functions in `RnTypes` which do not remove duplicates, and use those near `rnImplicitBndrs` call sites. test case: ghci/scripts/T13988 Test Plan: make test TEST=T13988 Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: goldfire, simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13988 Differential Revision: https://phabricator.haskell.org/D3902

alexbiehl authored
This is another take on https://phabricator.haskell.org/D3844. This patch removes then need for haddock to reimplement the calculation of exported names from modules. Instead when renaming export lists ghc annotates each IE with its exported names. Haddocks current export logic has caused lots of trouble in the past (on the Github issue tracker):  https://github.com/haskell/haddock/issues/121  https://github.com/haskell/haddock/issues/174  https://github.com/haskell/haddock/issues/225  https://github.com/haskell/haddock/issues/344  https://github.com/haskell/haddock/issues/584  https://github.com/haskell/haddock/issues/591  https://github.com/haskell/haddock/issues/597 Updates haddock submodule. Reviewers: austin, bgamari, ezyang Reviewed By: bgamari, ezyang Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3864

Ben Gamari authored
It's not impossible that this will also get caught by another test given a suitably configured compiler, but this is minimal enough that it seems worth including. Test Plan: Validate with `DYNAMIC_GHC_PROGRAMS=NO` Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #14129 Differential Revision: https://phabricator.haskell.org/D3924

Ben Gamari authored
Test Plan: Run `make test WAY=prof` Reviewers: angerman, austin Subscribers: rwbarton, thomie GHC Trac Issues: #14181 Differential Revision: https://phabricator.haskell.org/D3917

 04 Sep, 2017 1 commit


Herbert Valerio Riedel authored
This is a preparatory refactoring for Semigroup=>Monoid as it prevents a messy .hsboot file which would interact inconveniently with the buildsystem...

 02 Sep, 2017 5 commits


Ryan Scott authored
Summary: Some code that @dfeuer was writing implicitly depended on these laws, but they didn't appear to be enshrined in the Haddocks. Let's do so. Test Plan: Read it Reviewers: austin, hvr, bgamari, dfeuer Reviewed By: dfeuer Subscribers: rwbarton, thomie, dfeuer Differential Revision: https://phabricator.haskell.org/D3908

Ryan Scott authored
Summary: Two places in GHC effectively attempt to //guess// whether a data type was declared using GADT syntax: 1. When reifying a data type in Template Haskell 2. When prettyprinting a data type (e.g., via `:info` in GHCi) But there's no need for heuristics here, since we have a 100% accurate way to determine whether a data type was declared using GADT syntax: the `isGadtSyntaxTyCon` function! By simply using that as the metric, we obtain far more accurate TH reification and prettyprinting results. This is technically a breaking change, since Template Haskell reification will now reify some data type constructors as `(Rec)GadtC` that it didn't before, and some data type constructors that were previously reified as `(Rec)GadtC` will no longer be reified as such. But it's a very understandable breaking change, since the previous behavior was simply incorrect. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #14167 Differential Revision: https://phabricator.haskell.org/D3901

Ryan Scott authored
Summary: GHC was allowing implicitly bidirectional pattern synonyms with bang patterns and irrefutable patterns in the RHS, like so: ```lang=haskell pattern StrictJust a = Just !a ``` This has multiple problems: 1. `Just !a` isn't a valid expression, so it feels strange to allow it in an implicitly bidirectional pattern synonym. 2. `StrictJust` doesn't provide the strictness properties one would expect from a strict constructor. (One could imagine a design where the `StrictJust` builder infers a bang pattern for its pattern variable, but accomplishing this inference in a way that accounts for all possible patterns on the RHS, including other pattern synonyms, is somewhat awkward, so we do not pursue this design.) We nip these issues in the bud by simply disallowing bang/irrefutable patterns on the RHS. Test Plan: make test TEST="T14112 unidir" Reviewers: simonpj, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #14112 Differential Revision: https://phabricator.haskell.org/D3896

Ryan Scott authored
Summary: I recently (re)discovered that `ForallC` quantifies different type variables depending on whether `GadtC` is present or not. This is an important enough gotcha where I feel like this fact should also be advertised in the `templatehaskell` documentation itself, so this patch does just that. Test Plan: Read it Reviewers: goldfire, austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13885 Differential Revision: https://phabricator.haskell.org/D3880

Herbert Valerio Riedel authored
This updates `transformers` from the v0.5.2 release to the v0.5.4 release + unreleased changes This is a prerequisite for the Semigroup=>Monoid implementation

 01 Sep, 2017 4 commits


Chris Martin authored

Ben Gamari authored
Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #14178 Differential Revision: https://phabricator.haskell.org/D3905

Ben Gamari authored
Test Plan: Added testcase in D3905. Reviewers: austin Subscribers: angerman, rwbarton, thomie GHC Trac Issues: #14178 Differential Revision: https://phabricator.haskell.org/D3904

Ben Gamari authored
While looking at #14171 I noticed these readability issues. Fix them.

 31 Aug, 2017 5 commits


Herbert Valerio Riedel authored
This is a followup to c0feee90

Herbert Valerio Riedel authored
This is a prerequisite for implementing the Semigroup/Monoid proposal. The instances have been introduced in a way to minimise warnings.

Simon Peyton Jones authored
I dug more into how #14158 started working. I temporarily reverted the patch that "fixed" it, namely commit a6c448b4 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Mon Aug 28 17:33:59 2017 +0100 Small refactor of getRuntimeRep Sure enough, there was a real bug, described in the new TcExpr Note [Visible type application zonk] In general, syntactic substituion should be kindpreserving! Maybe we should check that invariant...

Simon Peyton Jones authored

Simon Peyton Jones authored
We prettyprint a type by converting it to an IfaceType and prettyprinting that. But (a) that's a bit indirect, and (b) delibrately loses information about (e.g.) the kind on the /occurrences/ of a type variable So this patch implements debugPprType, which pretty prints the type directly, with no fancy formatting. It's just used for debugging. I took the opportunity to refactor the debugprettyprinting machinery a little. In particular, define these functions and use them: ifPprDeubug :: SDoc > SDOc > SDoc  Says what to do with and without dpprdebug whenPprDebug :: SDoc > SDoc  Says what to do with dpprdebug; without is empty getPprDebug :: (Bool > SDoc) > SDoc getPprDebug used to be called sdocPprDebugWith whenPprDebug used to be called ifPprDebug So a lot of files get touched in a very mechanical way

 30 Aug, 2017 3 commits


Simon Peyton Jones authored
All this Left/Right business was making my head spin, so I defined data HsArg tm ty = HsValArg tm  Argument is an ordinary expression (f arg)  HsTypeArg ty  Argument is a visible type application (f @ty) and used it. This is just simple refactor; no change in behaviour.

Simon Peyton Jones authored
These comments clarify the details of: commit 0257dacf Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Mon Aug 28 14:20:02 2017 +0100 Refactor bindHsQTyVars and friends

Simon Peyton Jones authored
I added these when investigating Trac #14163, but they'll be useful anyway.

 29 Aug, 2017 8 commits


Ben Gamari authored
I prematurely committed the D3892 before adding a Note. Fix this.

James Michael DuPont authored

Ben Gamari authored
We used to try a crude comparison of the type themselves, but this is essentially impossible in STG as we have discarded. both casts and type applications, so types might look different but be the same. Now we simply compare their runtime representations. See #14120. Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #14120 Differential Revision: https://phabricator.haskell.org/D3879

Ben Gamari authored
The unariser ensures that we never use case binders that are void, unboxed sums, or unboxed tuples. However, previously StgLint was enforcing this invariant even before the unariser was running, giving rise to spurious lint failures. Fix this. Following CoreLint, we introduce a LintFlags environment to the linter monad, allowing for additional flags to be easily accomodated in the future. See #14118. Test Plan: Build GHC with dstglint Reviewers: simonpj, austin Subscribers: rwbarton, thomie GHC Trac Issues: #14118 Differential Revision: https://phabricator.haskell.org/D3889

Ben Gamari authored
Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3887

Ben Gamari authored
There were a couple places where we indexed into linked lists of register names. Replace these with arrays. Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3893

Ben Gamari authored
Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #13945 Differential Revision: https://phabricator.haskell.org/D3874

Ben Gamari authored
Reviewers: austin, hvr Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3875
