- 03 Dec, 2018 7 commits
-
-
Arnaud Spiwack authored
Reviewers: goldfire, bgamari, tdammers Reviewed By: tdammers Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5399
-
Ryan Scott authored
At some point between 8.4 and 8.6, two things were fixed: * The entirety of #14451. * One of the test cases in #7503. I've added this as T7503a. The other test case from that ticket still does /not/ work, so we'll have to add T7503b some other day.
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
In the type checker Constraint and * are distinct; and the function that takes the kind of a type should respect that distinction (Trac #15971). This patch implements the change: * Introduce Type.tcTypeKind, and use it throughout the type inference engine * Add new Note [Kinding rules for types] for the kinding rules, especially for foralls. * Redefine isPredTy ty = tcIsConstraintKind (tcTypeKind ty) (it had a much more complicated definition before) Some miscellaneous refactoring * Get rid of TyCoRep.isTYPE, Kind.isTYPEApp, in favour of TyCoRep.kindRep, kindRep_maybe * Rename Type.getRuntimeRepFromKind_maybe to getRuntimeRep_maybe I did some spot-checks on compiler perf, and it really doesn't budge (as expected).
-
Ryan Scott authored
Summary: `pprParendType` was missing an explicit case for `EqualityT`, which caused it to fall through to a catch-all case that invokes `ppr`. But `ppr` itself does not have a case for a partial application of `EqualityT`, so //it// falls back to `pprParendType`, resulting in an infinite loop! The fix is simple: add a case for `EqualityT` in `pprParendType`. While I was in the neighborhood, I removed the catch-call case in `pprParendType` to make this sort of mistake less likely to happen in the future. Test Plan: make test TEST=T15985 Reviewers: bgamari, monoidal, simonpj Reviewed By: monoidal, simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15985 Differential Revision: https://phabricator.haskell.org/D5403
-
Ryan Scott authored
Summary: Previously, `check_type` (which catches illegal uses of unsaturated type synonyms without enabling `LiberalTypeSynonyms`, among other things) always checks for uses of polytypes before anything else. There is a problem with this plan, however: checking for polytypes requires decomposing `forall`s and other invisible arguments, an action which itself expands type synonyms! Therefore, if we have something like: ```lang=haskell type A a = Int type B (a :: Type -> Type) = forall x. x -> x type C = B A ``` Then when checking `B A`, `A` will get expanded to `forall x. x -> x` before `check_type` has an opportunity to realize that `A` is an unsaturated type synonym! This is the root cause of #15954. This patch fixes the issue by moving the case of `check_type` that detects polytypes to be //after// the case that checks for `TyConApp`s. That way, the `TyConApp` case will properly flag things like the unsaturated use of `A` in the example above before we ever attempt to check for polytypes. Test Plan: make test TEST=T15954 Reviewers: simonpj, bgamari, goldfire Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15954 Differential Revision: https://phabricator.haskell.org/D5402
-
Alec Theriault authored
Summary: These changes were motivated by #13256. While poking around, I realized we weren't very consistent in our "-Woverflowed-literals" warnings. This patch fixes that by: * warning earlier on in the pipeline (ie. before we've desugared 'Int' patterns into 'I# Int#') * handling 'HsLit' as well as 'HsOverLit' (this covers unboxed literals) * covering more pattern / expression forms 4/6 of the warnings in the 'Overflow' test are due to this patch. The other two are mostly for completeness. Also fixed a missing empty-enumeration warning for 'Natural'. This warnings were tripped up by the 'Bounded Word' instance (see #9505), but the fix was obvious and simple: use unboxed word literals. Test Plan: make TEST=Overflow && make TEST=T10930 Reviewers: hvr, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #13256, #10930 Differential Revision: https://phabricator.haskell.org/D5181
-
- 02 Dec, 2018 1 commit
-
-
Alp Mestanogullari authored
ghc-ci is a tiny webservice that acts as an intermediate between our CircleCI jobs on Gitlab and the actual builds running on CircleCI, so that the build script doesn't need to rely on any secret, which makes the whole setup fork-friendly. The concrete effect of this patch is to allow any fork of GHC on Gitlab to run CircleCI jobs.
-
- 01 Dec, 2018 6 commits
-
-
-
Ben Gamari authored
Git status is extremely expensive for this task. We instead use `git rev-parse HEAD` and throw away the output to ensure we don't spam the user.
-
Ben Gamari authored
-
Ben Gamari authored
-
Ben Gamari authored
Iserv is not supported on Windows. This fixes #15950 but this whole situation feels awfully fragile to me.
-
Alp Mestanogullari authored
And put it to use for running i386 and x86_64 linux validate, x86_64 darwin validate and building with hadrian. For all the validate jobs, we save the artifacts (bindist + test results for now) in Circle CI and subsequently grab them in Gitlab. The nice side effect is that merge requests now show the change in test results from the patches and let you download or browse the artifacts.
-
- 30 Nov, 2018 5 commits
-
-
David Eichmann authored
Reviewers: bgamari, tdammers, osa1 Reviewed By: tdammers Subscribers: osa1, tdammers, rwbarton, carter GHC Trac Issues: #15923 Differential Revision: https://phabricator.haskell.org/D5367
-
Sebastian Graf authored
Summary: Previously, the logic that checks whether a thunk has a counter or not was duplicated in multiple functions. This led to thunk enters being accounted to their enclosing functions in `StgCmmTicky.tickyEnterThunk`, because the outer call to `withNewTickyCounterThunk` didn't set the counter label for the thunk. And rightly so! `tickyEnterThunk` should only account thunk enters to a counter if `-ticky-dyn-thunk` is on. This patch extracts the logic that was already present in its most general form in `withNewTickyCounterThunk` into its own functions and lets all other call sites checking for `-ticky-dyn-thunk` call this new function named `thunkHasCounter` instead. Reviewers: bgamari, simonmar Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5392
-
Alec Theriault authored
Summary: Since 'NonEmpty' and 'Void' are now part of 'base', it makes sense that we put 'Lift' instances for them in 'template-haskell'. Not doing so is going to force users to define their own (possibly colliding) orphan instances downstream. Test Plan: ./validate Reviewers: goldfire, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15961 Differential Revision: https://phabricator.haskell.org/D5391
-
Simon Peyton Jones authored
-
Ryan Scott authored
This test output changed slightly due to commit 2257a86d (which is expected).
-
- 29 Nov, 2018 10 commits
-
-
Chaitanya Koparkar authored
Test Plan: make test TEST=T15962 Reviewers: RyanGlScott, bgamari Reviewed By: RyanGlScott Subscribers: rwbarton, carter GHC Trac Issues: #15962 Differential Revision: https://phabricator.haskell.org/D5393
-
Ryan Scott authored
Summary: Currently, `ghc-in-ghci` is hard-coded to only support the installation path of the `make`-based build system. There isn't a fundamental reason why this must be the case, however—it's just a matter of communicating which directories to look into. For the time being, I've hacked `utils/ghc-in-ghci/run.sh` to just check the default Hadrian installation path in addition to the `make` one. Disclaimer: I'm not well-versed in `bash`-fu, so it's possible that there is a better way to accomplish what I'm setting out to do. Suggestions welcome. Test Plan: ./utils/ghc-in-ghci/run.sh Reviewers: alpmestan, bgamari Reviewed By: alpmestan Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5390
-
Ryan Scott authored
Summary: Currently, Hadrian has restrictive upper bounds on `containers` and `QuickCheck` that prevents it from building with the latest versions of each respective library (0.6.0.1 and 2.12.6.1). There doesn't appear to be any good reason to do so, since Hadrian builds fine with them, so let's bump the upper version bounds accordingly. Test Plan: ./build/hadrian.sh Reviewers: bgamari, alpmestan, snowleopard Reviewed By: snowleopard Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5389
-
Chaitanya Koparkar authored
Summary: In some modules we directly dump the debugging output to STDOUT via 'putLogMsg', 'printInfoForUser' etc. However, if `-ddump-to-file` is enabled, that output should be written to a file. Easily fixed. Certain tests (T3017, Roles3, T12763 etc.) expect part of the output generated by `-ddump-types` to be in 'PprUser' style. However, generally we want all other debugging output to use 'PprDump' style. `traceTcRn` and `traceTcRnForUser` help us accomplish this. This patch also documents some missing flags in the users guide. Reviewers: RyanGlScott, bgamari, hvr Reviewed By: RyanGlScott Subscribers: rwbarton, carter GHC Trac Issues: #15953 Differential Revision: https://phabricator.haskell.org/D5382
-
Victor Nawothnig authored
Reviewers: hvr, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15930 Differential Revision: https://phabricator.haskell.org/D5379
-
mayac authored
Summary: Fix a bug in commit 12eeb9 which permits the following: ``` class C a where type T a b instance C (Maybe a) where type forall a b. T (Maybe a) b = b ``` where instead, the user should write: ``` instance C (Maybe a) where type forall b. T (Maybe a) b = b ``` Update the users guide to discuss scoping of type variables in explicit foralls in type family instances. Test Plan: validate Reviewers: bgamari, goldfire, monoidal Reviewed By: goldfire Subscribers: monoidal, rwbarton, carter GHC Trac Issues: #15828 Differential Revision: https://phabricator.haskell.org/D5283
-
Simon Peyton Jones authored
My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881
-
David Eichmann authored
* (#15837 point 5) Use the -rpath gcc option and using the $ORIGIN variable which the dynamic linker sets to the location of the ghc binary. * (#15837 point 4) "-fPIC -dynamic" options are used when building ghc when either ghc or the rts have a dynamic way. * (#15837 point 7) "-shared -dynload deploy" options are only used when linking a library (no longer when linking a program). Reviewers: bgamari, alpmestan Reviewed By: alpmestan Subscribers: adamse, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5281
-
Alp Mestanogullari authored
Previously, Hadrian was building all the appropriate dynamic ways for libHSrts but they were not picked up and installed in the package database when we register the rts library. Since we use Cabal for registering packages and the .cabal files of packages as sources of truth for configuring and installing, we ended up patching Cabal to add a new field, 'extra-dynamic-library-flavours', to specify those extra flavours to install in .cabal files: https://github.com/haskell/cabal/pull/5606 We now make use of this in rts.cabal.in to expose dynamic flavours behind a Cabal flag, which Hadrian will use whenever we are building a GHC flavour that requires dynamic libraries. This is all part of a larger plan to build a dynamic stage 2 GHC by default, like with make, which in turn will fix a lot of test failures. See Test Plan: hadrian/build.sh _build/stage1/lib/package.conf.d/rts-1.0.conf _build/stage1/lib/x86_64-.../ should contain many libHSrts-*.so Reviewers: snowleopard, DavidEichmann, bgamari, erikd, simonmar Reviewed By: snowleopard, DavidEichmann Subscribers: rwbarton, carter GHC Trac Issues: #15837 Differential Revision: https://phabricator.haskell.org/D5385
-
Simon Peyton Jones authored
This test seems to work in HEAD
-
- 28 Nov, 2018 2 commits
-
-
Simon Peyton Jones authored
-
Sebastian Graf authored
After reverting Phab:D5358, Simon (Peyton Jones) asked for a Note summarising why we want to keep the dead case binder check in `cgCase`. Summary from mail conversation: * Phab:D5324 means that we no longer /recompute/ dead-ness of case-binders in STG-land * But TidyPgm preserves dead-ness info (see CoreTidy.tidyIdBndr) * And so we can take advantage of it to avoid a redundant load. This load would be eliminated by CmmSink, but that only happens with -O
-
- 27 Nov, 2018 1 commit
-
-
Alp Mestanogullari authored
As outlined in #15925, hadrian bindists had not made a clear choice with respect to relocatable GHCs and wrapper scripts. This commit implements the policy described in the ticket. That is: - the bindists ship {bin, lib} as they are, modulo the addition of haddock from stage2/bin - we now _always_ generate wrapper scripts for all the programs that are in the bindist's bin/ directory The idea being that anyone on Linux/Windows/OS X can just unpack the binary distribution anywhere and start using bin/ghc, while the installation process systematicaly generates wrapper scripts. Test Plan: hadrian/build.sh binary-dist ; cd _build/bindist/ghc-X.Y.Z-arch/; configure --prefix=/tmp/foo && make install Reviewers: snowleopard, bgamari, angerman Reviewed By: snowleopard, bgamari, angerman Subscribers: rwbarton, carter GHC Trac Issues: #15925 Differential Revision: https://phabricator.haskell.org/D5371
-
- 26 Nov, 2018 5 commits
-
-
Ryan Scott authored
Summary: The iface pretty-printer had a special case for an application of an infix type constructor to two arguments. But this didn't take the visibilities of the arguments into account, which could lead to strange output like `@{LiftedRep} -> @{LiftedRep}` when `-fprint-explicit-kinds` was enabled (#15941). The fix is relatively straightforward: simply plumb through the visibilities of each argument, and only trigger the special case for infix applications if both arguments are visible (i.e., required). Test Plan: make test TEST=T15941 Reviewers: goldfire, bgamari, monoidal Reviewed By: goldfire, monoidal Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15941 Differential Revision: https://phabricator.haskell.org/D5375
-
Ryan Scott authored
Summary: Currently, the version numbers for `libiserv`, `iserv`, and `iserv-proxy` are hard-coded directly into their `.cabal` files. These are easy to forget to update, and in fact, this has already happened once (see #15866). Let's use `autoconf` to do this for us so that it is not forgotten in the future. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, erikd, carter GHC Trac Issues: #15866 Differential Revision: https://phabricator.haskell.org/D5302
-
Ryan Scott authored
Summary: When `-fprint-explicit-foralls` is enabled, type family equations are either printed without an explict `forall` entirely, or with a bizarre square bracket syntax (in the case of closed type families). I find neither satisfying, so in this patch, I introduce support for printing explicit `forall`s in open type-family, closed type-family, and data-family equations when appropriate. (By "when appropriate", I refer to the conditions laid out in `Note [When to print foralls]` in `IfaceType`.) One tricky point in the implementation is that I had to pick a visibility for each type variable in a `CoAxiom`/`FamInst` in order to be able to pass it to `pprUserIfaceForAll` //et al.// Because the type variables in a type family instance equation can't be instantiated by the programmer anyway, the choice only really matters for pretty-printing purposes, so I simply went with good ol' trustworthy `Specified`. (This design choice is documented in `Note [Printing foralls in type family instances]` in `IfaceType`.) Test Plan: make test TEST=T15827 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15827 Differential Revision: https://phabricator.haskell.org/D5282
-
Ömer Sinan Ağacan authored
CPP error introduced with b2950e03
-
Ömer Sinan Ağacan authored
This reverts commit d13b7d60. (See discussion in D5358)
-
- 25 Nov, 2018 1 commit
-
-
Ömer Sinan Ağacan authored
-
- 24 Nov, 2018 2 commits
-
-
Ben Gamari authored
-
Ben Gamari authored
This reverts commit 390df8b5.
-