Ben Gamari authored 9 years ago and Ben Gamari committed 9 years ago

This adds basic support to the RTS for DWARF-assisted unwinding of the
Haskell and C stack via libdw. This only adds the infrastructure;
consumers of this functionality will be introduced in future diffs.

Currently we are carrying the initial register collection code in
Libdw.c but this will eventually make its way upstream to libdw.

Test Plan: See future patches

Reviewers: Tarrasch, scpmw, austin, simonmar

Reviewed By: austin, simonmar

Subscribers: simonmar, thomie, erikd

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

GHC Trac Issues: #10656

See Trac #10773

Remove Control.Monad.IO.Class from `transformers`. Updates
`transformers` submodule.

See Trac #10773

Test Plan: ./validate

Reviewers: ekmett, hvr, bgamari, austin

Reviewed By: hvr, bgamari, austin

Subscribers: thomie

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

GHC Trac Issues: #10773

Tamar Christina authored 9 years ago and Thomas Miedema committed 9 years ago

Silence the unconditional debugBelch statements recently added to HEAD
which on Windows cause debug information to always be printed.

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

There are multiple hacks all over the build system to account for the
fact that the ghc package uses different build subdirectories
(stage1/stage2) than the other packages (dist/dist-install).

One such hack filtered on 'ghc%', with the intention of filtering the
ghc package only. After renaming bin-package-db to ghc-boot
(d2f9972a, Phab:D1313, #10796), ghc-boot
also got caught in the hack, which broke the build when running without
parallelism.

This patch replaces the before mentioned hack by a different one, such
that filtering on 'ghc%' is no longer necessary. See Note [inconsistent
distdirs].

Reviewed by: austin

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

Summary: This was left off in the previous commits.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Reviewed By: ekmett

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

Signed-off-by: Austin Seipp <austin@well-typed.com>

See #10911.

Reviewers: ekmett

Signed-off-by: Austin Seipp <austin@well-typed.com>

Fixes #10267. Typed holes in typed Template Haskell currently don't work.
See #10945 and #10946.

This implements DuplicateRecordFields, the first part of the
OverloadedRecordFields extension, as described at
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields

This includes fairly wide-ranging changes in order to allow multiple
records within the same module to use the same field names.  Note that
it does *not* allow record selector functions to be used if they are
ambiguous, and it does not have any form of type-based disambiguation
for selectors (but it does for updates). Subsequent parts will make
overloading selectors possible using orthogonal extensions, as
described on the wiki pages.  This part touches quite a lot of the
codebase, and requires changes to several GHC API datatypes in order
to distinguish between field labels (which may be overloaded) and
selector function names (which are always unique).

The Haddock submodule has been adapted to compile with the GHC API
changes, but it will need further work to properly support modules
that use the DuplicateRecordFields extension.

Test Plan: New tests added in testsuite/tests/overloadedrecflds; these
will be extended once the other parts are implemented.

Reviewers: goldfire, bgamari, simonpj, austin

Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie,
goldfire

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

And that allows us to remove the nasty import of HsBinds,
which has no business in this module.

Test Plan: Validate on x86_64, PowerPC and Arm

Reviewers: simonmar, austin, bgamari

Subscribers: thomie

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

GHC Trac Issues: #10977

Tamar Christina authored 9 years ago and Thomas Miedema committed 9 years ago

Add a missing #ifdef

Reviewed By: simonmar

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

On 64-bit ELF we need to link object files into the low 2GB due to the
small memory model.  Previously we would map the entire object file
using MAP_32BIT, but the object file can consist of 75% or more
symbols, which only need to be present during linking, so this is
wasteful.  In our particular application, we're already running out of
space here.

This patch changes the way we load object files on ELF platforms so
that the object is first mapped above the 2GB boundary, parsed, and
then the important sections are re-mapped into the low 2GB area.

Test Plan:
validate
(also needs testing on OS X & Windows, preferably 32 & 64 bit)

Reviewers: Phyx, trommler, bgamari, austin

Subscribers: hsyl20, thomie, bgamari

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

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

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

Comes with Haddock submodule update.

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

This commit contains a Cabal submodule update which unifies installed
package IDs and package keys under a single notion, a Component ID.
We update GHC to keep follow this unification.  However, this commit
does NOT rename installed package ID to component ID and package key to
unit ID; the plan is to do that in a companion commit.

    - Compiler info now has "Requires unified installed package IDs"

    - 'exposed' is now expected to contain unit keys, not IPIDs.

    - Shadowing is no more.  We now just have a very simple strategy
      to deal with duplicate unit keys in combined package databases:
      if their ABIs are the same, use the latest one; otherwise error.
      Package databases maintain the invariant that there can only
      be one entry of a unit ID.

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

Test Plan: validate

Reviewers: simonpj, austin, bgamari, hvr, goldfire

Subscribers: thomie

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

GHC Trac Issues: #10714

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

Arm has two instruction sets, Arm and Thumb, and an execution mode for each.
Executing Arm code in Thumb mode or vice-versa will likely result in an
Illegal instruction exception.

Furthermore, Haskell code compiled via LLVM was generating Arm instructions
while C code compiled via GCC was generating Thumb code by default. When
these two object code types were being linked by the system linker, all was
fine, because the system linker knows how to jump and call from one
instruction set to the other.

The first problem was with GHCi's object code loader which did not know
about Thumb vs Arm. When loading an object file `StgCRun` would jump
into the loaded object which could change the mode causing a crash after
it returned. This was fixed by forcing all C code to generate Arm
instructions by passing `-marm` to GCC.

The second problem was the `mkJumpToAddr` function which was generating
Thumb instructions. Changing that to generate Arm instructions instead
results in a working GHCi on Arm.

Test Plan: validate on x86_64 and arm

Reviewers: bgamari, austin, hvr

Subscribers: thomie

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

GHC Trac Issues: #10375

Signed-off-by: Austin Seipp <austin@well-typed.com>

Before this commit, GHC only supported LLVM 3.6. Now it only supports
LLVM 3.7 which was released in August 2015. LLVM version 3.6 and earlier
do not work on AArch64/Arm64, but 3.7 does.

Also:
* Add CC_Ghc constructor to LlvmCallConvention.
* Replace `maxSupportLlvmVersion`/`minSupportLlvmVersion` with
  a single `supportedLlvmVersion` variable.
* Get `supportedLlvmVersion` from version specified in configure.ac.
* Drop llvmVersion field from DynFlags (no longer needed because only
  one version is supported).

Test Plan: Validate on x86_64 and arm

Reviewers: bgamari, austin

Subscribers: thomie

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

GHC Trac Issues: #10953

See #10216.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Fixes #8010, according to the specified libraries proposal. [1]

Also, some minor wordsmithing.

  [1] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/22709



Signed-off-by: Austin Seipp <austin@well-typed.com>

The previous users' guide documentation was too implementation-oriented. This
attempts to make it more accessible to those who aren't familiar with how
`-XDeriveFunctor` and friends work (and more importantly, what will not work
when using them).

Fixes #10831.

Reviewed By: austin

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

GHC Trac Issues: #10831

Currently, GHC's warning generation code is assuming that a name (`RdrName`)
can be imported at most once. This is a correct assumption, because 1) it's OK
to import same names as long as we don't use any of them 2) when we use one of
them, GHC generates an error because it doesn't disambiguate it automatically.

But apparently the story is different with typeclass methods. If I import two
methods with same names, it's OK to use them in typeclass instance
declarations, because the context specifies which one to use. For example, this
is OK (where modules A and B define typeclasses A and B, both with a function
has),

    import A
    import B

    data Blah = Blah

    instance A Blah where
      has = Blah

    instance B Blah where
      has = Blah

But GHC's warning generator is not taking this into account, and so if I change
import list of this program to:

    import A (A (has))
    import B (B (has))

GHC is printing these warnings:

    Main.hs:5:1: Warning:
        The import of ‘A.has’ from module ‘A’ is redundant

    Main.hs:6:1: Warning:
        The import of ‘B.has’ from module ‘B’ is redundant

Why? Because warning generation code is _silently_ ignoring multiple symbols
with same names.

With this patch, GHC takes this into account. If there's only one name, then
this patch reduces to the previous version, that is, it works exactly the same
as current GHC (thanks goes to @quchen for realizing this).

Reviewed By: austin

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

GHC Trac Issues: #10890

Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function
freak out if using a `Data` instance that produces a `Constr` (by means of
`toConstr`) using a function name instead of a data constructor name. While
such `Data` instances are somewhat questionable, they are nevertheless present
in popular libraries (e.g., `containers`), so we can at least make `dataToQa`
aware of their existence.

In order to properly distinguish strings which represent variables (as opposed
to data constructors), it was necessary to move functionality from `Lexeme` (in
`ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named
`bin-package-db`).

Reviewed By: goldfire, thomie

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

GHC Trac Issues: #10796

Add some commas, fix some typos, etc.

Signed-off-by: Alexander Berntsen <alexander@plaimi.net>

Reviewed By: austin

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

This fallout was caused by f8fbf385 (see #10935), and looks easy
enough, but admittedly I just tried patching the output, so we're doing it
live.

Signed-off-by: Austin Seipp <austin@well-typed.com>

HERMIT users depend on RULES to specify equational properties. 7.10.2
performed both inlining and simplification in both sides of the rules, meaning
they can't really be used for this. This breaks most HERMIT use cases.  A
separate commit already disabled this for the LHS of rules. This does so for
the RHS.

See Trac #10829 for nofib results.

Reviewed By: austin, bgamari, simonpj

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

GHC Trac Issues: #10829

This patch is driven by Trac #10935, and reinstates the
-fwarn-monomorphism-restriction warning.  It was first lost in 2010:
d2ce0f52 "Super-monster patch implementing the new typechecker -- at
last"

I think the existing documentation is accurate; it is not even
turned on by -Wall.

I added one test.

This refactors `(>>)`/`(*>)`/`return`/`pure` methods into normal form.

The redundant explicit `return` method definitions are dropped
altogether.

The explicit `(>>) = (*>)` definitions can't be removed yet, as
the default implementation of `(>>)` is still in terms of `(*>)`
(even though that should have been changed according to the AMP but
wasn't -- see note in GHC.Base for details why this had to be postponed)

A nofib comparision shows this refactoring to result in minor runtime
improvements (unless those are within normal measurement fluctuations):

        Program           Size    Allocs   Runtime   Elapsed  TotalMem
  -------------------------------------------------------------------------
            Min          -0.0%     -0.0%     -1.6%     -3.9%     -1.1%
            Max          -0.0%     +0.0%     +0.5%     +0.5%      0.0%
  Geometric Mean         -0.0%     -0.0%     -0.4%     -0.5%     -0.0%

Full `nofib` report at https://phabricator.haskell.org/P68

Reviewers: quchen, alanz, austin, #core_libraries_committee, bgamari

Reviewed By: bgamari

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

Summary: Test included.

Test Plan: Run test T10870.hs on X86/X86_64/Arm/Arm64 etc

Reviewers: bgamari, nomeata, austin

Subscribers: thomie

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

GHC Trac Issues: #10870

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

Sphinx may trip over itself when multiple instances are run in parallel.

Fixes #10950.

Test Plan: validate

Reviewers: simonpj, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

Ben Gamari authored 9 years ago and Ben Gamari committed 9 years ago

This can happen because the underlying primitive operations in
`integer-gmp` don't support negative shift-amounts, and since
`integer-gmp` can't throw proper exceptions and just provides a
low-level API, it simply segfaults instead...

This patch simply removes the `shift{L,R}` method definitions (and
defines `unsafeShift{L,R}` instead) whose default-impls fallback on
using `shift` which properly handles negative shift arguments.

This addresses #10571

Test Plan: harbormaster can do it

Reviewers: hvr, austin, rwbarton

Subscribers: rwbarton, thomie, bgamari

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

GHC Trac Issues: #10571

Tamar Christina authored 9 years ago and Thomas Miedema committed 9 years ago

Make Linker.hs try asking gcc for lib%s.dll as well, also changed tryGcc
to pass -L to all components by using -B instead. These two fix
shortnames linking on windows.

re-enabled tests: ghcilink003, ghcilink006 and T3333
Added two tests: load_short_name and enabled T1407 on windows.

Reviewed By: thomie, bgamari

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

GHC Trac Issues: #9878, #1407, #1883, #5289