For some reason, `axSub0R` was left out of `typeNatCoAxiomRules` in
`TcTypeNats`, which led to disaster when trying to look up `Sub0R` from
an interface file, as demonstrated in #14934.

The fix is simple—just add `axSub0R` to that list. To help prevent
an issue like this happening in the future, I added a
`Note [Adding built-in type families]` to `TcTypeNats`, which
contains a walkthrough of all the definitions in `TcTypeNats` you
need to update when adding a new built-in type family.

Test Plan: make test TEST=T14934

Reviewers: bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #14934

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

(cherry picked from commit c3aea396)

This subtle patch fixes Trac #5129 (again; comment:20
and following).

I took the opportunity to document seq# properly; see
Note [seq# magic] in PrelRules, and Note [seq# and expr_ok]
in CoreUtils.

(cherry picked from commit abaf43d9)

The RULE for bitInteger was trying to constant-fold

    bitInteger 9223372036854775807#

which meant constructing a gigantic Integer at compile
time.  Very bad idea!  Easily fixed.

Fixes Trac #14959, #14962.

(cherry picked from commit efc844f5)

When interpreter is not profiled (see `interpreterProfiled` in
`DynFlags`) bytecode generator generates a NULL pointer as the cost
centre of a `BRK_FUN` instruction:

    let cc | interpreterProfiled dflags = cc_arr ! tick_no
           | otherwise = toRemotePtr nullPtr
    let breakInstr = BRK_FUN (fromIntegral tick_no) (getUnique this_mod) cc
    return $ breakInstr `consOL` code

We now take this into account when disassembling `BRK_FUN`.

Reviewers: bgamari, simonmar, erikd

Subscribers: rwbarton, thomie, carter

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

(cherry picked from commit 8e341013)

Given this program:

    main = do
      f $ do
        a <- return 3
          c <- do
          return 5

GHC previously gave this error message:

    Main.hs:2:7: error:
        Parse error in pattern: do a <- return 3 c
        Possibly caused by a missing 'do'?
      |
    2 |   f $ do
      |       ^^...

What happened is GHC considered the whole `f $ do a <- return 3 c` as a
pattern. When parsed as an expression it becomes an infix application of
`($)`, and GHC checks left and right hand sides before checking if `($)`
is a valid infix constructor name, and shows the first error it got.

If instead we first check if the infix op is valid in pattern context,
the error message becomes much clearer:

    Main.hs:2:3: error:
        Parse error in pattern: f $ do a <- return 3 c
        Possibly caused by a missing 'do'?
      |
    2 |   f $ do
      |   ^^^^^^...

This may not entirely fix #11188 but I think it's an improvement.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #11188

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

(cherry picked from commit cb6d8589)

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

Test Plan: `make test TEST=T14925`

Reviewers: hvr, dfeuer

Reviewed By: dfeuer

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14925

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

(cherry picked from commit 20ae19fc)

Manually-written instances and standalone-derived instances
have the benefit of having the `checkValidInstHead` function run over
them, which catches manual instances of built-in types like `(~)` and
`Coercible`. However, instances generated from `deriving` clauses
weren't being passed through `checkValidInstHead`, leading to
confusing results as in #14916.

`checkValidInstHead` also has additional validity checks for language
extensions like `FlexibleInstances` and `MultiParamTypeClasses`. Up
until now, GHC has never required these language extensions for
`deriving` clause, so to avoid unnecessary breakage, I opted to
suppress these language extension checks for `deriving` clauses, just
like we currently suppress them for `SPECIALIZE instance` pragmas.

Test Plan: make test TEST=T14916

Reviewers: goldfire, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14916

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

(cherry picked from commit 20f14b4f)

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

-g1 removes block information, but it turns out that procs can
refer to block information through parents.
Note [Splitting DebugBlocks] explains the parentage relationship.

Test Plan:
* ./validate
* added a new test

Reviewers: bgamari, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14894

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

(cherry picked from commit 0cbb13b3)

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

Subscribers: rwbarton, thomie, carter

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

(cherry picked from commit d718023e)

Summary:
In commit dbd81f7e, a
regression was inadvertently introduced which caused derived `Read`
instances for record data types with fields ending in a `#` symbol
(using `MagicHash`) would no longer parse on valid output. This
is ultimately due to the same reasons as #5041, as we cannot parse
a field name like `foo#` as a single identifier. We fix this issue
by employing the same workaround as in #5041: first parse the
identifier name `foo`, then then symbol `#`.

This is accomplished by the new `readFieldHash` function in
`GHC.Read`. This will likely warrant a `base-4.11.1.0` release.

Test Plan: make test TEST=T14918

Reviewers: tdammers, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14918

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

(cherry picked from commit d5577f44)

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

Reviewers: hvr

Subscribers: rwbarton, thomie, erikd, carter

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

(cherry picked from commit a25b763f)

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

Summary: OpenIndiana apparently reports a triple of i386-pc-solaris2.11.

Reviewers: hvr

Subscribers: rwbarton, thomie, erikd, carter

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

(cherry picked from commit 4fa077a2a1d6e6e7a45ef03a1075ff3c7dddb23d)

OpenIndiana apparently reports a triple of i386-pc-solaris2.11.

Thanks to Gabor for pointing this out.

Simon Marlow authored 7 years ago and Ben Gamari committed 7 years ago

This was broken by D3746 and/or D3809, but unfortunately we didn't
notice because CI at the time wasn't building the profiling way.

Test Plan:
```
cd testsuite/test/profiling/should_run
make WAY=ghci-ext-prof
```

Reviewers: bgamari, michalt, hvr, erikd

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14705

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

(cherry picked from commit 488d63d6)

`all_tasks_mutex` should be released before calling `releaseCapability_`
in the parent process as `releaseCapability_` spawns worker tasks in
some cases.

Reviewers: bgamari, erikd, simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14538

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

(cherry picked from commit e261b852)

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

Summary:
This came up when trying to build GHC HEAD with nix. We
do not set CCX for integer-gmp when running ./configure. We do
this however for libffi.

The result is, that if CCX is not set, we default to the system
one, of which there might be none (as in nixos's case).  This
will not show on a debian+nix or similar setup, where the system
`cxx` is still in place, and only shows up when the system tries
hard to sandbox everything (even cxx) as nixOS does.

We use `CXX`, which is set to either `clang` or `CC_STAGE1`, and
also usedfor `CC`, similar to what we do for libffi.c

Test Plan: ./validate

Reviewers: bgamari, hvr

Reviewed By: hvr

Subscribers: rwbarton, thomie, carter

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

(cherry picked from commit cf5bc96e)

niteria authored 7 years ago and Ben Gamari committed 7 years ago

This reverts f5b275a2
and changes the places that looked for `Lit (MachStr _))`
to use `exprIsMbTickedLitString_maybe` to unwrap ticks as
necessary.
Also updated relevant comments.

Test Plan:
I added 3 new tests that previously reproduced.
GHC HEAD now builds with -g

Reviewers: simonpj, simonmar, bgamari, hvr, goldfire

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14779

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

(cherry picked from commit 5bc195a2)

Herbert Valerio Riedel authored 7 years ago and Ben Gamari committed 7 years ago

This wasn't spotted rightaway in
8f0b2f5e
because the include-site deliberately ignored include-errors as
a Hack with the justification below:

> Hack. The file gmp/config.mk doesn't exist yet after running ./configure in
> the toplevel (ghc) directory. To let some toplevel make commands such as
> sdist go through, right after ./configure, don't consider this an error.

This may have contributed to #14891.

(cherry picked from commit df7ac37d)

niteria authored 7 years ago and Ben Gamari committed 7 years ago

Since 7aaeaf81
`-g1` and `-g2` are actually different.
The tutorial below is correct.

Test Plan: harbormaster

Reviewers: bgamari, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

(cherry picked from commit 5b1132eefd0a75189b3527486b492c3dffc7bdf1)

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

Requires some ghc-cabal changes as well.

Test Plan: ./validate

Reviewers: hvr, bgamari

Reviewed By: bgamari

Subscribers: hsyl20, erikd, alpmestan, rwbarton, thomie, carter

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

Sergey Vinokurov authored 7 years ago and Ben Gamari committed 7 years ago

 * Fix missing code example in changelog for 8.4.1

 * List 'setEnv' as opposite of 'getEnv'

   It seems best to direct users to use 'System.Environment.setEnv'
   rather than 'System.Posix.Env.putEnv'. This is due to 'setEnv' being
   located in the same module as 'getEnv' and my virtue of working on
   Windows platform, whereas 'putEnv' does not have that quality because
   it's part of the 'unix' package.

 * Reflect in docs the fact that 'readMVar' is not a composition of
   'takeMVVar' and 'putMVar' any more

(cherry picked from commit df449e17)

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Test Plan: `./configure --disable-ld-override; make; make install`

Reviewers: trofi, hvr

Reviewed By: trofi

Subscribers: rwbarton, thomie, erikd, carter, simonmar

GHC Trac Issues: #14675

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

(cherry picked from commit bc1bcaa2)

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

Our *-cross flavours force -fllvm, this adds flavours for cross
compilation to x86_64, where we can use our native code generator.

Test Plan: ./validate

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

(cherry picked from commit e4dcebf8)

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

Reviewers: bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

(cherry picked from commit 821daadf)

Fixes file handle leak

Sergey Vinokurov authored 7 years ago and Ben Gamari committed 7 years ago

(cherry picked from commit 37e78029845a04d0ab4cc05e1790c648facdcb1f)

Sergey Vinokurov authored 7 years ago and Ben Gamari committed 7 years ago

It seems best to direct users to use 'System.Environment.setEnv'
rather than 'System.Posix.Env.putEnv'. This is due to 'setEnv' being
located in the same module as 'getEnv' and my virtue of working on
Windows platform, whereas 'putEnv' does not have that quality because
it's part of the 'unix' package.

(cherry picked from commit c74fcf5d27744c67b09b29a78029c31c9371cf41)

Sergey Vinokurov authored 7 years ago and Ben Gamari committed 7 years ago

(cherry picked from commit 3ae408cf93d10b9a2e5acb4186dc8e0c62e0afb6)

Simon Marlow authored 7 years ago and Ben Gamari committed 7 years ago

Summary:
ld.gold is buggy when using -r and a linker script.  See upstream bug
https://sourceware.org/bugzilla/show_bug.cgi?id=22266

This has been causing various brokenness for the GHC runtime linker,
where we load these broken object files.

Test Plan: Test program from #14675

Reviewers: bgamari, RyanGlScott, alpmestan, hvr, erikd

Subscribers: rwbarton, thomie, erikd, carter

GHC Trac Issues: #14328, #14675, #14291

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

(cherry picked from commit 0a3629af)

* Clarify the representation of sums without fields.
* Try to improve language, clarity, and examples.

Fixes #14752

Reviewers: osa1, bgamari

Reviewed By: osa1

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14752

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

(cherry picked from commit d987f71a)

Michal Terepeta authored 7 years ago and Ben Gamari committed 7 years ago

During some recent work on CBE we discovered that `zipWith` is used to
check for equality, but that doesn't quite work if lists are of
different lengths! This was fixed by bgamari, but unfortunately the fix
had to be rolled back due to other changes in CBE in
50adbd7c. Since I wanted to have another
look at CBE anyway, we agreed that the first thing to do would be to
re-introduce the fix.

Sadly I don't have any actual test case that would exercise this.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate

Reviewers: bgamari, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14226

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

(cherry picked from commit 4e513bf7)