GitLab

Summary:
Previously when the split was performed in splitBang, `BangPat` was given the
same SrcSpan as the whole of the LHS of the declaration. This patch
correctly calculates the value.

Reviewers: alanz, austin

Reviewed By: alanz, austin

Subscribers: thomie, bgamari

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

GHC Trac Issues: #10588

The fix in 0b7e538a has regressed these benchmarks. I have recentered
them rather than marking them as broken(10482), because nobody
systematically watches the broken test cases, and we want to catch
future regressions (or improvements!). #10482 is currently still open,
presumably because this needs investigating.

Summary: It was possible to kill GHCi with a carefully-timed ^C

Test Plan: The bug in #10017 exposed this

Reviewers: bgamari, austin

Reviewed By: austin

Subscribers: thomie, bgamari

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

GHC Trac Issues: #10017

Summary:
As of 7.10.1 we specialize INLINEABLE identifiers defined in other
modules. This can expose issues (compiler bugs or otherwise) in some cases
(e.g. Trac #10491) and therefore we now provide a way for the user to disable
this optimization.

Test Plan: Successfully compile Splice.hs from Trac #10491.

Reviewers: simonpj, austin

Reviewed By: simonpj

Subscribers: simonpj, thomie, bgamari

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

GHC Trac Issues: #10491

Summary:
As of 7.10.1 we specialize INLINEABLE identifiers defined in other
modules. This can expose issues (compiler bugs or otherwise) in some cases
(e.g. Trac #10491) and therefore we now provide a way for the user to disable
this optimization.

Test Plan: Successfully compile Splice.hs from Trac #10491.

Reviewers: simonpj, austin

Reviewed By: simonpj

Subscribers: simonpj, thomie, bgamari

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

GHC Trac Issues: #10491

GHC can't yest build a TypeRep for a type involving kind variables.
(We await kinds = types for that.)  But the error message was terrible,
as fixing #10524 reminded me.

This improves it a lot.

TcValidity.fvTypes works in partnership with sizeTypes, and
hence should ignore kinds in exactly the same way.  It wasn't
doing so, which meant that validDerivPred said "No" when it
should have said "Yes". That led to the bug reported in
Trac #10524 comment:7.

The error message is pretty terrible
  No instance for (Typeable T)
but I'll fix that next

It really isn't needed, and life is simpler without

Combining functional dependencies with kind-polymorphism is
devilishly tricky!  It's all documented in
    Note [Closing over kinds in coverage]

Fixes Trac #10564

When working on Trac #10482 I noticed that we could give constructor
arguments the CPR property if they are use strictly.

This is documented carefully in
    Note [CPR in a product case alternative]
and also
    Note [Initial CPR for strict binders]

There are a bunch of intersting examples in
    Note [CPR examples]
which I have added to the test suite as T10482a.

I also added a test for #10482 itself.

Summary:
I don't know if or when this changed, but the documentation on :{ :}
(multiline input) seems out of date. Layout rule works fine. I added a
regression test.

Reviewers: austin

Subscribers: thomie, bgamari

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

yieldCapability() was not prepared to be called by a Task that is not
either a worker or a bound Task.  This could happen if we ended up in
yieldCapability via this call stack:

performGC()
scheduleDoGC()
requestSync()
yieldCapability()

and there were a few other ways this could happen via requestSync.
The fix is to handle this case in yieldCapability(): when the Task is
not a worker or a bound Task, we put it on the returning_workers
queue, where it will be woken up again.

Summary of changes:

* `yieldCapability`: factored out subroutine waitForWorkerCapability`
* `waitForReturnCapability` renamed to `waitForCapability`, and
  factored out subroutine `waitForReturnCapability`
* `releaseCapabilityAndQueue` worker renamed to `enqueueWorker`, does
  not take a lock and no longer tests if `!isBoundTask()`
* `yieldCapability` adjusted for refactorings, only change in behavior
  is when it is not a worker or bound task.

Test Plan:
* new test concurrent/should_run/performGC
* validate

Reviewers: niteria, austin, ezyang, bgamari

Subscribers: thomie, bgamari

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

GHC Trac Issues: #10545

getNewNursery() was unconditionally incrementing next_nursery, which
is normally fine but it broke an assumption in
storageAddCapabilities().  This manifested as an occasional crash in
the setnumcapabilities001 test.

The patch "Treat out-of-scope variables as holes" makes
lots of error messages change a bit. This patch has all
the change.

This patch implements the idea in Trac #10569.

* An out-of-scope variable is treated as a typed expression
  hole.

* That is, we don't report it in the type checker, not the
  renamer, and we when we do report it, we give its type.

* Moreover, we can defer the error to runtime with
  -fdefer-typed-holes

In implementation terms:

* The renamer turns an unbound variable into a HsUnboundVar

* The type checker emits a Hole constraint for a
  HsUnboundVar, and turns it back into a HsVar

It was a bit painful to implement because a whole raft of
error messages change slightly.  But there was absolutely
nothing hard in principle.

Holes are reported with a bunch of possibly-useful context,
notably the "relevant bindings".  I found that this was
distracting clutter in the very common case of a mis-typed
variable that is only accidentally not in scope, so I've
arranged to print the context information only for true holes,
that is ones starting with an underscore.

Unbound data constructors use in patterns, like
  f (D x) = x
are still reportd by the renamer, and abort compilation
before type checking.

These tests aren't about impredicativity

Result type-sigs are now illegal, but that's not what this test
is about

..to avoid irrelevant 'main is not defined' error message

This is just a small twiddle to TcSimplify.usefulToFloat
See Note [Which equalities to float].

See Note [Add demands for strict constructors].

The new bit is the test for isAbsDmd in addDataConStrictness.
There was a cryptic note that said that this function
should add a seqDmd even for Absent arguments, but that
is definitely a bad thing (as the Note now says), causing
unused arguments to be passed to the worker.

Easy fix!

A type wild-card should't appear in the "uses"
free-variable set.

When doing strictness analysis, we need to look inside products.
To avoid unpacking infinitely, we must be careful about
infinite types.  That in turn is controlled by TyCon.checkRecTc.

For data families like
   data instance T (a,b) = MkT a (T b)
we want to unpack the thing recursively for types like
  T (Int, (Int, (Int, Int)))

This patch elaborates the checkRecTc mechanism in TyCon, to
maintain a *count* of how many times a TyCon has shown up,
rather than just a boolean.

A simple change, and a useful one.  Fixes Trac #10482.

When we have
  data instance T (a,b) = MkT a b
we make a represntation type
  data TPair a b = MkT a b
plus an axiom to connect the two
  ax a b :: T (a,b)  ~R  TPair a b

Previously this was a Nominal equality, and that worked ok
but seems illogical since Nominal equalities are between
types that the programmer thinks of as being equal.  But
TPair is not visible to the programmer; indeed we call it
the "representation TyCon".  So a Representational equality
seems more suitable here.

Summary:
On x86_64, commit e2f6bbd3 assigned
the STG registers F1 and D1 the same hardware register (xmm1), and
the same for the registers F2 and D2, etc. When mixing calls to
functions involving Float#s and Double#s, this can cause wrong Cmm
optimizations that assume the F1 and D1 registers are independent.

Reviewers: simonpj, austin

Reviewed By: austin

Subscribers: simonpj, thomie, bgamari

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

GHC Trac Issues: #10521

The main payload is in 'mk_functor_like_constraints' in
TcDeriv.inferConstraints.

This is moving towards a fix for Trac #10561

Reported by mitchty:

  When porting ghc to alpine linux (rumors say they build
  all binaries as Position Independent Executables
  to leverage global ASLR) linker issued obscure errors:

Tiny example:
    $ echo 'main = print "hello"' > a.hs
    $ ghc -fforce-recomp a.hs -fPIC -dynamic -optl-pie -o a
        ld: /tmp/ghc2142_0/ghc2142_5.o: relocation R_X86_64_32 against `ZCMain_main_closure'
            can not be used when making a shared object; recompile with -fPIC
        /tmp/ghc2142_0/ghc2142_5.o: error adding symbols: Bad value
        collect2: error: ld returned 1 exit status

There is two entry points in CC driver:
    'runPhase' (CC) and 'mkExtraObj'

'mkExtraObj' does not handle most of 'runPhase's complexity.
Ideally it should.

This patch only adds -fPIC propagation to 'mkExtraObj'.

Please merge to stable branch.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Summary:
Contains Cabal submodule update, as Cabal is responsible
generating package keys.  We also have to update some output.

Also comes with a documentation update for ghc-pkg in the
user manual for --package-key.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin

Subscribers: thomie, bgamari

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

GHC Trac Issues: #10550