GitLab

Reviewers: austin, erikd, simonmar

Subscribers: rwbarton, thomie

GHC Trac Issues: #14096

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

Reviewers: austin

Subscribers: rwbarton, thomie

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

Summary: Fixes #8532

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #8532

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

Previously SetLevels.lvlMFE would fail to substitute in ticks, unlike
lvlExpr.  This lead to #13481. Fix this.

Test Plan: `make test TEST=T12622 WAY=ghci`

Reviewers: austin, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie

GHC Trac Issues: #13481

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

When doing profiling on startup time of ghci on Windows, both cold and
startup loading static LLVM libs, the profiler is showing a glaring red
spot on the division operation of the the hashStr function.

In fact profiling shows 14% of the time is spent hashing the keys.

So I am replacing the hash function with xxHash which is a very fast
non-crypto hash. It's faster than MurMurHash which node etc use.

It also passes SMHasher. I can provide if required the collected raw
data.  But from analysis done on the keys, xxHash does not introduce
more collisions than before, the amount splits seem about the same and
the distributions among the buckets are slightly more uniform than
before.

However the runtime dropped enough to remove the function completely
from the profiler's report.

There's also a noticeable improvement in responsiveness.

xxHash is BSD licensed and can be found
https://github.com/Cyan4973/xxHash

Test Plan: ./validate

Reviewers: austin, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13165

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

This fixes #12502 by using the `find` utility found by FP_PROG_FIND
instead of the first one in PATH.

Test Plan: Validate on Windows

Reviewers: Phyx, austin, hvr

Reviewed By: Phyx

Subscribers: rwbarton, thomie, erikd

GHC Trac Issues: #12502

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

The script appears to use the local keyword, which I'm fairly certain is
a feature of bash and not sh.

Reviewers: Phyx, austin

Reviewed By: Phyx

Subscribers: rwbarton, thomie

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

`RnTypes` contains a fairly intricate algorithm to extract
the kind and type variables of an HsType. This algorithm carefully
maintains the separation between type variables and kind variables
so that the difference between `-XPolyKinds` and `-XTypeInType` can
be respected.

But after doing all this, `rmDupsInRdrTyVars` stupidly just
concatenated the lists of type and kind variables at the end. If a
variable were used as both a type and a kind, the algorithm would
produce *both*! This led to all kinds of problems, including #13988.

This is mostly Richard Eisenberg's patch. The only original
contribution I made was adapting call sites of `rnImplicitBndrs` to
work with the new definition of `rmDupsInRdrTyVars`. That is,
`rnImplicitBndrs` checks for variables that are illegally used in
both type and kind positions without using `-XTypeInType`, but in
order to check this, one cannot have filtered duplicate variables out
before passing them to `rnImplicitBndrs`. To accommodate for this, I
needed to concoct variations on the existing `extract-` functions in
`RnTypes` which do not remove duplicates, and use those near
`rnImplicitBndrs` call sites.

test case: ghci/scripts/T13988

Test Plan: make test TEST=T13988

Reviewers: goldfire, simonpj, austin, bgamari

Reviewed By: goldfire, simonpj

Subscribers: rwbarton, thomie

GHC Trac Issues: #13988

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

This is another take on https://phabricator.haskell.org/D3844.

This patch removes then need for haddock to reimplement the calculation
of exported names from modules. Instead when renaming export lists ghc
annotates each IE with its exported names.

Haddocks current  export logic has caused lots of trouble in the past
(on the Github issue tracker):
  - https://github.com/haskell/haddock/issues/121
  - https://github.com/haskell/haddock/issues/174
  - https://github.com/haskell/haddock/issues/225
  - https://github.com/haskell/haddock/issues/344
  - https://github.com/haskell/haddock/issues/584
  - https://github.com/haskell/haddock/issues/591
  - https://github.com/haskell/haddock/issues/597

Updates haddock submodule.

Reviewers: austin, bgamari, ezyang

Reviewed By: bgamari, ezyang

Subscribers: rwbarton, thomie

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

It's not impossible that this will also get caught by another test given
a suitably configured compiler, but this is minimal enough that it seems
worth including.

Test Plan: Validate with `DYNAMIC_GHC_PROGRAMS=NO`

Reviewers: austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #14129

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

Test Plan: Run `make test WAY=prof`

Reviewers: angerman, austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #14181

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

This is a preparatory refactoring for Semigroup=>Monoid
as it prevents a messy .hs-boot file which would interact
inconveniently with the buildsystem...

Summary:
Some code that @dfeuer was writing implicitly depended on these laws,
but they didn't appear to be enshrined in the Haddocks. Let's do so.

Test Plan: Read it

Reviewers: austin, hvr, bgamari, dfeuer

Reviewed By: dfeuer

Subscribers: rwbarton, thomie, dfeuer

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

Summary:
Two places in GHC effectively attempt to //guess// whether a data type
was declared using GADT syntax:

1. When reifying a data type in Template Haskell
2. When pretty-printing a data type (e.g., via `:info` in GHCi)

But there's no need for heuristics here, since we have a 100% accurate way to
determine whether a data type was declared using GADT syntax: the
`isGadtSyntaxTyCon` function! By simply using that as the metric, we obtain
far more accurate TH reification and pretty-printing results.

This is technically a breaking change, since Template Haskell reification will
now reify some data type constructors as `(Rec)GadtC` that it didn't before,
and some data type constructors that were previously reified as `(Rec)GadtC`
will no longer be reified as such. But it's a very understandable breaking
change, since the previous behavior was simply incorrect.

Test Plan: ./validate

Reviewers: simonpj, goldfire, austin, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie

GHC Trac Issues: #14167

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

Summary:
GHC was allowing implicitly bidirectional pattern synonyms with bang
patterns and irrefutable patterns in the RHS, like so:

```lang=haskell
pattern StrictJust a = Just !a
```

This has multiple problems:

1. `Just !a` isn't a valid expression, so it feels strange to allow it in an
   implicitly bidirectional pattern synonym.
2. `StrictJust` doesn't provide the strictness properties one would expect
   from a strict constructor. (One could imagine a design where the
   `StrictJust` builder infers a bang pattern for its pattern variable, but
   accomplishing this inference in a way that accounts for all possible
   patterns on the RHS, including other pattern synonyms, is somewhat
   awkward, so we do not pursue this design.)

We nip these issues in the bud by simply disallowing bang/irrefutable patterns
on the RHS.

Test Plan: make test TEST="T14112 unidir"

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie

GHC Trac Issues: #14112

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

Summary:
I recently (re-)discovered that `ForallC` quantifies different type variables
depending on whether `GadtC` is present or not. This is an important
enough gotcha where I feel like this fact should also be advertised in the
`template-haskell` documentation itself, so this patch does just that.

Test Plan: Read it

Reviewers: goldfire, austin, bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13885

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

This updates `transformers` from the v0.5.2 release to the
v0.5.4 release + unreleased changes

This is a pre-requisite for the Semigroup=>Monoid implementation

Reviewers: austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #14178

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

Test Plan: Added testcase in D3905.

Reviewers: austin

Subscribers: angerman, rwbarton, thomie

GHC Trac Issues: #14178

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

While looking at #14171 I noticed these readability issues. Fix them.

This is a follow-up to c0feee90

This is a pre-requisite for implementing the Semigroup/Monoid proposal.
The instances have been introduced in a way to minimise warnings.

I dug more into how #14158 started working. I temporarily reverted the
patch that "fixed" it, namely

    commit a6c448b4
    Author: Simon Peyton Jones <simonpj@microsoft.com>
    Date:   Mon Aug 28 17:33:59 2017 +0100

    Small refactor of getRuntimeRep

Sure enough, there was a real bug, described in the new
TcExpr Note [Visible type application zonk]

In general, syntactic substituion should be kind-preserving!
Maybe we should check that invariant...

We pretty-print a type by converting it to an IfaceType and
pretty-printing that.  But
 (a) that's a bit indirect, and
 (b) delibrately loses information about (e.g.) the kind
      on the /occurrences/ of a type variable

So this patch implements debugPprType, which pretty prints
the type directly, with no fancy formatting.  It's just used
for debugging.

I took the opportunity to refactor the debug-pretty-printing
machinery a little.  In particular, define these functions
and use them:

  ifPprDeubug :: SDoc -> SDOc -> SDoc
    -- Says what to do with and without -dppr-debug
  whenPprDebug :: SDoc -> SDoc
    -- Says what to do with  -dppr-debug; without is empty
  getPprDebug :: (Bool -> SDoc) -> SDoc

getPprDebug used to be called sdocPprDebugWith
whenPprDebug used to be called ifPprDebug

So a lot of files get touched in a very mechanical way

All this Left/Right business was making my head spin, so I defined

data HsArg tm ty
  = HsValArg tm   -- Argument is an ordinary expression     (f arg)
  | HsTypeArg  ty -- Argument is a visible type application (f @ty)

and used it.  This is just simple refactor; no change in behaviour.

These comments clarify the details of:

  commit 0257dacf
  Author: Simon Peyton Jones <simonpj@microsoft.com>
  Date:   Mon Aug 28 14:20:02 2017 +0100

      Refactor bindHsQTyVars and friends

I added these when investigating Trac #14163, but they'll be
useful anyway.

I prematurely committed the D3892 before adding a Note. Fix this.

We used to try a crude comparison of the type themselves, but this is
essentially impossible in STG as we have discarded. both casts and type
applications, so types might look different but be the same.  Now we
simply compare their runtime representations.

See #14120.

Reviewers: austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #14120

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

The unariser ensures that we never use case binders that are void,
unboxed sums, or unboxed tuples. However, previously StgLint was
enforcing this invariant even before the unariser was running, giving
rise to spurious lint failures.  Fix this. Following CoreLint, we
introduce a LintFlags environment to the linter monad, allowing for
additional flags to be easily accomodated in the future.

See #14118.

Test Plan: Build GHC with -dstg-lint

Reviewers: simonpj, austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #14118

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

Reviewers: austin

Subscribers: rwbarton, thomie

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

There were a couple places where we indexed into linked lists of
register names.  Replace these with arrays.

Reviewers: austin

Subscribers: rwbarton, thomie

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

Reviewers: austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #13945

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

Reviewers: austin, hvr

Subscribers: rwbarton, thomie

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

As pointed out in #13945, some filesystems only allow allow exclusive
locks if the fd being locked was opened for write access. This causes
ghc-pkg to fail as it first attempts to open and exclusively lock its
lockfile in read-only mode to accomodate package databases for which we
lack write permissions (e.g.  global package databases).

Instead, we now try read-write mode first, falling back to read-only
mode if this fails.

Reviewers: austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #13945

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

Summary:
This tool can be used to generate dll's for any list of object files
given to it. It will then repartition them automatically to fit within
a dll and generates as many dll's as needed to do this. Cyclic dependencies
between these generated dlls are handle automatically so there is no need
to tell it how to partition.

It is also a lot more general than `dll-split` as it is able to split any
package not just `libGHC`. It also uses a trick using GNU style import libraries
to hide the splitting from the rest of the pipeline. Which means come linking time
you don't need to know which dll contains what symbol or how many split dlls were
created.

The import libraries are by default created with libtool. However since libtool is BFD
based it is very slow. So if present and detected by configure the `genlib` tool
from the msys2 project is used. This makes a difference of about ~45 minutes when compiling.

To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`.

More detailed explaination of the process can be found here
https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking

Test Plan: ./validate

Reviewers: austin, hvr, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force

GHC Trac Issues: #5987

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

Summary:
Fix the path decomposition error that occurs when the Symlink resolver
fails. `Win32.try` throws an exception, so catch it and assume the path
isn't a symlink to use the old behavior.

Test Plan: ./validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #14159

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