GitLab

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 reverts commit 9513fe6b.

Sadly this broke with -DDEBUG.

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

Test Plan: Validate, should pass.

Reviewers: austin

Subscribers: thomie

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

GHC Trac Issues: #12082

Test Plan: Validate

Reviewers: austin

Subscribers: thomie

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

GHC Trac Issues: #12381, #11348

This cleans up various aspects of the handling of built-in syntax in the
original name cache (hopefully resulting in a nice reduction in compiler
allocations),

  * Remove tuple types from original name cache: There is really no
    reason for these to be in the name cache since we already handle
    them specially in interface files to ensure that we can resolve them
    directly to Names, avoiding extraneous name cache lookups.

  * Sadly it's not possible to remove all traces of tuples from the
    name cache, however. Namely we need to keep the tuple type
    representations in since otherwise they would need to be wired-in

  * Remove the special cases for (:), [], and (##) in isBuiltInOcc_maybe
    and rename it to isTupleOcc_maybe

  * Split lookupOrigNameCache into two variants,

     * lookupOrigNameCache': Merely looks up an OccName in the original
       name cache, making no attempt to resolve tuples

     * lookupOrigNameCache: Like the above but handles tuples as well.
       This is given the un-primed name since it does the "obvious"
       thing from the perspective of an API user, who knows nothing of
       our special treatment of tuples.

Arriving at this design took a significant amount of iteration. The
trail of debris leading here can be found in #11357.

Thanks to ezyang and Simon for all of their help in coming to this
solution.

Test Plan: Validate

Reviewers: goldfire, simonpj, austin

Reviewed By: simonpj

Subscribers: thomie, ezyang

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

GHC Trac Issues: #11357

Previously instIsVisible had completely broken the laziness of
lookupInstEnv' since it would examine is_dfun_name to check the name of
the defining module (to know whether it is an interactive module). This
resulted in the visibility check drawing in an interface file
unnecessarily. This contributed to the unnecessary regression in
compiler allocations reported in #12367.

Test Plan: Validate, check nofib changes

Reviewers: simonpj, ezyang, austin

Reviewed By: ezyang

Subscribers: thomie, ezyang

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

GHC Trac Issues: #12367

* Update the sample error messages. The messages have been reworded and
  reformatted since GHC 7.10.

* Mention `TypeApplications` in "Where can they occur?"

* The name of a named wild card is no longer used in the name of a
  resulting type variable. Before: `_foo` => `w_foo`, now: `_foo` => `t`
  or `a`.

Test Plan: generate the users guide

Reviewers: goldfire, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #12365

Reviewers: austin, hvr, RyanGlScott, bgamari

Reviewed By: RyanGlScott, bgamari

Subscribers: RyanGlScott, thomie

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

GHC Trac Issues: #12402

When trying to build arm64-apple-iso, the build fell over
`strdup`, as the arm64-apple-ios build did not fall into `darwin_HOST_OS`,
and would need `ios_HOST_OS`.

This diff tries to clean up PosixSource.h, instead of layering another
define on top.

As we use `strnlen` in sources that include PosixSource.h, and `strnlen`
is defined in POSIX.1-2008, the `_POSIX_C_SOURCE` and `_XOPEN_SOURCE`
are increased accordingly.

Furthermore the `_DARWIN_C_SOURCE` (required for `u_char`, etc. used in
sysctl.h) define is moved into `OSThreads.h` alongside a similar ifdef
for freebsd.

Test Plan: Build on all supported platforms.

Reviewers: rwbarton, erikd, austin, hvr, simonmar, bgamari

Reviewed By: simonmar, bgamari

Subscribers: thomie

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

This fixes #12128.

The bug was introduced in 1c9fd3f1.

Test Plan: ./validate

Reviewers: simonmar, austin, hvr, simonpj, bgamari

Reviewed By: bgamari

Subscribers: simonpj, thomie

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

GHC Trac Issues: #12128

This allows you to easily move to the result in a well-equipped editor.

Test Plan:
Previously, `Data.{Bifoldable,Bitraversable}` were being inferred as
`Unsafe` due to a transitive `Data.Coerce` import from `Data.Functor.Utils`.
This rectifies this unfortunate mistake.

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: thomie, phadej

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

Not having SCCs at the top level is becoming annoying real quick. For
simplest cases, it's possible to do this transformation:

    f x y = ...
    =>
    f = {-# SCC f #-} \x y -> ...

However, it doesn't work when there's a `where` clause:

    f x y = <t is in scope>
      where t = ...
    =>
    f = {-# SCC f #-} \x y -> <t is out of scope>
      where t = ...

Or when we have a "equation style" definition:

    f (C1 ...) = ...
    f (C2 ...) = ...
    f (C3 ...) = ...
    ...

(usual solution is to rename `f` to `f'` and define a new `f` with a
`SCC`)

This patch implements support for SCC annotations in declaration
contexts. This is now a valid program:

    f x y = ...
      where
        g z = ...
        {-# SCC g #-}
    {-# SCC f #-}

Test Plan: This passes slow validate (no new failures added).

Reviewers: goldfire, mpickering, austin, bgamari, simonmar

Reviewed By: bgamari, simonmar

Subscribers: simonmar, thomie, mpickering

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

Summary:
`okConIdOcc`, which validates that a type or constructor name is valid
for splicing using Template Haskell, has a special case for tuples, but
neglects to look for unboxed tuples, causing some sensible Template Haskell
code involving unboxed tuples to be rejected.

Fixes #12407.

Test Plan: make test TEST=T12407

Reviewers: austin, bgamari, hvr, goldfire

Reviewed By: goldfire

Subscribers: thomie

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

GHC Trac Issues: #12407

Summary:
Previously, Template Haskell reified unboxed tuple types as boxed
tuples with twice the appropriate arity.

Fixes #12403.

Test Plan: make test TEST=T12403

Reviewers: hvr, goldfire, austin, bgamari

Reviewed By: goldfire

Subscribers: thomie

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

GHC Trac Issues: #12403

Summary:
Unboxed tuples have `RuntimeRep` arguments which `-XDeriveFunctor` was
mistaking for actual data constructor arguments. As a result, a derived
`Functor` instance for a datatype that contained an unboxed tuple would
generate twice as many arguments as it needed for an unboxed tuple pattern
match or expression. The solution is to simply put `dropRuntimeRepArgs` in the
right place.

Fixes #12399.

Test Plan: ./validate

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: thomie, osa1

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

GHC Trac Issues: #12399

[ci skip]

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

This is backport of [1] for GHC's copy of Pretty. See Note [Differences
between libraries/pretty and compiler/utils/Pretty.hs].

[1] http://git.haskell.org/packages/pretty.git/commit/bbe9270c5f849a5bb74c9166a5f4202cfb0dba22
    https://github.com/haskell/pretty/issues/32
    https://github.com/haskell/pretty/pull/35

Reviewers: bgamari, austin

Reviewed By: austin

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

GHC Trac Issues: #12227

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

Test Plan: The tests have been included. This change deals with a
relatively minor edge case and should not break unrelated functionality.

Reviewers: thomie, #core_libraries_committee, ekmett, bgamari

Reviewed By: #core_libraries_committee, ekmett, bgamari

Subscribers: bgamari, ekmett

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

GHC Trac Issues: #11632

It's unclear how much of an effect on runtime this will have, but if
nothing else the code generation may be a tad better since the system's
`memcpy` will be used.

Test Plan: Validate

Reviewers: simonmar, austin

Subscribers: thomie

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

This check is not entirely cheap and will not succeed unless we are
looking for something in the module where built-in syntax lives,
GHC.Types.

Reviewers: simonpj, austin

Subscribers: simonpj, thomie, osa1

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

Test Plan: Try it

Reviewers: hvr, simonmar, austin, erikd

Subscribers: thomie

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

GHC Trac Issues: #11094

[ci skip]

Summary:
Signed-off-by: Baldur Blöndal <baldurpet@gmail.com>

Reviewers: goldfire, RyanGlScott, austin, bgamari, hvr

Reviewed By: RyanGlScott, austin

Subscribers: RyanGlScott, thomie

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

GHC Trac Issues: #12057

So that
> :t (id,id,id)
produces
(id,id,id) :: (a3 -> a3, a2 -> a2, a1 -> a1)
instead of
(id,id,id) :: (a2 -> a2, a1 -> a1, a -> a)

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

this refactoring commit prepares for fixing #12382, which can now be
implemented soley in tidyTyCoVarBndrs.

This makes the implementation match the description in the paper more
closely: There, a let binding that is not a function has first its body
analised, and then the binding’s RHS. This way, the demand on the bound
variable by the body can be fed into the RHS, yielding more precise
results.

Performance measurements do unfortunately not show significant
improvements or regessions.

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

This changelog is very incomplete, and basically useless. I'm removing
it, because it made it harder to compare this copy of `Pretty.hs` with
the copy in `libraries/pretty` (from which a similar changelog was
deleted some time ago).

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

Previously we would unpack the OccName into a String, then pattern match
against this string. Due to the implementation of `unpackFS`, this
actually unpacks the entire contents, even though we often only need to
look at the first few characters.

Here we take another approach: build a UniqFM with the known built-in
OccNames, allowing us to use `FastString`'s hash-based comparison
instead.

Reviewers: simonpj, austin, simonmar

Reviewed By: simonmar

Subscribers: thomie

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

GHC Trac Issues: #12357

Reviewed by: Phyx

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

This was the only user of concatFS and really just wants the `String`
anyways.

Stumbled upon while looking at #12357.

Test Plan: Validate

Reviewers: austin

Reviewed By: austin

Subscribers: thomie

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

GHC Trac: #4012

Previously we would form derived OccNames by first decoding the name
being derived from, manipulating it in [Char] form, and then
re-encoding. This is all very wasteful as we essentially always just
want to concatenate. Instead we now take care to form the final name
with only one concatFS.

Test Plan: Validate, examing compiler allocations

Reviewers: simonpj, austin

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #12357

This avoids decoding the entire string just to look at the first
character.

Test Plan: Validate

Reviewers: austin

Subscribers: thomie

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