GitLab

Test Plan: GHC CI

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: snowleopard, thomie

Maniphest Tasks: T74

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

This patch reverts the change introduced with
587dcccf and restores the previous
default output of GHC (i.e., show source path and object path for each
compiled module).

The -fhide-source-paths flag can be used to hide these paths and reduce
the line
noise.

Reviewers: gracjan, nomeata, austin, bgamari, simonmar, hvr

Reviewed By: hvr

Subscribers: thomie

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

GHC Trac Issues: #12851

This is a preliminary commit to add colors to diagnostics (warning and
error messages).  The aesthetic changes are:

  - 'warning', 'error', and 'fatal' are all colored magenta, red, and
    red respectively.
  - The warning annotation [-Wsomething] shares the same color.
  - Warnings and errors are also bolded (this is consistent with what
    other compilers do).

A new flag has been added to control the behavior:

    -fdiagnostics-color=(always|auto|never)

This flag is 'auto' by default.  However, auto-detection is not
implemented yet, so it effectively it defaults to off.

Test Plan: validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #8809

This patch add new options `-Werror=...`, `-Wwarn=...` and
`-Wno-error=...` (synonym for `-Wwarn=...`).

Semantics:

  - `-Werror` marks all warnings as fatal, including those that don't
    have a warning flag, and CPP warnings.
  - `-Werror=...` enables a warning and marks it as fatal
  - `-Wwarn=...` marks a warning as non-fatal, but doesn't disable it

Test Plan: validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: mpickering, svenpanne, RyanGlScott, thomie

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

GHC Trac Issues: #11219

Reviewers: simonmar, mpickering, austin, bgamari

Reviewed By: bgamari

Subscribers: mpickering, nomeata, thomie

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

GHC Trac Issues: #12807

Otherwise we end up looking in the wrong place for dynamic libraries on
Windows. This addresses a regression introduced by D2611. See #12479.

Test Plan: validate across platforms

Reviewers: austin

Subscribers: thomie

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

GHC Trac Issues: #12479

Currently passing the `CONF_LD_LINKER_OPTS_STAGE0` environment
variable to `configure` is broken due to this naming inconsistency.

Test Plan: Try passing `CONF_LD_LINKER_OPTS_STAGE0` to `configure`.
Look at resulting stage0 ghc invocation.

Reviewers: austin

Subscribers: thomie

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

Summary:
This omits -L and -l flags from the linker command line that shouldn't
be necessary because GHC will already add them via the -package-id
flags we pass.

This also reverts part of 90538d86
that rearranges the linker command line and causes some knock-on
problems (see D2618).

Test Plan: validate (need to validate on Windows too)

Reviewers: Phyx, bgamari, niteria, austin, erikd

Subscribers: thomie

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

GHC Trac Issues: #12738

Summary:
This also changes the backpack Renaming type to use a Maybe for the
renameTo field, to more accurately reflect the parsed source.

Updates haddock submodule to match AST changes

Test Plan: ./validate

Reviewers: ezyang, bgamari, austin

Reviewed By: bgamari

Subscribers: thomie, mpickering

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

Summary:
Build systems / package managers want to be able to control the file
layout of installed libraries. In general they may want/need to be able
to put the static libraries and dynamic libraries in different places.
The ghc-pkg library regisrtation needs to be able to handle this.

This is already possible in principle by listing both a static lib dir
and a dynamic lib dir in the library-dirs field (indeed some previous
versions of Cabal did this for shared libs on ELF platforms).

The downside of listing both dirs is twofold. There is a lack of
precision, if we're not careful with naming then we could end up
picking up the wrong library. The more immediate problem however is
that if we list both directories then both directories get included
into the ELF and Mach-O shared object runtime search paths. On ELF this
merely slows down loading of shared libs (affecting prog startup time).
On the latest OSX versions this provokes a much more serious problem:
that there is a rather low limit on the total size of the section
containing the runtime search path (and lib names and related) and thus
listing any unnecessary directories wastes the limited space.

So the solution in this patch is fairly straightforward: split the
static and dynamic library search paths in the ghc-pkg db and its use
within ghc. This is a traditional solution: pkg-config has the same
static / dynamic split (though it describes in in terms of private and
public, but it translates into different behaviour for static and
dynamic linking).

Indeed it would make perfect sense to also have a static/dynamic split
for the list of the libraries to use i.e. to have dynamic variants of
the hs-libraries and extra-libraries fields. These are not immediately
required so this patch does not add it, but it is a reasonable
direction to follow.

To handle compatibility, if the new dynamic-library-dirs field is not
specified then its value is taken from the library-dirs field.

Contains Cabal submodule update.

Test Plan:
Run ./validate

Get christiaanb and carter to test it on OSX Sierra, in combination
with Cabal/cabal-install changes to the default file layout for
libraries.

Reviewers: carter, austin, hvr, christiaanb, bgamari

Reviewed By: christiaanb, bgamari

Subscribers: ezyang, Phyx, thomie

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

GHC Trac Issues: #12479

Previously BinIface had some dedicated logic for handling tuple names in
the symbol table. As it turns out, this logic was essentially dead code
as it was superceded by the special handling of known-key things. Here
we cull the tuple code-path and use the known-key codepath for all
tuple-ish things.

This had a surprising number of knock-on effects,

 * constraint tuple datacons had to be made known-key (previously they
   were not)

 * IfaceTopBndr was changed from being a synonym of OccName to a
   synonym of Name (since we now need to be able to deserialize Names
   directly from interface files)

 * the change to IfaceTopBndr complicated fingerprinting, since we need
   to ensure that we don't go looking for the fingerprint of the thing
   we are currently fingerprinting in the fingerprint environment (see
   notes in MkIface). Handling this required distinguishing between
   binding and non-binding Name occurrences in the Binary serializers.

 * the original name cache logic which previously lived in IfaceEnv has
   been moved to a new NameCache module

 * I ripped tuples and sums out of knownKeyNames since they introduce a
   very large number of entries. During interface file deserialization
   we use static functions (defined in the new KnownUniques module) to
   map from a Unique to a known-key Name (the Unique better correspond
   to a known-key name!) When we need to do an original name cache
   lookup we rely on the parser implemented in isBuiltInOcc_maybe.

 * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames.

 * Lots of comments were sprinkled about describing the new scheme.

Updates haddock submodule.

Test Plan: Validate

Reviewers: niteria, simonpj, austin, hvr

Reviewed By: simonpj

Subscribers: simonmar, niteria, thomie

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

GHC Trac Issues: #12532, #12415

It turns out that we don't really need to be able to
extract a ComponentId from UnitId, except in one case.
So compress UnitId into a single FastString.

The one case where we do need the ComponentId is when
we are compiling an instantiated version of a package;
we need the ComponentId to look up the indefinite
version of this package from the database.  So now we
just pass it in as an argument -this-component-id.

Also: ghc-pkg now no longer will unregister a package if
you register one with the same package name, if the
instantiations don't match.

Cabal submodule update which tracks the same data type
change.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

Summary:
This patch implements Backpack for GHC.  It's a big patch but I've tried quite
hard to keep things, by-in-large, self-contained.

The user facing specification for Backpack can be found at:

    https://github.com/ezyang/ghc-proposals/blob/backpack/proposals/0000-backpack.rst

A guide to the implementation can be found at:

    https://github.com/ezyang/ghc-proposals/blob/backpack-impl/proposals/0000-backpack-impl.rst

Has a submodule update for Cabal, as well as a submodule update
for filepath to handle more strict checking of cabal-version.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, simonmar, bgamari, goldfire

Subscribers: thomie, mpickering

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

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

This apparently should have been an import of rawSystem instead of
runProcess. Oops.

Fixes D2538.

Test Plan: Validate on Linux and Windows.

Reviewers: austin, snowleopard

Reviewed By: snowleopard

Subscribers: thomie

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

Summary:
Note that Cabal needs one more bugfix which is in PR to
fix GHC bootstrapping. But the rest of the patch is
ready for review.

Needs a filepath submodule update because cabal check
became more strict.

This patch handles the abstract-ification of Version and
PackageName.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: bgamari, austin

Subscribers: thomie

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

This means that, on POSIX systems, there will be only one ghc process
used for running scripts, as opposed to the current situation of a
runghc process and a ghc process. Beyond minor performance benefits of
not having an extra fork and resident process, the more important impact
of this is automatically getting proper signal handling. I noticed this
problem myself when running runghc as PID1 inside a Docker container.

I attempted to create a shim library for executeFile that would work for
both POSIX and Windows, but unfortunately I ran into issues with exit
codes being propagated correctly (see
https://github.com/fpco/replace-process/issues/2). Therefore, this patch
leaves the Windows behavior unchanged. Given that signals are a POSIX
issue, this isn't too bad a trade-off. If someone has suggestions for
better Windows _exec support, please let me know.

Reviewers: erikd, austin, bgamari

Reviewed By: bgamari

Subscribers: Phyx, thomie

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

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #12637

Allows users to explicitly request which approach to `deriving` to use
via keywords, e.g.,

```
newtype Foo = Foo Bar
  deriving Eq
  deriving stock    Ord
  deriving newtype Show
```

Fixes #10598. Updates haddock submodule.

Test Plan: ./validate

Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin,
erikd, simonmar

Reviewed By: alanz, bgamari, simonpj

Subscribers: thomie, mpickering, oerjan

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

GHC Trac Issues: #10598

Fixes #12519

Test Plan: Read it

Reviewers: dfeuer, austin

Subscribers: thomie

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

GHC Trac Issues: #11691

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

Reviewers: simonpj, thomie, austin, bgamari

Reviewed By: simonpj, thomie, bgamari

Subscribers: simonpj, thomie

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

GHC Trac Issues: #12170

Reviewers: thomie, bgamari, austin

Reviewed By: thomie, bgamari

Subscribers: thomie

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

GHC Trac Issues: #9089

In outHsLine, paths passed to construct invocations of hsc_line must be
escaped twice in order to generate a properly escaped string literal
that will end up in the eventual LINE pragma emitted by this code. This
is especially important on Windows paths, where backslashes would
otherwise be treated as C escape sequences and result in the incorrect
Windows paths.

Adds test case to verify that hsc2hs properly escapes file paths in LINE
pragmas

Updates the hsc2hs submodule.

See https://ghc.haskell.org/trac/ghc/ticket/12504

Reviewers: erikd, hvr, austin, bgamari, Phyx

Reviewed By: erikd, Phyx

Subscribers: thomie, Phyx, mpickering

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

GHC Trac Issues: #12504

Reviewers: austin, thomie, bgamari

Reviewed By: bgamari

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

GHC Trac Issues: #12517

There's a substantial bump to the haddock.Cabal allocation
stats, because we added 50% more modules, so of course allocations
are going to increase 50%. (But perhaps this is indicative of
some bad constant factor in Haddock related to modules.)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: ggreif, austin, bgamari

Subscribers: thomie

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

... in LocalBuildInfo, getting rid of a TODO in the
process. Turns out that componentsConfigs won't be
a field in Cabal 2.0 any more, so this can be seen
as a preparation for it.

... that we grep out of libraries/Cabal/Cabal/Cabal.cabal

This is necessary because the file got reformatted
in the 'master' branch.

I needed to rnf a data structure (CompiledByteCode) but we don't have
any good deepseq infrastructure in the compiler yet.  There are bits and
pieces, but nothing consistent, so this is a start.

We already had a dependency on deepseq indirectly via other packages
(e.g. containers).

Includes an update to the haddock submodule, to remove orphan NFData
instances in there.

Test Plan: validate

Reviewers: austin, bgamari, erikd, hvr

Subscribers: thomie

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

Summary:
This patch implements primitive unboxed sum types, as described in
https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes.

Main changes are:

- Add new syntax for unboxed sums types, terms and patterns. Hidden
  behind `-XUnboxedSums`.

- Add unlifted unboxed sum type constructors and data constructors,
  extend type and pattern checkers and desugarer.

- Add new RuntimeRep for unboxed sums.

- Extend unarise pass to translate unboxed sums to unboxed tuples right
  before code generation.

- Add `StgRubbishArg` to `StgArg`, and a new type `CmmArg` for better
  code generation when sum values are involved.

- Add user manual section for unboxed sums.

Some other changes:

- Generalize `UbxTupleRep` to `MultiRep` and `UbxTupAlt` to
  `MultiValAlt` to be able to use those with both sums and tuples.

- Don't use `tyConPrimRep` in `isVoidTy`: `tyConPrimRep` is really
  wrong, given an `Any` `TyCon`, there's no way to tell what its kind
  is, but `kindPrimRep` and in turn `tyConPrimRep` returns `PtrRep`.

- Fix some bugs on the way: #12375.

Not included in this patch:

- Update Haddock for new the new unboxed sum syntax.

- `TemplateHaskell` support is left as future work.

For reviewers:

- Front-end code is mostly trivial and adapted from unboxed tuple code
  for type checking, pattern checking, renaming, desugaring etc.

- Main translation routines are in `RepType` and `UnariseStg`.
  Documentation in `UnariseStg` should be enough for understanding
  what's going on.

Credits:

- Johan Tibell wrote the initial front-end and interface file
  extensions.

- Simon Peyton Jones reviewed this patch many times, wrote some code,
  and helped with debugging.

Reviewers: bgamari, alanz, goldfire, RyanGlScott, simonpj, austin,
           simonmar, hvr, erikd

Reviewed By: simonpj

Subscribers: Iceland_jack, ggreif, ezyang, RyanGlScott, goldfire,
             thomie, mpickering

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

This brings in initial support for compact regions, as described in the
ICFP 2015 paper "Efficient Communication and Collection with Compact
Normal Forms" (Edward Z. Yang et.al.) and implemented by Giovanni
Campagna.

Some things may change before the 8.2 release, but I (Simon M.) wanted
to get the main patch committed so that we can iterate.

What documentation there is is in the Data.Compact module in the new
compact package.  We'll need to extend and polish the documentation
before the release.

Test Plan:
validate
(new test cases included)

Reviewers: ezyang, simonmar, hvr, bgamari, austin

Subscribers: vikraman, Yuras, RyanGlScott, qnikst, mboes, facundominguez, rrnewton, thomie, erikd

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

GHC Trac Issues: #11493

The names in the .hp files may contain un-matched opening parentheses,
so escape them.

GHC Trac: #9517

Reviewers: bgamari, austin

Reviewed By: bgamari, austin

Subscribers: thomie

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

GHC Trac Issues: #9517

The `-ddump-cmm` put all stages of Cmm processing into one output.
This patch changes its behavior and adds two more options to make
Cmm dumping flexible.

- `-ddump-cmm-from-stg` dumps only initial version of  Cmm right after
   STG->Cmm codegen
- `-ddump-cmm` dumps the final result of the Cmm pipeline processing
- `-ddump-cmm-verbose` dumps intermediate output of each Cmm pipeline
   step
- `-ddump-cmm-proc` and `-ddump-cmm-caf` seems were lost. Now enabled

Test Plan: ./validate

Reviewers: thomie, simonmar, austin, bgamari

Reviewed By: thomie, simonmar

Subscribers: simonpj, thomie

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

GHC Trac Issues: #11717

Previously it loaded by modulename, which prevented loading files with a
Main module.

This makes pattern synonym signatures more consistent with normal
type signatures.

Updates haddock submodule.

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