Tamar Christina authored 8 years ago and Ben Gamari committed 8 years ago

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.

Ben Gamari authored 8 years ago and Ben Gamari committed 8 years ago

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.

lukemaurer authored 8 years ago and Ben Gamari committed 8 years ago

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

Chris Martin authored 8 years ago and Ben Gamari committed 8 years ago

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Rufflewind authored 8 years ago and Ben Gamari committed 8 years ago

Test Plan: validate

Reviewers: bgamari, austin

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

coopercm authored 8 years ago and Ben Gamari committed 8 years ago

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

Rufflewind authored 8 years ago and Ben Gamari committed 8 years ago

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

Chris Martin authored 8 years ago and Ben Gamari committed 8 years ago

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

Chris Martin authored 8 years ago and Ben Gamari committed 8 years ago

Reviewers: austin, hvr, bgamari, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: RyanGlScott, rwbarton, thomie

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

Matthew Pickering authored 8 years ago and Ben Gamari committed 8 years ago

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

At long last fixes OS X build.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

I noticed some code in the wild that broke due to the validity checking
introduced in #13267, so we should be proactive and warn about it in the 8.2
release notes.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Fixes 32-bit validation

A very small refactoring

Trac #13381 showed that we were losing track of a wanted constraint
when simplifying the LHS constraints for a RULE.

This patch fixes it, makes the code a bit simpler, and better
documented.

In error messages like this
    • Couldn't match type ‘c’ with ‘f0 (a -> b)’
      ‘c’ is a rigid type variable bound by
        the type signature for:
          f :: ((a -> b) -> b) -> forall c. c -> a

we need to take case both to actually show that 'forall c',
and to make sure that its name lines with the 'c' in the
error message.

This has been shaky for some time, and this commit puts it on solid
ground.  See TcRnTypes: Note [SigSkol SkolemInfo]

The main changes are

* SigSkol gets an extra field that records the way in which the
  type signature was skolemised.

* The type in SigSkol is now the /un/-skolemised version

* pprSkolemInfo uses the info to make the tidy type line up
  nicely

Lots of error message wibbles!

TcSimplify.decideQuantification was doing the Wrong Thing when
"growing" the type variables to quantify over. We were trying to do
this on a tyvar set where we'd split off the dependent type varaibles;
and we just got it wrong.  A kind variable wasn't being generalised
properly, with confusing knock on consequences.

All this led to Trac #13371 and Trac #13393.

This commit tidies it all up:

* The type TcDepVars is renamed as CandidateQTvs;
  and splitDepVarsOfType to candidateQTyVarsOfType

* The code in TcSimplify.decideQuantification is simpler.
  It no longer does the tricky "grow" stuff over TcDepVars.
  Instead it use ordinary VarSets (thereby eliminating the
  nasty growThetaTyVarsDSet) and uses that to filter the
  result of candidateQTyVarsOfType.

* I documented that candidateQTyVarsOfType returns the type
  variables in a good order in which to quantify, and rewrote
  it to use an accumulator pattern, so that we would predicatably
  get left-to-right ordering.

In doing all this I also made UniqDFM behave a little more nicely:

* When inserting an element that is there already, keep the old tag,
  while still overwriting with the new value.

* This means that when doing udfmToList we get back elements in the
  order they were originally inserted, rather than in reverse order.

It's not a big deal, but in a subsequent commit I use it to improve
the order of type variables in inferred types.

All this led to a lot of error message wibbles:
 - changing the order of quantified variables
 - changing the order in which instances are listed in GHCi
 - changing the tidying of variables in typechecker erors

There's a submodule update for 'array' because one of its tests
has an error-message change.

I may not have associated all of them with the correct commit.

Trac #13394, comment:4 showed up another place where we were testing
for the representation of of a type; and it turned out to be a JoinId
which can be rep-polymorphic.

Just putting the test in the right places solves this easily.

See Note [Data con wrappers and unlifted types] in MkId.
We were being totally stupid!

See Trac #1600 comment:66

Noticed breakage as build failure on i386 freebsd build bot:
  http://haskell.inf.elte.hu/builders/freebsd-i386-head/1267/10.html



  ghc-stage1: panic! (the 'impossible' happened)
    (GHC version 8.1.20170310 for i386-portbld-freebsd):
      outOfLineCmmOp: MO_F64_Fabs not supported here

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Bumps haddock submodule

Replace `Data.Reflection` with `Type.Reflection`.