Commit 08073e16 (#11066) ended up
fixing these, fortunately enough.

as helpfully reported by elpinal (#15217).

Currently, we parse both the **integral literal** value and the patterns
as `OverLit HsIntegral`.  For example:

```
  case 0::Int of
      0 -> putStrLn "A"
      1 -> putStrLn "B"
      _ -> putStrLn "C"
```

When checking the exhaustiveness of pattern matching, we translate the
`0` in value position as `PmOLit`, but translate the `0` and `1` in
pattern position as `PmSLit`. The inconsistency leads to the failure of
`eqPmLit` to detect the equality and report warning of "Pattern match is
redundant" on pattern `0`, as reported in #14546. In this patch we
remove the specialization of `OverLit` patterns, and keep the overloaded
number literal in pattern as it is to maintain the consistency.  Now we
can capture the exhaustiveness of pattern `0` and the redundancy of
pattern `1` and `_`.

For **string literals**, we parse the string literals as `HsString`.
When  `OverloadedStrings` is enabled, it further be turned as `HsOverLit
HsIsString`, whether it's type is `String` or not. For example:

```
  case "foo" of
      "foo" -> putStrLn "A"
      "bar" -> putStrLn "B"
      "baz" -> putStrLn "C"
```

Previously, the overloaded string values are translated to `PmOLit` and
the non-overloaded string values are translated to `PmSLit`. However the
string patterns, both overloaded and non-overloaded, are translated to
list of characters. The inconsistency leads to wrong warnings about
redundant and non-exhaustive pattern matching warnings, as reported
in #14546.

In order to catch the redundant pattern in following case:

```
  case "foo" of
      ('f':_) -> putStrLn "A"
      "bar" -> putStrLn "B"
```

In this patch, we translate non-overloaded string literals, both in
value position and pattern position, as list of characters. For
overloaded string literals, we only translate it to list of characters
only when it's type is `stringTy`, since we know nothing about the
`toString` methods.  But we know that if two overloaded strings are
syntax equal, then they are equal. Then if it's type is not `stringTy`,
we just translate it to `PmOLit`. We can still capture the
exhaustiveness of pattern `"foo"` and the redundancy of pattern `"bar"`
and `"baz"` in the following code:

```
{-# LANGUAGE OverloadedStrings #-}
main = do
  case "foo" of
      "foo" -> putStrLn "A"
      "bar" -> putStrLn "B"
      "baz" -> putStrLn "C"
```

Test Plan: make test TEST="T14546"

Reviewers: bgamari, simonpj

Reviewed By: bgamari, simonpj

Subscribers: simonpj, thomie, carter

GHC Trac Issues: #14546

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

Allows to align CmmProcs at the given boundries.

It makes performance usually worse but can be helpful
to limit the effect of a unrelated function B becoming
faster/slower after changing function A.

Test Plan: ci, using it.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15148

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

Alanas Plascinskas authored 6 years ago and Ben Gamari committed 6 years ago

Reviewers: mpickering, goldfire, bgamari

Reviewed By: mpickering

Subscribers: goldfire, rwbarton, thomie, carter

GHC Trac Issues: #15017

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

Tobias Dammers authored 6 years ago and Ben Gamari committed 6 years ago

With GADTs, it is possible to write programs such that the type
constraints make some code branches inaccessible.

Take, for example, the following program ::

    {-# LANGUAGE GADTs #-}

    data Foo a where
     Foo1 :: Foo Char
     Foo2 :: Foo Int

    data TyEquality a b where
            Refl :: TyEquality a a

    checkTEQ :: Foo t -> Foo u -> Maybe (TyEquality t u)
    checkTEQ x y = error "unimportant"

    step2 :: Bool
    step2 = case checkTEQ Foo1 Foo2 of
             Just Refl -> True -- Inaccessible code
             Nothing -> False

Clearly, the `Just Refl` case cannot ever be reached, because the `Foo1`
and `Foo2` constructors say `t ~ Char` and `u ~ Int`, while the `Refl`
constructor essentially mandates `t ~ u`, and thus `Char ~ Int`.

Previously, GHC would reject such programs entirely; however, in
practice this is too harsh. Accepting such code does little harm, since
attempting to use the "impossible" code will still produce errors down
the chain, while rejecting it means we cannot legally write or generate
such code at all.

Hence, we turn the error into a warning, and provide
`-Winaccessible-code` to control GHC's behavior upon encountering this
situation.

Test Plan: ./validate

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #11066

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

As observed in #14059 (starting at comment 5), the error
messages surrounding a program involving GADTs and a `COMPLETE` set
became worse between 8.2 and 8.4. The culprit was a new validity
check in 8.4 which filters out `COMPLETE` set candidates if a return
type of any conlike in the set doesn't match the type of the
scrutinee. However, this check was too conservative, since it removed
perfectly valid `COMPLETE` sets that contained GADT constructors,
which quite often have return types that don't match the type of a
scrutinee.

To fix this, I adopted the most straightforward possible solution of
only performing this validity check on //pattern synonym//
constructors, not //data// constructors.

Note that this does not fix #14059 entirely, but instead simply fixes
a particular buglet that was discovered in that ticket.

Test Plan: make test TEST=T14059

Reviewers: bgamari, mpickering

Reviewed By: mpickering

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14059

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

For some reason, it seems that the `ConstraintKinds` commit
introduced `~#` into Haskell syntax, in a pretty broken manner.
Unless and until we have an actual story for unboxed equality,
it doesn't make sense to expose it. Moreover, the way it was
donet was wrong enough and small enough that it will probably be
easier to start over if we do that. Yank it out.

Reviewers: bgamari, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: RyanGlScott, rwbarton, thomie, mpickering, carter

GHC Trac Issues: #15209

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

Tobias Dammers authored 6 years ago and Ben Gamari committed 6 years ago

When inferring the correct abi-depends, we now look at all the package
databases in the stack, up to and including the current one, because
these are the ones that the current package can legally depend on. While
doing so, we will issue warnings:

- In verbose mode, we warn about every package that declares
  abi-depends:, whether we actually end up overriding them with the
  inferred ones or not ("possibly broken abi-depends").

- Otherwise, we only warn about packages whose declared abi-depends
  does not match what we inferred ("definitely broken abi-depends").

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14381

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

Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

When we attempt to reserve the heap, we query the system's rlimit to
establish the starting point for our search over sizes.

Test Plan: Validate

Reviewers: erikd, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14492

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

This changes an obscure error (which mistakenly mentions
Template Haskell) to one that makes more sense.

Test Plan: make test TEST=T15214

Reviewers: bgamari, mpickering

Reviewed By: bgamari, mpickering

Subscribers: mpickering, rwbarton, thomie, carter

GHC Trac Issues: #15214

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

This gives us `One x` instead of `Many (x : [])` reducing overhead.
For compiling spectral/simple with -O0 difference was ~ -0.05%
allocations.

The only drawback is that something like toOL (x:panic "") will now
panic.  But that seems like a reasonable tradeoff.

Test Plan: ci, looking at +RTS -s

Reviewers: bgamari, jmct

Reviewed By: bgamari

Subscribers: jmct, rwbarton, thomie, carter

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

The error message that GHC emits from underdetermined CUSKs
is rather poor, since:

1. It may print an empty list of user-written variables if there
    are none in the declaration.
2. It may not mention any `forall`-bound, underdetermined
    variables in the result kind.

To resolve these issues, this patch:

1. Doesn't bother printing a herald about user-written
    variables if there are none.
2. Prints the result kind to advertise any
    underdetermination it may exhibit.

Test Plan: make test TEST=T13777

Reviewers: goldfire, bgamari

Reviewed By: goldfire

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #13777

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

lazac authored 6 years ago and Ben Gamari committed 6 years ago

Extend GHC plugins to access parsed, type checked representation,
interfaces that are loaded. And splices that are evaluated. The goal is
to enable development tools to access the GHC representation in the
pre-existing build environment.

See the full proposal here:
https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal

Reviewers: goldfire, bgamari, ezyang, angerman, mpickering

Reviewed By: mpickering

Subscribers: ezyang, angerman, mpickering, ulysses4ever, rwbarton, thomie, carter

GHC Trac Issues: #14709

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

Haskeline doesn't have its upper bound lifted yet.

Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

This feature has some very serious correctness issues (#14310),
introduces a great deal of complexity, and hasn't seen wide usage.
Consequently we are removing it, as proposed in Proposal #77 [1]. This
is heavily based on a patch from fryguybob.

Updates stm submodule.

[1] https://github.com/ghc-proposals/ghc-proposals/pull/77

Test Plan: Validate

Reviewers: erikd, simonmar, hvr

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14310

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

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

Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

Poor DPH and its vectoriser have long been languishing; sadly it seems there is
little chance that the effort will be rekindled. Every few years we discuss
what to do with this mass of code and at least once we have agreed that it
should be archived on a branch and removed from `master`. Here we do just that,
eliminating heaps of dead code in the process.

Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
`primitive` submodules.

Test Plan: Validate

Reviewers: simonpj, simonmar, hvr, goldfire, alanz

Reviewed By: simonmar

Subscribers: goldfire, rwbarton, thomie, mpickering, carter

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

admock authored 6 years ago and Ben Gamari committed 6 years ago

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15212

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

Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

The worker/wrapper transform needs to determine the levity of the result to
determine whether it needs to introduce a lambda to preserve laziness of the
result. For this is previously used isUnliftedType. However, this may fail in
the presence of levity polymorphism.

We now instead use isLiftedType_maybe, assuming that a lambda is needed if the
levity of the result cannot be determined.

Fixes #15186.

Test Plan: make test=T15186

Reviewers: simonpj, goldfire, tdammers

Reviewed By: simonpj

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15186

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

Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

Summary: Currently broken.

Test Plan: Validate

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15186

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

* Use toBlockList instead of revPostorder.

    Block elimination works on a given Cmm graph by:
     * Getting a list of blocks.
     * Looking for duplicates in these blocks.
     * Removing all but one instance of duplicates.

    There are two (reasonable) ways to get the list of blocks.
     * The fast way: `toBlockList`
       This just flattens the underlying map into a list.
     * The convenient way: `revPostorder`
       Start at the entry label, scan for reachable blocks and return
       only these. This has the advantage of removing all dead code.

    If there is dead code the later is better. Work done on unreachable
    blocks is clearly wasted work. However by the point we run the
    common block elimination pass the input graph already had all dead code
    removed. This is done during control flow optimization in
    CmmContFlowOpt which is our first Cmm pass.

    This means common block elimination is free to use toBlockList
    because revPostorder would return the same blocks. (Although in
    a different order).

* Change the triemap used for grouping by a label list
  from `(TM.ListMap UniqDFM)` to `ListMap (GenMap LabelMap)`.

    * Using GenMap offers leaf compression. Which is a trie
      optimization described by the Note [Compressed TrieMap] in
      CoreSyn/TrieMap.hs

    * Using LabelMap removes the overhead associated with UniqDFM.

  This is deterministic since if we have the same input keys the same
  LabelMap will be constructed.

Test Plan: ci, profiling output

Reviewers: bgamari, simonmar

Reviewed By: bgamari

Subscribers: dfeuer, thomie, carter

GHC Trac Issues: #15103

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

Noticed section mismatch on UNREG build failure:

```
  HC [stage 1] libraries/integer-gmp/dist-install/build/GHC/Integer/Type.o

     error: conflicting types for 'ufu0_srt'
     static StgWord ufu0_srt[]__attribute__((aligned(8)))= {
                    ^~~~~~~~

     note: previous declaration of 'ufu0_srt' was here
     IRO_(ufu0_srt);
          ^~~~~~~~
```

`IRO_` is a 'const' qualifier.

The error is a leftover from commit 838b6903
"Merge FUN_STATIC closure with its SRT" where part of SRT was moved
into closure itself and made SRTs writable.

This change puts all SRTs into writable section.

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

Reviewers: simonmar, bgamari

Subscribers: rwbarton, thomie, carter

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

Jump tables always point to blocks when we first generate them.  However
there are rare situations where we can shortcut one of these blocks to a
static address during the asm shortcutting pass.

While we already updated the data section accordingly this patch also
extends this to the references stored in JMP_TBL.

Test Plan: ci

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: thomie, carter

GHC Trac Issues: #15104

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

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

When linking dynamic libraries or executables, we compute the full
transitive closure over the dependencies, and instruct the linker
to link all dependencies.  With deep dependency trees the number
of transitive dependencies can grow quickly.

macOS since the Sierra release has an upper limit on the load
command sizes the linker parses when loading dynamic lirbaries.
As such it is mandatory to keep the number of load commands (and
their size) small on recent macOS releases.

An approach that would just link direct dependencies as specified
by the -package-id flag is insufficient, because GHC can inline
across packages and the library or executable being linked could
refer to symbols deep in the dependency tree.

If we just recursively linked librarys and re-exported their
symbols, this increases the number of symbols in libraries with
many dependencies and ultimately puts excessive strain on the
linker to the point where linking takes a lot longer than even
the compilation of the modules.

We can however build a list of symbols from the obejcts we want
to link, and try to compute the libraries we need to link that
contain those symbols from the transitive dependency closure.
Luckily, we don't need to write this ourselves, but can use
the ld64 `-dead_strip_dylibs` linker flag on macOS to achive
the same result.  This will link only the libraries that are
actually referenced, which is usually a small subset of the
full transitive dependency closure.  As such we should stay
within the load command size limit for almost all but pathological
cases.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: lelf, rwbarton, thomie, carter

GHC Trac Issues: #14444

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

Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

Previously we would allow the expiration time to overflow, which in
practice meant that `threadDelay maxBound` we return far earlier than
circa 2500 CE. For now we fix this by simply clamping to maxBound.

Fixes #15158.

Test Plan: Validate, run T8089

Reviewers: simonmar, hvr

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15158

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

Simon Jakobi authored 6 years ago and Ben Gamari committed 6 years ago

Docstrings don't profit from FastString's interning, so we switch to
a different type that doesn't incur this overhead.

Updates the haddock submodule.

Reviewers: alexbiehl, bgamari

Reviewed By: alexbiehl, bgamari

Subscribers: rwbarton, thomie, mpickering, carter

GHC Trac Issues: #15157

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

Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

Reviewers: ggreif

Reviewed By: ggreif

Subscribers: rwbarton, thomie, carter, ggreif

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

Jens Petersen authored 6 years ago and Ben Gamari committed 6 years ago

On Fedora: `/usr/libexec/sphinx-build --version` outputs `sphinx-build
1.7.2`.  In bindir we actually have sphinx-build-2 and sphinx-build-3
(python2 and python3 versions), which output `sphinx-build-2 1.7.2` and
`sphinx-build-3 1.7.2` respectively.  Dunno what version others are
using but at least this change should works for most versions I suppose.

Just look for the rule firing that we want to see instead of matching on
the entire dump.

Fixes #15088.

Alec Theriault authored 6 years ago and Ben Gamari committed 6 years ago

The warning does not consider the fact that the splice pattern may
very well end up binding variables.

Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

When we allocate the heap on POSIX platforms we generally just ask for a
1TB chunk of address space and call it a day. However, if the user has
set a ulimit then this request will fail. In this case we would
previously try successively smaller allocation requests, reducing the
request size by a factor of two each time.

However, this means that GHC will significantly allocate a significantly
smaller heap than the available physical memory size in some
circumstances.  Imagine, for instance, a machine with 512 GB of physical
memory but a ulimit of 511 GB: we would be limited to a 256 GB heap.

We now use a less aggressive back-off policy, reducing by one-eighth the
last allocation size each try.

Thanks to luispedro for the suggested approach.

Test Plan: Validate

Reviewers: simonmar, erikd

Subscribers: rwbarton, thomie

GHC Trac Issues: #14492

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

`ghc -M` currently doesn't properly account for ways when generating
dependencies (#15197). This import ensures correct build-ordering between this
module and GHC.Exts.Heap.InfoTableProf. Otherwise the profiled build may fail as
described in #15197.

This patch implements the API proposed as pull request #108 for plugin
authors to influence the recompilation checker.

It adds a new field to a plugin which computes a `FingerPrint`. This is
recorded in interface files and if it changes then we recompile the
module. There are also helper functions such as `purePlugin` and
`impurePlugin` for constructing plugins which have simple recompilation
semantics but in general, an author can compute a hash as they wish.

Fixes #12567 and #7414

https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002
2-plugin-recompilation.rst

Reviewers: bgamari, ggreif

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #7414, #12567

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

Matthías Páll Gissurarson authored 6 years ago and Ben Gamari committed 6 years ago

I've changed the name from `Valid substitutions` to `Valid hole fits`,
since "substitution" already has a well defined meaning within the
theory. As part of this change, the flags and output is reanamed, with
substitution turning into hole-fit in most cases. "hole fit" was already
used internally in the code, it's clear and shouldn't cause any
confusion.

In this update, I've also reworked how we manage side-effects in the
hole we are considering.

This allows us to consider local bindings such as where clauses and
arguments to functions, suggesting e.g. `a` for `head (x:xs) where head
:: [a] -> a`.

It also allows us to find suggestions such as `maximum` for holes of
type `Ord a => a -> [a]`, and `max` when looking for a match for the
hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`.

We also show much improved output for refinement hole fits, and
fixes #14990. We now show the correct type of the function, but we also
now show what the arguments to the function should be e.g. `foldl1 (_ ::
Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`.

I've moved the bulk of the code from `TcErrors.hs` to a new file,
`TcHoleErrors.hs`, since it was getting too big to not live on it's own.

This addresses the considerations raised in #14969, and takes proper
care to set the `tcLevel` of the variables to the right level before
passing it to the simplifier.

We now also zonk the suggestions properly, which improves the output of
the refinement hole fits considerably.

This also filters out suggestions from the `GHC.Err` module, since even
though `error` and `undefined` are indeed valid hole fits, they are
"trivial", and almost never useful to the user.

We now find the hole fits using the proper manner, namely by solving
nested implications. This entails that the givens are passed along using
the implications the hole was nested in, which in turn should mean that
there will be fewer weird bugs in the typed holes.

I've also added a new sorting method (as suggested by SPJ) and sort by
the size of the types needed to turn the hole fits into the type of the
hole. This gives a reasonable approximation to relevance, and is much
faster than the subsumption check. I've also added a flag to toggle
whether to use this new sorting algorithm (as is done by default) or the
subsumption algorithm. This fixes #14969

I've also added documentation for these new flags and update the
documentation according to the new output.

Reviewers: bgamari, goldfire

Reviewed By: bgamari

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #14969, #14990, #10946

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

Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

As noted in #15073, GeneralizedNewtypeDeriving may produce code that
uses extensions that do not directly appear in the code written by the
user.  Make this clear in the users guide.

[skip ci]

Test Plan: Read it

Reviewers: RyanGlScott

Reviewed By: RyanGlScott

Subscribers: fosskers, rwbarton, thomie, carter

GHC Trac Issues: #15073

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