GitLab

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

GhcStage1DefaultNewCodegen, GhcStage2DefaultNewCodegen,
GhcStage3DefaultNewCodegen and GhcCompilerWays are not used anywhere.

Summary:
Previously, we used $1_$2_PACKAGE_KEY to parametrize $1.  But the
documentation says that $1 should be the directory...  and we're now
putting the libraries in $1_$2_LIB_NAME.  So use /that/.  This is just
alpha-renaming, so as long as we're consistent, there's no material
difference.)

I also fixed a bug of a package ID calculation which I missed first
time around, which was tickled by this change.

BTW, this means DEP_KEYS and TRANSITIVE_DEP_KEYS are unused, so
remove them from ghc-cabal.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin

Subscribers: thomie, bgamari

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

Commit a93ab43a
enabled support for proper PIC relocations from
assembler.

Commit adds support for relocations of type:
    R_PPC_REL16_HI
    R_PPC_REL16_HA
    R_PPC_REL16_LO
    R_PPC_PLTREL24

They are used only when GHC is built in
    DYNAMIC_GHC_PROGRAMS = NO
mode.

Verified by running the following test:

    // cat a.c
    #include <stdio.h>

    void ffi_a_hello (int i) {
        fprintf (stderr, "WEEEEEEEE: i=%d\n", i);
    }

    -- cat A.hs
    {-# LANGUAGE ForeignFunctionInterface #-}
    module A where

    import Foreign.C

    foreign import ccall "ffi_a_hello" a :: CInt -> IO ()

    # ghc -fPIC -c a.c -fforce-recomp
    # ghc -fPIC -c A.hs -fforce-recomp
    # ghc --interactive ./a.o A
    ...
    *A> a 42
    WEEEEEEEE: i=42
See gory details in Trac #10402.
Signed-off-by: Colin Watson <cjwatson@debian.org>
Signed-off-by: Sergei Trofimovich <siarheit@google.com>

Reviewed By: bgamari, austin

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

GHC Trac Issues: #10402

Adding app1, app2, as requested in the ticket

Summary:
When we introduced user-friendly library names
(e.g. unix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d instead of
unix_G4Yo1pNtYrk8nCq1cx8P9d) we added a new variable to
be written out by ghc-cabal, $1_$2_LIB_NAME.

What I didn't realize at the time was that this conflicts
with an existing variable in the build system, $1_$2_$3_LIB_NAME,
which (confusingly) refers to something like
'libHSunix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d.so'.  This is pretty
confusing (despite never conflicting), so I renamed this variable
to LIB_FILE for enhanced greppability.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin

Subscribers: thomie, bgamari

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

Summary:
(NB: this code is dead at the moment since Windows is not built
dynamically.)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: none

Reviewers: austin

Subscribers: thomie, bgamari

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

GHC Trac Issues: #10551

Summary:
There's not really any good reason to use -package-key over
-package-id, so use the latter as standard practice.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin

Subscribers: thomie, bgamari

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

verifying fix for #10348