GitLab

Summary:
These are the names used by arm-linux-androideabi-objdump, so
it's helpful to have them here next to the Stg register mapping.

Reviewers: austin, erikd, bgamari

Reviewed By: erikd, bgamari

Subscribers: thomie

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

Summary: This is already the behavior on Elf_Rela platforms, and is helpful.

Reviewers: simonmar, austin, bgamari, erikd

Reviewed By: erikd

Subscribers: thomie

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

Blimey!  CoreUtils.exprIsHNFlike had not one but two bugs.

 * is_hnf_like treated coercion args like type args
   (result: exprIsHNF might wrongly say True)

 * app_is_value treated type args like value args
   (result: exprIsHNF might wrongly say False)

Bizarre.  This goes back to at least 2012. It's amazing that it
hasn't caused more trouble.

It was discovered by a Lint error when compiling Trac #11248 with -O.

In fixing Trac #11480 I had omitted to deal with FunDeps.oclose,
which was making recursive use of immSuperClasses, and hence
going into a loop in the recursive case.

Solution: use transSuperClasses, which takes care not to.

I found that there was some code duplication going on,
so I've put more into the shared function checkValidFamPats.

I did some refactoring in checkConsistentFamInst too,
preparatory to #11450; the error messages change a little
but no change in behaviour.

This issue came up in Trac #11480, and is documented in
Note [When superclasses help] in TcRnTypes.

We were getting a spurious warning
  T11480.hs:1:1: warning:
     solveWanteds: too many iterations (limit = 4)

The fix is easy.  A bit of refactoring along the way.

The original bug report in Trac #11480 appears to work
fine in HEAD and the 8.0 branch but I added a regression
test in this commit as well.

The MonadFail proposal implemented so far via #10751 only warns about
missing `MonadFail` instances based on existence of failible pattern
matches in `do`-blocks.

However, based on the noncanonical Monad warnings implemented via #11150
we can provide a different mechanism for detecting missing `MonadFail`
instances quite cheaply. That is, by checking for canonical `fail` definitions.

In the case of `Monad`/`MonadFail`, we define the canonical implementation of
`fail` to be such that the soft-deprecated method shall (iff overridden) be
defined in terms of the non-deprecated method. Consequently, in case of
`MonadFail`, the `Monad(fail)` method shall be defined as alias of
the `MonadFail(fail)` method.

This allows us at some distant point in the future to remove `fail` from
the `Monad` class, while having GHC ignore/tolerate such literal canonical
method definitions.

Reviewed By: bgamari, RyanGlScott

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

Fixes validate on Travis.

Reviewed by: bgamari

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

Refactoring only. It's shorter, and brings
`HasDynFlags/ContainsDynFLags` in line with `HasModule/ContainsModule`.
Introduce `updTopEnv`.

Reviewed by: bgamari

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

This information is mostly useless, since hierarchical modules are valid
Haskell2010 and everybody knows how to use them.

Reviewed by: bgamari

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

See #5641.

Test Plan: validate --slow

Reviewers: austin, bgamari, goldfire

Reviewed By: goldfire

Subscribers: thomie

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

It is impossible to write warning-free code under the three-release
policy with this flag enabled by default. See #11370 for details.

rwbarton authored Jan 23, 2016 and Ben Gamari committed Jan 23, 2016

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

ase authored Jan 23, 2016 and Ben Gamari committed Jan 23, 2016

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

Joachim Breitner authored Jan 23, 2016 and Ben Gamari committed Jan 23, 2016

it seems that this closure type has not been in use since 5d52d9, so all
this is dead and untested code. This removes it. Some of the code might
be useful for a counting indirection as described in #10613, so when
implementing that, have a look at what this commit removes.

Test Plan: validate on harbormaster

Reviewers: austin, bgamari, simonmar

Reviewed By: simonmar

Subscribers: thomie

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

Ryan Scott authored Jan 23, 2016 and Ben Gamari committed Jan 23, 2016

Reviewers: thomie, austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton

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

GHC Trac Issues: #11056

Ben Gamari authored Jan 22, 2016 and Ben Gamari committed Jan 22, 2016

Trac #9105 notes significant CPU usage by an otherwise idle process when
compiled with profiling. The reason for this is that we keep the tick
timer active in the profiling RTS even if profiling wasn't requested at
runtime.

If the user requests any sort of profiling then we need to keep the
timer active to ensure that samples are collected.

Test Plan: Validate, check CPU usage, ensure profiling still works

Reviewers: simonmar, austin

Reviewed By: simonmar, austin

Subscribers: thomie

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

GHC Trac Issues: #9105

Jonas Scholl authored Jan 22, 2016 and Ben Gamari committed Jan 22, 2016

This fixes #11372 by omitting arguments with a void-type when checking
whether a self-recursive tail call can be optimized to a local jump.
Previously, a function taking a real argument and a State# token
would report an arity of 1 in the SelfLoopInfo in getCallMethod,
but a self-recursive call would apply it to 2 arguments, one of them
being the State# token, thus no local jump would be generated.
As the State# token is not represented by anything at runtime, we can
ignore it and thus trigger the loopification optimization.

Test Plan: ./validate

Reviewers: austin, bgamari, simonmar

Reviewed By: bgamari

Subscribers: simonmar, thomie

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

GHC Trac Issues: #11372

Eric Seidel authored Jan 22, 2016 and Ben Gamari committed Jan 22, 2016

```
``CallStack``s
```

seems to confuse ReST into producing an extended code-span

```
``CallStack``\s
```

fixes it, but there may be a better solution

Test Plan: build the user's guide and inspect the last paragraph of
"9.14.4.5. Implicit CallStacks"

Reviewers: bgamari

Reviewed By: bgamari

Projects: #ghc

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

Test Plan: validate

Reviewers: bgamari, austin

Reviewed By: bgamari, austin

Subscribers: thomie

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

Summary:
Also don't print it if the user specifically requested
non-verbose output with -v0.

Since this means there is no longer any test that checks
for the message, add such a test.

Test Plan: validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #11478

Eric Seidel authored Jan 22, 2016 and Ben Gamari committed Jan 22, 2016

Test Plan: `make test TEST=T11462`

Reviewers: austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: thomie

Projects: #ghc

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

GHC Trac Issues: #11462

Edward Z. Yang authored Jan 21, 2016 and Ben Gamari committed Jan 22, 2016

Test Plan: validate

Reviewers: austin, thomie, bgamari

Reviewed By: thomie, bgamari

Subscribers: thomie

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

We don't know what the cause of the bug was, or what commit fixed it.
or why it was Windows only. So it seems prudent to run it in all
configurations, in case the bug should crop up again.

addressing some valuable feedback by thomie at
https://phabricator.haskell.org/rGHCde1160be0477

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

Summary:
commit a034031a

 did not
fix problem completely. Stack overflows still occasionally
happen.

Easy to test by the following Torture Test:

  while sphinx-build -T -N -E -a -b html \
        -d docs/users_guide/.doctrees-html \
        -D latex_paper_size=letter \
        docs/users_guide docs/users_guide/build-html/users_guide
  do
    echo again
  done

sphinx build large nested data structures when parses GHC manual
(docs/users_guide/glasgow_exts.rst is 455KB in size) which
can't be serialized useing default python call stack depth of 1000
calls.

The patch increases stack depth 10 times. Survived 2 hours of
Torture Test.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Test Plan: ran Torture Test to make sure it is stable

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #10950

Fixes #4248.

Ben Gamari authored Jan 21, 2016 and Ben Gamari committed Jan 21, 2016

Previously there were a few obsolete references to `Data.List` and
the descriptions were lacking examples.

Fixes #11065.

Test Plan: Read it.

Reviewers: ekmett, goldfire, hvr, austin

Reviewed By: hvr

Subscribers: nomeata, thomie

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

GHC Trac Issues: #11065