GitLab

This is the renaming that @simonpj requested:
```
· zipOpenTCvSubst  -> zipTvSubst   (It only deals with tyvars)

· zipOpenTCvSubstCoVars -> zipCvSubst   (it only deals with
covars)

· zipOpenTCvSubstBinders ->  zipTyBinderSubst  (it only deals
with TyBinders, not covars)
```
plus the `mk` variant.

Test Plan: ./validate

Reviewers: simonpj, goldfire, austin, bgamari

Subscribers: thomie, simonpj

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

GHC Trac Issues: #11371

The idea here is described in [wiki:Typechecker]. Briefly,
this refactor keeps solid track of "synthesis" mode vs
"checking" in GHC's bidirectional type-checking algorithm.
When in synthesis mode, the expected type is just an IORef
to write to.

In addition, this patch does a significant reworking of
RebindableSyntax, allowing much more freedom in the types
of the rebindable operators. For example, we can now have
`negate :: Int -> Bool` and
`(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic
is in tcSyntaxOp.

This addresses tickets #11397, #11452, and #11458.

Tests:
  typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458}
  th/T11452

This is relevant to #11371.

This was causing trouble as we had to remember when to use "unLifted"
and when to use "unlifted".

"unlifted" is used instead of "unLifted" as it's a single word.

Reviewers: austin, hvr, goldfire, bgamari

Subscribers: thomie

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

In an attempt to catch bugs involving using undef values, replace
undef literals by values likely to cause crashes or test failures.
We do this only when validating since it is a deoptimization.

This depends on D1857 to catch such bugs in the RTS (such as #11487).

Test Plan:
Did a build with
```
BuildFlavour = quick-llvm
SRC_HC_OPTS_STAGE1 = -fllvm-fill-undef-with-garbage
```
The build crashed when running ghc-stage2, as expected.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

The fourth argument of distdir-way-opts was missing. So, for example,
SRC_HC_OPTS_STAGE1 was not used when building the RTS.

Test Plan: validate --slow

Reviewers: austin, bgamari, thomie

Reviewed By: thomie

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

This was broken in 4a32bf92, meaning
that info tables and subsequent code are no longer guaranteed to have
the recommended alignment.  Split up the section header and section
alignment printers, and print an appropriate alignment directive before
each info table.

Fixes Trac #11486

Reviewers: austin, bgamari, rwbarton

Reviewed By: bgamari, rwbarton

Subscribers: thomie

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

GHC Trac Issues: #11486

jberthold astutely pointed out that the previous fix (D1822) could not
have possibly fixed the issue as the patch would only have had any
effect if !PROFILING.

Test Plan: Check for reduced CPU usage when compiled with `-prof` but
without `+RTS -p`

Reviewers: simonmar, austin, jberthold

Reviewed By: simonmar, jberthold

Subscribers: simonmar, thomie

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

GHC Trac Issues: #9105

Test Plan: validate

Reviewers: thomie, austin, bgamari

Reviewed By: bgamari

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

GHC Trac Issues: #11481

This is `subsititution` to `substitution`, plus one instance of
the note that I missed.

Test Plan: docufix

Reviewers: simonpj, bgamari, austin, goldfire

Reviewed By: simonpj, bgamari

Subscribers: thomie

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

GHC Trac Issues: #11371

Makes the needed changes to make RemoteGHCi work on Windows.
The approach passes OS Handles areound instead of the Posix Fd
as on Linux.

The reason is that I could not find any real documentation about
the behaviour of Windows w.r.t inheritance and Posix FDs.

The implementation with Fd did not seem to be able to find the Fd
in the child process. Instead I'm using the much better documented
approach of passing inheriting handles.

This requires a small modification to the `process` library.
https://github.com/haskell/process/pull/52

Test Plan: ./validate On Windows x86_64

Reviewers: thomie, erikd, bgamari, simonmar, austin, hvr

Reviewed By: simonmar

Subscribers: #ghc_windows_task_force

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

GHC Trac Issues: #11100

* T2552 (#10037) is failng for all threaded opt_ways, not for WAY=prof.
* TH_spliceE5_prof (#11495) is failing when ghc_dynamic
* Rename ghci_dynamic to ghc_dynamic. It's the same thing.

The pre-condition on `mkTopTCvSubst` turned out to be wrong and
not satisfied by any of the callers. I've fixed it, so that it
constructs the in_scope set from the range of the substitution.
`mkTopTCvSubst` was also unnecessarily general it is never called
with `CoVars`, so I changed the type signature and added an assertion.

Test Plan: ./validate --slow

Reviewers: goldfire, simonpj, bgamari, austin

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #11371

Summary:
Previously, `-Wunused-matches` would fire whenever it detected unused type
variables in a type family or data family instance. This can be annoying for
users who wish to use type variable names as documentation, as being
`-Wall`-compliant would mean that they'd have to prefix many of their type
variable names with underscores, making the documentation harder to read.

To avoid this, a new warning `-Wunused-type-variables` was created that only
encompasses unused variables in family instances. `-Wunused-matches` reverts
back to its role of only warning on unused term-level pattern names. Unlike
`-Wunused-matches`, `-Wunused-type-variables` is not implied by `-Wall`.

Fixes #11451.

Test Plan: ./validate

Reviewers: goldfire, ekmett, austin, hvr, simonpj, bgamari

Reviewed By: simonpj, bgamari

Subscribers: thomie

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

GHC Trac Issues: #11451

There are two ways to do retainer profiling. Quoting from the user's guide:
  1. `+RTS -hr` "Breaks down the graph by retainer set"
  2. `+RTS -hr<cc> -h<x>`, where `-h<x>` is one of normal heap profiling
     break-down options (e.g. `-hc`), and `-hr<cc> means "Restrict the
     profile to closures with retainer sets containing cost-centre
     stacks with one of the specified cost centres at the top."

Retainer profiling writes to a .hp file, like the other heap profiling
options, but also to a .prof file. Therefore, when the .prof file is not
writeable for whatever reason, retainer profiling should be turned off
completely.

This worked ok when running the program with `+RTS -hr` (option 1), but a
segfault would occur when using `+RTS -hr<cc> -h<x>`, with `x!=r` (option 2).

This commit fixes that.

Reviewed by: bgamari

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

GHC Trac Issues: #11489

Before:
 * without -rtsopts: Most RTS options are disabled. Link with -rtsopts to enable them.
 * with -rtsopts: invalid heap profile option: -hc
After:
 * the flag -hc requires the program to be built with -prof

Copy `Note [OPTION_SAFE vs OPTION_UNSAFE]` from commit 8c7ad0bd.

Reviewed by: bgamari

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

This is the fix proposed in #11371:
```
In other cases, we already have the in-scope set in hand. Example: in
CoreLint.lintTyApp we find a call to substTyWith. But Lint carries an
in-scope set, so it would be easy to pass it to substTyWith.
```

Test Plan: ./validate --slow (only pre-existing problems)

Reviewers: simonpj, goldfire, austin, nomeata, bgamari

Subscribers: thomie

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

GHC Trac Issues: #11371

See comment:16 in Trac #10712. The tests were wrong, not GHC!

Most notably, this pulls in a feature needed for #11100 (remote ghci)
windows-support

This shouldn't have any noticeable API changes for GHC

Follow-up to 132c2089

[skip ci]

Crikey!  Not just one but two bugs in type variable cloning,
both dating from the days before PolyKinds.  Both were shown up
by Trac #11330.

1. In SetLevels, when floating a case expression we must clone its
   binders, *and* do so in a telescope-aware way, because the
   constructor may bind a kind variable that appears in the kind
   of a type variable.

   Instead of doing this (wrongly) by steam, call CoreSubst.cloneBndrs.

   I added Notes and did other refactoring at the same time.

2. It turned out that CoreSubst.cloneBndrs calls TyCoRep.cloneTyVarBndr,
   and that too was bogus!  It didn't substitute in the kind of the
   TyVar being cloned.  There was even a comment to say "variables can't
   appear in kinds".  Thta hasn't been true for a long time now.

Easily fixed.

Interestingly, I then found that test
   dependent/should_compile/KindEqualities
was emitting a new inexhaustive-pattern-match warning.  Sure enough
it was valid!  So the lack of cloning in cloneTyVarBndr really was
causing an observable bug; just one that we had not observed.

As Bartosz has discovered, the invariants for substitutions were
wrong, and in particular the "mkTop...Subst" and "zipTop..Subst"
functions were building substitutions that didn't obey even the
old invariants.

This patch kills of the bogus zipTopTCvSubst in favour of the
more robust zipOpenTCvSubst.

I tripped over this because my upcoming patch (concerning SetLevels,
Trac #11330) triggered an ASSERT failure in the substitution
well-formedness assertion in TyCoRep.

This code deliberately builds a subtle negative-occurrence-of-data-type
example, described in the paper, so with -O it'll give "simplifier
ticks exhausted".

This patch just adds a comment to explain.

With -dppr-debug the output for the (ofen-large) InScope set
was overwhelming.  This makes it smaller.

Only affects debugging.

We are unable to produce load/store barriers for pre-ARMv7 targets.
Phab:D894 added dummy cases to SMP.h for these barriers to prevent the
build from failing under the assumption that there are no SMP-capable
devices of this vintage. However, #10433 points out that it is more
correct to simply set NOSMP for such targets.

Tested By: rwbarton

Test Plan: Validate

Reviewers: erikd, rwbarton, austin

Reviewed By: rwbarton

Subscribers: thomie

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

GHC Trac Issues: #10433

This allows the user to avoid warnings for warning flags that GHC
doesn't recognise. See #11429 for details..

Test Plan: Validate with T11429[abc] tests

Reviewers: austin, hvr

Reviewed By: hvr

Subscribers: thomie

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

GHC Trac Issues: #11429

This supplements the description previously added in
6400c768. See #10560 for details.

Test Plan: read it

Reviewers: austin

Subscribers: thomie, hvr

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

GHC Trac Issues: #10560

Test Plan: Read it

Reviewers: austin

Subscribers: thomie

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

This warning flag was recently introduced as part of #10751. However,
it was missed during code-review that almost all existing warning
flags use a plural-form, so for consistency this commit renames
that warning flag to `-Wmissing-monadfail-instances`.

Test Plan: local validate (still running)

Reviewers: quchen, goldfire, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #10751

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.