This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git.
Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
- 17 Mar, 2017 7 commits
-
-
Richard Eisenberg authored
test cases: ghci/scripts/T13202{,a}
-
Richard Eisenberg authored
In an effort to report multiple levity polymorphism errors all at once, the desugarer does not fail when encountering bad levity polymorphism. But we must be careful not to build the bad applications, lest they try to satisfy the let/app invariant and call isUnliftedType on a levity polymorphic type. This protects calls to mkCoreAppDs appropriately. test case: typecheck/should_fail/T12709
-
Richard Eisenberg authored
-
Gabor Greif authored
-
Edward Z. Yang authored
Summary: I don't really know why this stopped working for me, but it did on a recent clean. I don't know if this is right but it solved the problem for me. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3318
-
Edward Z. Yang authored
Summary: This is required to make Haddock work correctly. Comes with a Haddock submodule update for better rendering. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3335
-
Test Plan: Validate Reviewers: hvr, austin, bgamari Reviewed By: hvr Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3353
-
- 16 Mar, 2017 1 commit
-
-
Ben Gamari authored
-
- 15 Mar, 2017 8 commits
-
-
Ben Gamari authored
-
Ben Gamari authored
-
Reviewers: austin, hvr, bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3345
-
Ben Gamari authored
Fixes #13388. Also updates the expected output for T12504, which previously contained a redundant LINE pragma.
-
This factors out the repetition of (log_action dflags dflags) and will hopefully allow us to someday better abstract log output. Test Plan: Validate Reviewers: austin, hvr, goldfire Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3334
-
This factors out a repeated pattern found in DynFlags, where we use an IntSet and Enum to represent sets of flags. Requires bump of haddock submodule. Test Plan: validate Reviewers: austin, goldfire Subscribers: rwbarton, thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3331
-
Since the introduction of -split-sections, using GHCi with the RTS linker is really slow: ``` $ time (echo :quit | ./inplace/bin/ghc-stage2 --interactive -fexternal-interpreter) GHCi, version 8.1.20170304: http://www.haskell.org/ghc/ :? for help Prelude> Leaving GHCi. real 0m3.793s ``` (when we use `-fexternal-interpreter` it uses the RTS linker by default, you can make it use the system linker by adding `-dynamic`) Building the GHCi libs doesn't take much time or space in the GHC build, but makes things much quicker for people using the RTS linker: ``` $ time (echo :quit | ./inplace/bin/ghc-stage2 --interactive -fexternal-interpreter) GHCi, version 8.1.20170304: http://www.haskell.org/ghc/ :? for help Prelude> Leaving GHCi. real 0m0.285s ``` So I propose that we build and ship them unconditionally. Test Plan: validate, perf tests above Reviewers: bgamari, austin, niteria, erikd, Phyx Reviewed By: bgamari Subscribers: rwbarton, thomie, snowleopard Differe...
-
Ben Gamari authored
This test has been fluctuating wildly recently. Moreover, it's not even clear to me that this is a particularly useful thing to be testing.
-
- 14 Mar, 2017 10 commits
-
-
`minusList ms ns` was `O(m*n)`. Now it's `O((m + n) log n)`, which should be a bit better. Reviewers: austin, bgamari, mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3341
-
`exprIsOk` didn't shortcut properly when checking `case` (it used `foldl` inappropriately). Fix that. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3343
-
The big change is the introduction of solveSomeEqualities. This is just like solveEqualities, but it doesn't fail if there are unsolved equalities when it's all done. Anything unsolved is re-emitted. This is appropriate if we are not kind-generalizing, so this new form is used when decideKindGeneralizationPlan says not to. We initially thought that any use of solveEqualities would be tied to kind generalization, but this isn't true. For example, we need to solveEqualities a bunch in the "tc" pass in TcTyClsDecls (which is really desugaring). These equalities are all surely going to be soluble (if they weren't the "kc" pass would fail), but we still need to solve them again. Perhaps if the "kc" pass produced type- checked output that is then desugared, solveEqualities really would be tied only to kind generalization. Updates haddock submodule. Test Plan: ./validate, typecheck/should_compile/T13337 Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3315
-
In Windows 10 Insiders build 15019+ which will probably be released mainstream somewhere this year Microsoft seems to have started being stricter with API calls. The call to `FreeConsole` just after `CreateProcess` is making Windows treat the process as an interactive process. In which case it tries to use the `Desktop session` but fails resulting in the cryptic error reported. I don't understand why the call to `FreeConsole` was there and it doesn't seem to be needed, so removed. This fixes #13411 Test Plan: ./validate, alternative just do anything with ghc which requires compilation. Reviewers: austin, bgamari, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3319
-
Ryan Scott authored
Summary: After 8136a5cb (#11450), if you have a class with an associated type: ``` class C a where type T a b ``` And you try to create an instance of `C` like this: ``` instance C Int where type T Int Char = Bool ``` Then it is rejected, since you're trying to instantiate the variable ``b`` with something other than a type variable. But this restriction proves quite onerous in practice, as it prevents you from doing things like this: ``` class C a where type T a (b :: Identity c) :: c instance C Int where type T Int ('Identity x) = x ``` You have to resort to an auxiliary type family in order to define this now, which becomes extremely tiring. This lifts this restriction and fixes #13398, in which it was discovered that adding this restriction broke code in the wild. Test Plan: ./validate Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3302
-
Ryan Scott authored
Summary: The section on `-XTypeApplications` in the users' guide isn't terribly clear on how to view the visibility of a function type signature's type variables in GHCi properly (i.e., using the `:type +v` GHCi command). This adds some more exposition that demonstrates how to use `:type +v` (and why you don't want to use `:type`). Fixes #13401. Test Plan: Eyeball it Reviewers: bgamari, austin, goldfire, crockeea Reviewed By: goldfire, crockeea Subscribers: rwbarton, thomie, crockeea Differential Revision: https://phabricator.haskell.org/D3310
-
Ben Gamari authored
Both the OS X build machine and my local builds have been failing. Unfortunately, our x86_64 Linux machine has been succeeding.
-
Test Plan: Validate Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3303
-
Simon Peyton Jones authored
In this commit commit 02ac2974 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Wed Nov 16 10:37:47 2011 +0000 Fix CaseIdentity optimisaion In fixing one bug I'd introduced another; case x of { T -> T; F -> F } wasn't getting optmised! Trivial to fix. I introduced yet another! This line of code in SimplUtils.mkCase1 check_eq (Var v) (DataAlt con) [] = v == dataConWorkId con -- Optimisation only is patently false when arg_tys is non-empty. Astonishing that it has not shown up before now. Easily fixed though. This was all shown up by Trac #13417, which is now fixed. Merge to 8.0, 8.2.
-
Gabor Greif authored
-
- 13 Mar, 2017 14 commits
-
-
Test Plan: No new test (bug is latent) Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3285
-
Ben Gamari authored
-
Ben Gamari authored
It seems I must have dropped the update of the expected value during a conflict resolution.
-
Ben Gamari authored
As previously documented (88f5add0) wc's output is inconsistent between Linux and BSDs. Use grep -c instead.
-
Ben Gamari authored
What was previously known as TypeRepX is now known as SomeTypeRep.
-
This fixes some idiosyncracies I noticed between `Data.Typeable` and `Type.Reflection`: * `showsTypeRep` (from `Data.Typeable`) had the type `SomeTypeRep -> ShowS`, despite the fact that `SomeTypeRep` isn't exported from `Data.Typeable`. I changed it to be `Data.Typeable.TypeRep -> ShowS`. * Similarly, `typeRepFingerprint` (reexported from `Data.Typeable`) had the type `SomeTypeRep -> Fingerprint`. I changed it to `Data.Typeable.TypeRep -> Fingerprint`. * `Type.Reflection` wasn't exporting `typeRepX` or `typeRepXFingerprint`, despite the fact that their counterparts were exported from `Data.Typeable`. `Type.Reflection` now exports them as well. * `withTypeable :: TypeRep (a :: k) -> (Typeable a => r) -> r` was being reexported from `Data.Typeable`. This is in spite of the fact that you can't actually use the type-indexed `TypeRep a` by importing `Data.Typeable` alone. I decided to remove this export from `Data.Typeable`. Reviewers: bgamari, austin, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3309
-
The I/O hack for demand analysis has broader and arguably more important implications than the note expressed. Broaden it. [skip ci] Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: carter, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3307
-
Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3312
-
Test Plan: validate Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3313
-
This commit adds a command line option to limit the number of errors displayed. It also moves the documentation for `reverse-errors` into the `Warnings` section. https://ghc.haskell.org/trac/ghc/ticket/13326 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3323
-
This corrects the line numbers for literate code after a shebang. Fixes #13414. Test Plan: validate Reviewers: austin, bgamari, trofi Reviewed By: bgamari, trofi Subscribers: trofi, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3333
-
I was initially confused when I read "zipWithn" in the haddock for ZipList, went looking for a function named "zipWithn", and found that it didn't exist. This expands the docs to clarify that we're referring to the family of functions [zipWith, zipWith3, zipWith4, ...], capitalizes the letter "n" in "zipWithN" in attempt to make that more readable, and gives an example. I also moved this documentation from ZipList itself to the Applicative instance, so that it will show up in both the Ziplist documentation and in the list of Applicative instances. Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3324
-
Reviewers: austin, hvr, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3325
-
Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3326
-