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`.

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

Test Plan: Validate

Reviewers: austin, hvr, RyanGlScott

Subscribers: rwbarton, thomie

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

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

@rwbarton pointed out that this could be an issue during review, but I
assumed from my point sample of three test builds that this wouldn't be
necessary.  Sadly, none of these builds were on Windows, which indeed
does fail.

Strangely, only Simon and Harbormaster have been able to replicate the
issue (which apparently manifests as libffi thinking it's building for
unix).  I've been completely unable to replicate the failure in my own
builds, neither locally nor on the Harbormaster machine.

Test Plan: Validate on Windows

Reviewers: austin, Phyx, hvr

Reviewed By: Phyx

Subscribers: thomie, rwbarton, erikd

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

They were `expect_broken` without any output. Add the actual
output and remove the `expect_broken`.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

This reverts commit 5dce2160 as it
didn't build.

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

The .cstring.* sections don't get merged by the linker (bfd or gold).
That's bad, and especially bad in #13265 where it caused the number of
sections to exceed what is apparently an internal limit in ld.bfd.

Test Plan:
I can only test this on Linux, and I am guessing at what
the correct behavior is on Mac OS and Windows (and AIX I suppose).
Testers on other platforms would be much appreciated, though I
understand that the LLVM backend is broken on Mac OS currently for
other reasons (#13378).

Reviewers: olsner, austin, xnyhps, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

Make `raiseIO#` produce `topRes` instead of `ExnRes`. `ExnRes` leads to
demand analysis being too aggressive, IMO, allowing imprecise exceptions
produced by `throw` to replace exceptions thrown by `throwIO` that
would like to think of as precise.

This fixes that, but is certanly much more conservative than we would
ideally like. Let's see how bad it is.

Fixes Trac #13380

Reviewers: austin, bgamari

Subscribers: rwbarton, thomie

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

This fixes fetching of signatures and sources for inconsistently named msys2
tarballs.

to amend 2fa44217.

This pulls out the hashes into a separate file, making them far easier to
update.

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

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: RyanGlScott, rwbarton, thomie

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

Build failed as:
  libraries/base/GHC/Event/KQueue.hsc:192:25: error:
      Not in scope: type constructor or class ‘Int16’
      |
  192 | newtype Filter = Filter Int16
      |                         ^^^^^

If was caused by an import tweak from Word16 to Int16.
Adjust imports to make KQueue compile cleanly.

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

Test Plan: build on freebsd

Reviewers: bgamari, austin, hvr

Subscribers: rwbarton, thomie

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

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

The main goal is to easily allow the inline-c project (and
similar projects such as inline-java) to emit C/C++ files to
be compiled and linked with the current module.

Moreover, `addCStub` is removed, since it's quite fragile. Most
notably, the C stubs end up in the file generated by
`CodeOutput.outputForeignStubs`, which is tuned towards
generating a file for stubs coming from `capi` and Haskell-to-C
exports.

Reviewers: simonmar, austin, goldfire, facundominguez, dfeuer, bgamari

Reviewed By: dfeuer, bgamari

Subscribers: snowleopard, rwbarton, dfeuer, thomie, duncan, mboes

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

This was broken in the ecb880ca.

* Fix demand analysist for `catchSTM#`.

* Add more notes on demand analysis of `catch`-like functions.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

It's ok to have a levity-polymorphic join point, thus
   let j :: r :: TYPE l = blah
   in ...

Usually we don't allow levity-polymorphic binders, but join points
are different because they are not first class.  I updated the
invariants in CoreSyn.

This commit fixes Trac #13394.

Summary: This fixes the Windows build after the latest -Werror patches landed.

Test Plan: ./validate

Reviewers: austin, bgamari

Subscribers: rwbarton, thomie

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

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

As far as I can tell we were unnecessarily building a new TcgEnv when we
already had one on hand. TcRnMonad now sports an initTcWithGbl function,
which allows us to run a TcM monad in the context of this TcgEnv. This
appears to simplify things nicely.

Test Plan: Validate

Reviewers: austin

Subscribers: dfeuer, simonpj, thomie

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

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

This is just a bit of reorganization, pulling out the DPH things into a
separate section of the file.

Test Plan: Validate

Reviewers: austin

Subscribers: thomie

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

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

We can no longer use the mtime of the containing directory since it now
contains a lock file in addition to the .cache and .conf files.

Fixes #13375.

Test Plan: Validate on Windows

Reviewers: austin, arybczak

Subscribers: rwbarton, thomie

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

I checked both the FreeBSD and Darwin manpages; it's signed in both cases.
This was producing validation failures on OS X due to the new literal
range-check.

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

Currently we have this in libraries/base/GHC/Float.hs:
```
abs x | x == 0    = 0 -- handles (-0.0)
      | x >  0    = x
      | otherwise = negateFloat x
```
But 3-4 years ago it was noted that this was inefficient:
https://mail.haskell.org/pipermail/libraries/2013-April/019690.html

We can generate better code for X86 and llvm and for others generate 
some custom cmm code which is similar to what the compiler generates 
now.

Reviewers: austin, simonmar, hvr, bgamari

Reviewed By: bgamari

Subscribers: dfeuer, thomie

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

It relies on System.Posix.DynamicLinker, which is not available.

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

This resolves #13130. It's not entirely clear to me why we don't use an
unboxed tuple here but this is at least better than the status quo.

[skip ci]

Test Plan: Read it

Reviewers: simonmar, austin, dfeuer

Reviewed By: dfeuer

Subscribers: dfeuer, rwbarton, thomie

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

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

This is a rather stupid mangler hack. However, when using prefix data
with llvm, on systems that support -dead_strip (macOS, iOS), the prefix
data is stipped.

llvm generiously adds .subsections_via_symbols for macho in any case.

Thus we use our trusted mangler to drop the .subsections_via_symbols
line from the assembly.

This ultimately means that for (macOS, llvm), and (iOS, llvm) will not
benefit from -dead_strip. Yet, this patch will allow building ghc on
macOS again.

Test Plan: build ghc with llvm on macOS

Reviewers: rwbarton, bgamari, austin

Reviewed By: rwbarton, bgamari

Subscribers: thomie

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