GitLab

test cases: ghci/scripts/T13202{,a}

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

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

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

Reviewers: austin, hvr, bgamari

Subscribers: rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3345

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

Differential Revision: https://phabricator.haskell.org/D3298

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.

`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

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

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

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

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.

Test Plan: No new test (bug is latent)

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3285

It seems I must have dropped the update of the expected value during a conflict
resolution.

As previously documented (88f5add0) wc's output
is inconsistent between Linux and BSDs. Use grep -c instead.

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