GitLab

This implements SPJ's suggestion on the ticket (#14273). We find the
relevant constraints (ones that whose free unification variables are all
mentioned in the type of the hole), and then clone the free unification
variables of the hole and the relevant constraints. We then add a
subsumption constraints and run the simplifier, and then check whether
all the constraints were solved.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: RyanGlScott, rwbarton, thomie, carter

GHC Trac Issues: #14273

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

Reviewers: simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14665

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

Summary:
This code is quadratic and a simple test case I used
managed to tickle it.

The example (same one as #14667) looks like this:
```
module A10000 where

 data A = A
   | A00001
   | A00002
 ...
   | A10000

 f :: A -> Int
 f A00001 = 19900001
 f A00002 = 19900002
 ...
 f A10000 = 19910000
```

Applied on top of a fix for #14667, it gives a 30% compile time
improvement.

Test Plan: ./validate

Reviewers: simonpj, bgamari

Subscribers: rwbarton, thomie, simonmar, carter

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

Substitute RanlibCmd for consistency, and other configure cleanups that
should have no effect

The other commands are so substituted. Maybe we don't need ranlib at
all, and the configure snippet can be removed all together, but that
can always be done later.

Reviewers: bgamari, hvr, angerman

Reviewed By: bgamari, angerman

Subscribers: rwbarton, thomie, erikd, carter

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

Given that we have two unique keys (guaranteed by Map) checking that
`|range| == 1` is faster.

The fact that `x1 == lo` and `x2 == hi` is guaranteed by mkSwitchTargets
which removes values outside of the range.

Test Plan: ci

Reviewers: bgamari, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

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

On Windows GHC enforces currently that the real executable is named
ghc.exe/ghc-stage[123].exe.

I don't see a good reason why this is neccessary.
This patch removes this restriction and fixes #14652

Test Plan: ci

Reviewers: bgamari, Phyx

Reviewed By: Phyx

Subscribers: Phyx, rwbarton, thomie, carter

GHC Trac Issues: #14652

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

Trac #14646 happened because we forgot to parenthesize `forall` types to
the left of an arrow. This simple patch fixes that.

Test Plan: make test TEST=T14646

Reviewers: alanz, goldfire, bgamari

Reviewed By: alanz

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14646

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

This flag stops ghci creating the special variable `it`
after evaluating an expression. This stops ghci leaking
as much memory when evaluating expressions. See #14336

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14336

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

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14653

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

Reviewers: bgamari, goldfire

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

Subscribers: rwbarton, thomie, carter

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

`LIBRARY_PATH` is used to find libraries and other link artifacts while
`LD_LIBRARY_PATH` is used to find shared libraries by the loader.

Due to an implementation detail on Windows, using `LIBRARY_PATH` will
automatically add the path of any library found to the loader's path.

So in that case `LD_LIBRARY_PATH` won't be needed.

Test Plan:
./validate along with T14611 which has been made Windows only
due to linux using the system linker/loader by default. So I feel a
testcase there is unwarranted as the support is indirect via glibc.

Reviewers: hvr, bgamari, erikd, simonmar, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: RyanGlScott, rwbarton, thomie, carter

GHC Trac Issues: #14611

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

We currently always prefer shared libraries before import libraries and
static libraries. This is because they're faster to load. The problem is
when shared library are installed in the Windows directory. These would
supersede any user specified ones.

This is bad because e.g. Windows now ships icuuc, but an old version.
If you try to use -licuuc then it would pick the Windows one instead of
your user specified one.

This patch slighly tweaks the ordering so user paths get prefered.

Test Plan: ./validate

Reviewers: RyanGlScott, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14456

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

Distinguishing between "refutable" and "irrefutable" patterns
(as described by the Haskell Report) in incomplete pattern errors
was more confusing than helpful. Remove references to irrefutable
patterns.

Reviewers: hvr, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #14569

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

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

Reviewers: simonmar, erikd

Subscribers: rwbarton, thomie, carter

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

This adds support for adding Haddocks on individual non-record fields
of regular (and GADT) constructors. The following now parses just fine
with `-haddock` enabled:

data Foo
  = Baz             -- ^ doc on the `Baz` constructor
      Int           -- ^ doc on the `Int` field of `Baz`
      String        -- ^ doc on the `String` field of `Baz`

  | Int             -- ^ doc on the `Int` field of the `:*` constructor
      :*            -- ^ doc on the `:*` constructor
    String          -- ^ doc on the `String` field of the `:*`
constructor

  | Boa             -- ^ doc on the `Boa` record constructor
      { y :: () }

The change is backwards compatible: if there is only one doc and it
occurs
on the last field, it is lifted to apply to the whole constructor (as
before).

Reviewers: bgamari, alanz

Subscribers: rwbarton, thomie, mpickering, carter

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

When merging D4259 I had to resort to manual merge due to some conflicts that
arc couldn't sort out. Unfortunately in the process I merged the wrong version
of the patch. Fix this. Thanks to @ntc2 for the great documentation and noticing
my mistake.

when read notifications are requested, too (#13903)
Signed-off-by: Matthias Treydte <mt@waldheinz.de>

KQueue: Drop Bits/FiniteBits instances for Filter as they are really
constants whose bits should not be fiddled with
Signed-off-by: Matthias Treydte <mt@waldheinz.de>

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: gridaphobe, kazu_yamamoto, rwbarton, thomie

GHC Trac Issues: #13903

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

This recent patch
    commit 1577908f
    Author: Simon Peyton Jones <simonpj@microsoft.com>
    Date:   Tue Jan 9 16:20:46 2018 +0000

        Fix two more bugs in partial signatures

        These were shown up by Trac #14643

failed validation for typecheck/should_run/T10846
(Reported in Trac #14658.)

The fix is simple.

Before this change, for each constructor that we want
to allocate a tag for we would traverse a list of all
the constructors in a datatype to determine which tag
a constructor should get.

This is obviously quadratic and for datatypes with 10k
constructors it actually makes a big difference.

This change implements the plan outlined by @simonpj in
https://mail.haskell.org/pipermail/ghc-devs/2017-October/014974.html
which is basically about using a map and constructing it outside the
loop.

One place where things got a bit awkward was TysWiredIn.hs,
it would have been possible to just assign the tags by hand, but
that seemed error-prone to me, so I decided to go through a map
there as well.

Test Plan:
./validate
On a file with 10k constructors
Before:
   8,130,522,344 bytes allocated in the heap
  Total   time    3.682s  (  3.920s elapsed)
After:
   4,133,478,744 bytes allocated in the heap
  Total   time    2.509s  (  2.750s elapsed)

Reviewers: simonpj, bgamari

Reviewed By: simonpj

Subscribers: goldfire, rwbarton, thomie, simonmar, carter, simonpj

GHC Trac Issues: #14657

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

These were shown up by Trac #14643

Bug 1: if we had a single partial signature for
two functions
   f, g :: forall a. _ -> a
then we made two different SigTvs but with the sane Name.
This was jolly confusing and ultimately led to deeply bogus
results with Any's appearing in the resulting program. Yikes.
Fix: clone the quantified variables in TcSigs.tcInstSig (as
indeed its name suggests).

Bug 2: we were not eliminating duplicate/superclass constraints
in the partial signatures of a mutually recursive group.

Easy to fix: we are already doing dup/superclass elim in
TcSimplify.decideQuantification.  So we move the partial-sig
constraints there too.

When debugging Trac #14650, I found a place where we had

    let {-# INLINEABLE f #-}
        f = BIG
    in f 7

but 'f' wasn't getting inlined at its unique call site.
There's a good reason for that with INLINE things, which
should only inline when saturated, but not  for INILNEABLE
things.

This patch narrows the case where preInlineUnconditionally
gives up.  It significantly shortens (and improves) the code
for #14650.

This patch moves the "ok_unfolding" test
   from  CoreOpt.joinPointBinding_maybe
   to    OccurAnal.decideJoinPointHood

Previously the occurrence analyser was deciding to make
something a join point, but the simplifier was reversing
that decision, which made the decision about /other/ bindings
invalid.

Fixes Trac #14650.

The new comment explains why this warning can
legitimately fire, so I've removed it entirely.
Lint will cath any bad cases.

Summary: To be in line with the other typeNatTyCons

Reviewers: bgamari, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: RyanGlScott, rwbarton, thomie, carter

GHC Trac Issues: #14632

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

Summary:
get/setAllocationCounter didn't take into account allocations in the
current block. This was known at the time, but it turns out to be
important to have more accuracy when using these in a fine-grained
way.

Test Plan:
New unit test to test incrementally larger allocaitons.  Before I got
results like this:

```
+0
+0
+0
+0
+0
+4096
+0
+0
+0
+0
+0
+4064
+0
+0
+4088
+4056
+0
+0
+0
+4088
+4096
+4056
+4096
```

Notice how the results aren't always monotonically increasing.  After
this patch:

```
+344
+416
+488
+560
+632
+704
+776
+848
+920
+992
+1064
+1136
+1208
+1280
+1352
+1424
+1496
+1568
+1640
+1712
+1784
+1856
+1928
+2000
+2072
+2144
```

Reviewers: niteria, bgamari, hvr, erikd

Subscribers: rwbarton, thomie, carter

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

Commit fa8035e3 added `Div`
and `Mod` type families to `GHC.TypeNats`. However, they did not add
the corresponding fixities! Currently, we have that both `div` and
`mod` (at the value level) are `infixl 7`, so we should adopt the
same fixities for the type-level `Div` and `Mod` as well.

Test Plan: It compiles

Reviewers: hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14640

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

This one, discovered by Iceland Jack (Trac #14507), shows
that a pattern-bound coercion can show up in the argument
type(s) of the matcher of a pattern synonym.

The error message isn't great, but at least we now rightly
reject the program.

Just better layout in output for the user

Trac #14552 showed a very obscure case where we can't infer a
good pattern-synonym type.

The error message is horrible, but at least we no longer crash
and burn.

We were getting the stack trace printed twice in assertion
failures (e.g. see the Description of Trac #14552).

This fixes it, by deleting code.

(c.f. Trac #14635 which reports the same bug in documentation).

Trac #13032 pointed out that we sometimes generate unused
bindings for Givens, and (worse still) we can't always discard
them later (we don't drop a case binding unless we can prove
that the scrutinee is non-bottom.

It looks as if this may be a major reason for the performace
problems in #14338 (see comment:29).

This patch fixes the problem at source, by pruning away all the
dead Givens.  See Note [Delete dead Given evidence bindings]

Remarkably, compiler allocation falls by 23% in
perf/compiler/T12227!

I have not confirmed whether this change actualy helps with

This is a follow-up after faf60e85 - Make tagForCon non-linear.
On the mailing list @simonpj suggested to solve the
linear behavior by caching the sizes.

Test Plan: ./validate

Reviewers: simonpj, simonmar, bgamari, austin

Reviewed By: simonpj

Subscribers: carter, goldfire, rwbarton, thomie, simonpj

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

Summary:
`GeneralizedNewtypeDeriving` generates calls to `coerce`
which take visible type arguments. These types must be produced by
way of `typeToLHsType`, which converts a `Type` to an `LHsType`.
However, `typeToLHsType` was leaving off important kind information
when a `Type` contained a poly-kinded tycon application, leading to
incorrectly generated code in #14579.

This fixes the issue by tweaking `typeToLHsType` to generate
explicit kind signatures for tycon applications. This makes the
generated code noisier, but at least the program from #14579 now
works correctly.

Test Plan: make test TEST=T14579

Reviewers: simonpj, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14579

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

As Trac #14605 showed, we can't defer a type error under a
'forall' (when unifying two forall types).

The fix is simple.