Test Plan: If it builds, ship it

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

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

Several executables inexplicably appear twice in bindist.list, which
ends up producing multiple tar file entries, consequently breaking BSD
tar during extraction. I spent a fair amount of time trying to work out
where these duplicates were coming from to no avail. Since Hadrian is
right around the corner I'm satisfied with a terrible hack: just uniq
bindist.list before producing the bindist tarball.

Test Plan: Validate

Reviewers: austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #13979, #13974

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

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

This is a conservative assumption which will limit some uses of spliced
patterns, but it fixes #13984.

Test Plan: Validate

Reviewers: RyanGlScott, AaronFriel, austin

Reviewed By: RyanGlScott

Subscribers: rwbarton, thomie

GHC Trac Issues: #13984

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

This reverts commit b2d3ec37. Didn't
mean to push this one.

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

Previously we failed to do this, which meant that the bindist's
configure would fail when passed --target (as you may need to do when
installing an armv7 bindist on an aarch64 machine, for instance).

Reviewers: hvr, erikd, austin

Reviewed By: hvr

Subscribers: rwbarton, thomie

GHC Trac Issues: #13934

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

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

In the fix to #13615 we introduced some logic to atomically blackhole
AP_STACKs closures upon entry. However, this logic was placed *after* a
stack pointer adjustment. This meant that if someone else beat us to
blackholing the AP_STACK we would suspend the thread with uninitialized
content on the stack.  This would then later blow up when threadPaused
attempted to walk the stack, hence #13970.

Silly bug but still cost lots of head-scratching to find.

Thanks to albertov for the great repro.

Fixes #13970. Bug originally introduced by the fix to #13615.

Reviewers: austin, erikd, simonmar

Reviewed By: erikd, simonmar

Subscribers: rwbarton, thomie

GHC Trac Issues: #13970, #13615

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

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

This is another step in fixing #13825 (based on D38 by Simon Marlow).

This commit adds a few macros for accessing and modifying `Sp`
(interpreter stack) and will be useful to allow sub-word
indexing/pushing. (but that will be a separate change, this commit
should introduce no changes in behavior)

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

Test Plan: ./validate

Reviewers: bgamari, simonmar, austin, erikd

Reviewed By: bgamari, erikd

Subscribers: rwbarton, thomie

GHC Trac Issues: #13825

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

Fixes #13803, but adds a note about a yet to be fixed #13981.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: bgamari, austin

Reviewed By: bgamari

Subscribers: simonpj, rwbarton, thomie

GHC Trac Issues: #13803

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

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

Test T13701 was failing sporadically. The problem manifested while the
test was run on a system under load. Profiling showed the increased
allocations were in SysTools.builderMainLoop.loop, during calls to the
assembler. This was due to loop effectively busy-waiting from when both
stdin and stderr handles were closed, until getProcessExitCode
succeeded.

This is fixed by removing exit code handling from loop. We now wait for
loop to finish, then read the exit code with waitForProcess.

Some exception safety is added: the readerProc threads will now be
killed and the handles will be closed if an exception is thrown.

A TODO saying that threads dying is not accounted for is removed. I
believe that this case is handled by readerProc sending EOF in a finally
clause.

Test Plan:
Replicate test failures using procedure on the ticket, verify that they
do not occur with this patch.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13987

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

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

Reviewers: austin

Subscribers: rwbarton, thomie

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

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

Previously the driver would read the stdin content from the source file
and then write it to the subprocess' stdin. We now simply open the stdin
file and provide that handle to the subprocess as its stdin

Test Plan: Validate

Reviewers: austin

Subscribers: rwbarton, thomie, goldfire

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

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

This flag instructs the simplifier to emit ``error`` expressions in the
continutation of empty case analyses (which should bottom and
consequently not return). This is helpful when debugging demand analysis
bugs which can sometimes manifest as segmentation faults.

Test Plan: Validate

Reviewers: simonpj, austin

Subscribers: niteria, rwbarton, thomie

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

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

[skip-ci]

Reviewers: austin

Subscribers: rwbarton, thomie

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

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

This fixes #13915, where the promoted tycons belonging to data family
instances wouldn't get Typeable bindings, resulting in missing
declarations.

Test Plan: Validate with included testcases

Reviewers: austin, simonpj

Reviewed By: simonpj

Subscribers: simonpj, RyanGlScott, rwbarton, thomie

GHC Trac Issues: #13915

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

An error message was referring to a type synonym as a datatype.
Annoyingly, learning that the TyCon over which the error message is
operating is actually a type synonym was previously impossible, since
that code only had access to a TcTyCon, which doesn't retain any
information about what sort of TyCon it is.

To rectify this, I created a new TyConFlavour datatype, intended to
capture roughly what sort of TyCon we're dealing with. I then performing
the necessary plumbing to ensure all TcTyCons have a TyConFlavour, and
propagated this information through to the relevant error message.

Test Plan: ./validate

Reviewers: goldfire, austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie

GHC Trac Issues: #13983

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

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

This fixes #13977 and consequently #13615. Here an optimization in the
demand analyser was too liberal, causing us to drop the ExnStr flag and
consequently resulting in incorrect demand signatures. This manifested
as a segmentation fault in #13615 as we incorrectly concluded that an
application of catchRetry# would bottom.

Specifically, we had

    orElse' :: STM a -> STM a -> STM a
    orElse' x = catchRetry# x y
      where y = {- some action -}

Where the catchRetry# primop places a demand of <xC(S),1*C1(U)> on its
first argument. However, due to #13977 the demand analyser would assign
a demand of <C(S),1*C1(U)> on the first argument of orElse'. Note the
missing `x`.

    case orElse' bottomingAction anotherAction of { x -> Just x }

being transformed to,

    case orElse' bottomingAction anotherAction of {}

by the simplifier. This would naturally blow up when orElse' returned at
runtime, causing the segmentation fault described in #13615.

Test Plan: Validate, perhaps add a testcase

Reviewers: austin, simonpj

Reviewed By: simonpj

Subscribers: rwbarton, thomie

GHC Trac Issues: #13977, #13615

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

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

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: RyanGlScott, rwbarton, thomie

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

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

This fixes #12578.
Update links to SPJ's papers in following files:

  * compiler/coreSyn/CoreSyn.hs
  * docs/users_guide/using-optimisation.rst
  * docs/users_guide/parallel.rst
  * docs/users_guide/glasgow_exts.rst

This commit is for ghc-8.2 branch.

Test Plan: build

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #12578

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

This amounts to a one-line change in `tcExpr`. I've added a Note to
explain what is going on.

This requires a separate change in the pattern-match checker to
account for the fact that typechecked `[]` expressions become
`ConLikeOut`s, not `ExplicitList`s.

Test Plan: make test TEST=T13680

Reviewers: goldfire, mpickering, austin, bgamari

Reviewed By: mpickering, bgamari

Subscribers: rwbarton, thomie, goldfire

GHC Trac Issues: #13680

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

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

Test Plan: Validate

Reviewers: austin, simonmar

Reviewed By: simonmar

Subscribers: simonmar, rwbarton, thomie

GHC Trac Issues: #13434

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

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

Reviewers: austin, hvr

Subscribers: Phyx, rwbarton, thomie

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

When loading/reloading with a large number of modules
(>5000) the cost of linear lookups becomes significant.

The changes here made `:reload` go from 6s to 1s on my
test case.

The bottlenecks were `needsLinker` in `DriverPipeline` and
`getModLoop` in `GhcMake`.

Test Plan: ./validate

Reviewers: simonmar, austin, bgamari

Subscribers: thomie, rwbarton

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

Summary:
When we use nursery chunks with +RTS -n<size>, when the current nursery
runs out we have to check whether there's another chunk available with
getNewNursery().  There was one place we weren't doing this: the ad-hoc
heap check in scheduleProcessInbox().

The impact of the bug was that we would GC too early when using nursery
chunks, especially in programs that used messages (throwTo between
capabilities could do this, also hs_try_putmvar()).

Test Plan: validate, also local testing in our application

Reviewers: bgamari, niteria, austin, erikd

Subscribers: rwbarton, thomie

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

Summary:
This temporarily disabled split-sections again on Windows because
of the overhead in linking it introduces. Unfortunately because BFD
is so slow a testsuite run gets almost 2x slower. Simply linking
Hello World takes an unacceptable long time.

So for now, it'll be disabled as we look into different linkers such
as LLD.

Test Plan: ./validate

Reviewers: austin, bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #12913

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

Test Plan: If it builds, ship it

Reviewers: austin, bgamari

Subscribers: rwbarton, thomie

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

This test appears to be quite unstable.

It seems to be the change to getNameToInstancesIndex that bumped these.

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

When we load non absolute pathed .so's this usually implies that we
expect the system to have them in place already, and hence we should not
need to ship them.  Without the absolute path to the library, we are
also unable to open and send said library.  Thus we'll do library
shipping only for libraries with absolute paths.

When dealing with a host and target of different word size (say host
hast 64bit, target has 32bit), we need to fix the RemotePtr size and the
toWordArray function, as they are part of the iserv ResolvedBCO binary
protocol.  This needs to be word size independent.  The choice for
RemotePtr to 64bit was made to ensure we can store 64bit pointers when
targeting 64bit. The choice for 32bit word arrays was made wrt.
encoding/decoding on the potentially slower device.

The efficient serialization code has been graciously provided by
@bgamari.

Reviewers: bgamari, simonmar, austin, hvr

Reviewed By: bgamari

Subscribers: Ericson2314, rwbarton, thomie, ryantrinkle

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

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

This is a sure sign that something is terribly wrong.

We also now verify that the word size that the binary distribution
expects matches the word size produced by the local target toolchain.

Finally we rename WordSize to TargetWordSize, since non-host/target
qualified quantities are terribly confusing.

Reviewers: austin, hvr, Phyx

Reviewed By: Phyx

Subscribers: Phyx, rwbarton, thomie, erikd

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

Moritz Angermann authored 7 years ago and David Feuer committed 7 years ago

Reviewers: angerman, austin, bgamari, erikd, simonmar

Reviewed By: angerman

Subscribers: rwbarton, thomie

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

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

Previously GHC would always assume that section types began with `@` while
producing assembly, which is not true. For instance, in ARM assembly syntax
section types begin with `%`. This abstracts out section type pretty-printing
and adjusts it to correctly account for the target architectures assembly
flavor.

Reviewers: austin, hvr, Phyx

Reviewed By: Phyx

Subscribers: Phyx, rwbarton, thomie, erikd

GHC Trac Issues: #13937

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

Previously -Werror or -Werror=flag printed warnings as usual and then
printed
these two lines:

    <no location info>: error:
    Failing due to -Werror.

This is not ideal: first, it's not clear which flag made one of the
warnings an
error. Second, warning messages are not modified in any way, so there's
no way
to know which warnings caused this error.

With this patch we (1) promote warning messages to error messages if a
relevant
-Werror is enabled (2) mention which -Werror is used during this
promotion.

Previously:

    [1 of 1] Compiling Main             ( test.hs, test.o )

    test.hs:9:10: warning: [-Wincomplete-patterns]
        Pattern match(es) are non-exhaustive
        In a case alternative: Patterns not matched: (C2 _)
      |
    9 | sInt s = case s of
      |          ^^^^^^^^^...

    test.hs:12:14: warning: [-Wmissing-fields]
        • Fields of ‘Rec’ not initialised: f2
        • In the first argument of ‘print’, namely ‘Rec {f1 =
1}’
          In the expression: print Rec {f1 = 1}
          In an equation for ‘main’: main = print Rec {f1 = 1}
       |
    12 | main = print Rec{ f1 = 1 }
       |              ^^^^^^^^^^^^^

    <no location info>: error:
    Failing due to -Werror.

Now:

    [1 of 1] Compiling Main             ( test.hs, test.o )

    test.hs:9:10: error: [-Wincomplete-patterns,
-Werror=incomplete-patterns]
        Pattern match(es) are non-exhaustive
        In a case alternative: Patterns not matched: (C2 _)
      |
    9 | sInt s = case s of
      |          ^^^^^^^^^...

    test.hs:12:14: error: [-Wmissing-fields, -Werror=missing-fields]
        • Fields of ‘Rec’ not initialised: f2
        • In the first argument of ‘print’, namely ‘Rec {f1 =
1}’
          In the expression: print Rec {f1 = 1}
          In an equation for ‘main’: main = print Rec {f1 = 1}
       |
    12 | main = print Rec{ f1 = 1 }
       |              ^^^^^^^^^^^^^

Test Plan: - Update old tests, add new tests if there aren't any
relevant tests

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

* Remove the redundant import of `Data.Maybe` from `GHC.Foreign`.

* Fix the note in `GHC.Stack.Types` to give a correct explanation
of the problematic cycle.

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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