GitLab

* Add stage specific versions of SRC_HC_OPTS. These are currently only
  used for -Werror. The previous combination of GhcStage2HcOpts and
  GhcLibHcOpts didn't apply to utils/*.

* Add stage specific versions of SRC_HC_WARNING_OPTS. These will later be
  used for new warning supression flags that should not be passed to the
  bootstrap compiler.

* Move -Wall (and -Werror) related code back to mk/warnings.mk, where it
  was before 987d5427. Now all warning related code is nicely together.
  Include mk/warnings.mk after mk/custom-settings.mk to make this work.

Reviewed By: bgamari, hvr

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

This patch is similar to the AMP patch (#8004), which offered two
functions:

  1. Warn when an instance of a class has been given, but the type does
     not have a certain superclass instance
  2. Warn when top-level definitions conflict with future Prelude names

These warnings are issued as part of the new `-Wcompat` warning group.

Reviewers: hvr, ekmett, austin, bgamari

Reviewed By: hvr, ekmett, bgamari

Subscribers: ekmett, thomie

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

GHC Trac Issues: #11139

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

Since f16ddcee / D876, `ghc-stage1`
supports a subset of `-XTemplateHaskell`, but since we need Cabal to be
able detect (so `.cabal` files can be specified accordingly, see also
GHC #11102 which omits `TemplateHaskell` from `--supported-extensions`)
whether GHC provides full or only partial `-XTemplateHaskell` support,
the proper way to accomplish this is to split off the
quotation/non-splicing `TemplateHaskell` feature-subset into a new
language pragma `TemplateHaskellQuotes`.

Moreover, `-XTemplateHaskellQuotes` is considered safe under SafeHaskell

This addresses #11121

Reviewers: goldfire, ezyang, dterei, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #11121

This should catch duplicate uniques in the future before Bad Things
happen.

Test Plan: Introduce a duplicate unique and validate

Reviewers: austin, hvr, thomie

Reviewed By: hvr, thomie

Subscribers: thomie

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

Reviewers: hvr, austin, thomie, bgamari

Reviewed By: hvr, austin, thomie, bgamari

Subscribers: thomie

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

GHC Trac Issues: #11000

Warn about incoherent/non-canonical 'Applicative'/'Monad' instance
declarations. Specifically the following invariants are checked:

In 'Monad' instances declarations warn if the any of the following
conditions does not hold:

 * If `return` is overridden it must be canonical (i.e. `return = pure`).
 * If `(>>)` is overridden it must be canonical (i.e. `(>>) = (*>)`).

In 'Applicative' instance declarations:

 * Warn if 'pure' is defined backwards (i.e. `pure = return`).
 * Warn if '(*>)' is defined backwards (i.e. `(*>) = (>>)`).

NB, this warning flag is not enabled via `-Wall` nor `-Wcompat`.

This addresses #11128

Reviewers: quchen, austin, bgamari

Reviewed By: bgamari

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

We now only strip block information from DebugBlocks when compiling with
`-g1`, intended to be used when only minimal debug information is
desired. `-g2` is assumed when `-g` is passed without any integer
argument.

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

At the moment the API Annotations can only be used on the ParsedSource,
as there are changes made to the RenamedSource that prevent it from
being used to round trip source code.

It is possible to build a map from every Located Name in the
RenamedSource from its location to the Name, which can then be used when
resolved names are required when changing the ParsedSource.

However, there are instances where the identifier is not located,
specifically

  (GHC.VarPat name)
  (GHC.HsVar name)
  (GHC.UserTyVar name)
  (GHC.HsTyVar name)

Replace each of the name types above with (Located name)

Updates the haddock submodule.

Test Plan: ./validate

Reviewers: austin, goldfire, bgamari

Reviewed By: bgamari

Subscribers: goldfire, thomie, mpickering

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

GHC Trac Issues: #11019

On IBM AIX `nm` doesn't support reporting symbol sizes, so we need to
resort to `objdump` instead, which has a peculiar output format on AIX.

depends on D1499

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: kgardas, thomie

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

`derivedConstants` currently uses `System.Info.os` for decisions (which
doesn't necessarily reflect the build-target), as well as hardcoding
"/usr/bin/objdump" for openbsd.

This patch auto-detects `objdump` similiar to how `nm` is detected via
Autoconf as well as passing the target-os into `derivedConstants` via
commandline.

Reviewers: austin, kgardas, erikd, bgamari

Reviewed By: kgardas, erikd, bgamari

Subscribers: kgardas, thomie, erikd

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

These were far too noisy to enable by default. In the future we will
hopefully have a more variant of -Wall targetted at these sorts of
diagnostics.

In the interim I've pointed out the existence of these options in the
release
notes in hopes that people will discover them.

Test Plan: Validate

Reviewers: hvr, austin

Subscribers: thomie

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

Summary:
This reverts commit 06d46b1e.

This also has a Haddock submodule update.

Test Plan: validate

Reviewers: simonpj, austin, bgamari

Subscribers: thomie

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

This adds a flag -split-sections that does similar things to
-split-objs, but using sections in single object files instead of
relying on the Satanic Splitter and other abominations. This is very
similar to the GCC flags -ffunction-sections and -fdata-sections.

The --gc-sections linker flag, which allows unused sections to actually
be removed, is added to all link commands (if the linker supports it) so
that space savings from having base compiled with sections can be
realized.

Supported both in LLVM and the native code-gen, in theory for all
architectures, but really tested on x86 only.

In the GHC build, a new SplitSections variable enables -split-sections
for relevant parts of the build.

Test Plan: validate with both settings of SplitSections

Reviewers: dterei, Phyx, austin, simonmar, thomie, bgamari

Reviewed By: simonmar, thomie, bgamari

Subscribers: hsyl20, erikd, kgardas, thomie

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

GHC Trac Issues: #8405

We no longer parse old-style GADT syntax but there was some left-over
code for emitting deprecation warnings.

Updates haddock submodule.

Test Plan: ./validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

This patch implements #10653.

It adds the ability to bundle pattern synonyms with type constructors in
export lists so that users can treat pattern synonyms more like data
constructors.

Updates haddock submodule.

Test Plan: ./validate

Reviewers: goldfire, austin, bgamari

Reviewed By: bgamari

Subscribers: simonpj, gridaphobe, thomie

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

GHC Trac Issues: #10653

When cross-compiling ghc itself, this prevents:

  "dll-split: cannot execute binary file: Exec format error"

Test Plan:
   * ./configure --target=arm-linux-gnueabihf
   * DYNAMIC_GHC_PROGRAMS=YES
   * Stage1Only=NO

Reviewers: rwbarton, bgamari, austin

Reviewed By: austin

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

We already used a process-1.4 snapshot with non-bumped version,
so this commit is mostly a `.cabal` file upper-bound relaxation change.

At the moment BooleanFormula is defined as

  data BooleanFormula a = Var a | And [BooleanFormula a]
                        | Or [BooleanFormula a]
       deriving (Eq, Data, Typeable, Functor, Foldable, Traversable)

An API Annotation can only be attached to an item of the form Located a.

Replace this with a properly Located version, and attach the appropriate
API Annotations to it

Updates haddock submodule.

Test Plan: ./validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, mpickering

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

GHC Trac Issues: #11017

This is needed to prepare for #11026 as this update
relaxes the upper bounds on `base` to allow for `base-4.9.0.0`

This also needs to relax a few upper bounds on process in some cabal files

(there will be another process submodule update soon, as a major
version bump of process' version is still pending)

This is needed to prepare for #11026 as these updates
relax the upper bounds on `base` to allow for `base-4.9.0.0`

A utility to check API Annotations was provided in
https://git.haskell.org/ghc.git/commitdiff/43751b2436f370d956d8021b3cdd3
eb77801470b

This commit had poor documentation.

This patch improves the output generated by the utility as well as
supplying better documentation

Test Plan: ./validate

Reviewers: simonpj, austin, bgamari

Reviewed By: austin, bgamari

Subscribers: thomie, mpickering

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

GHC Trac Issues: #10917

Summary:
Fix building new Sphinx documenation on Windows in msys2 using Awson's patch on #11021.

Install Sphinx using `pacman -S mingw-w64-$(uname -m)-python2-sphinx`

Test Plan: Apply patch and ./validate

Reviewers: thomie, bgamari, austin

Reviewed By: thomie, bgamari

Subscribers: erikd

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

GHC Trac Issues: #11021

Starting with directory-1.2.5 there will be a nameclash with
`withCurrentDirectory` and `MIN_VERSION_filepath()` isn't available at
bootstrap-time with the current GHC build-system.

By using explicit import lists we avoid CPP altogether

This is the second attempt at merging D757.

This patch implements the idea floated in Trac #9858, namely that we
should generate type-representation information at the data type
declaration site, rather than when solving a Typeable constraint.

However, this turned out quite a bit harder than I expected. I still
think it's the right thing to do, and it's done now, but it was quite
a struggle.

See particularly

 * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
 * Note [The overall promotion story] in DataCon (clarifies existing
stuff)

The most painful bit was that to generate Typeable instances (ie
TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
etc:

 * We need to have enough data types around to *define* a TyCon
 * Many of these types are wired-in

Also, to minimise the code generated for each data type, I wanted to
generate pure data, not CAFs with unpackCString# stuff floating about.

Performance
~~~~~~~~~~~
Three perf/compiler tests start to allocate quite a bit more. This isn't
surprising, because they all allocate zillions of data types, with
practically no other code, esp. T1969

 * T1969:    GHC allocates 19% more
 * T4801:    GHC allocates 13% more
 * T5321FD:  GHC allocates 13% more
 * T9675:    GHC allocates 11% more
 * T783:     GHC allocates 11% more
 * T5642:    GHC allocates 10% more

I'm treating this as acceptable. The payoff comes in Typeable-heavy
code.

Remaining to do
~~~~~~~~~~~~~~~

 * I think that "TyCon" and "Module" are over-generic names to use for
   the runtime type representations used in GHC.Typeable. Better might
be
   "TrTyCon" and "TrModule". But I have not yet done this

 * Add more info the the "TyCon" e.g. source location where it was
   defined

 * Use the new "Module" type to help with Trac Trac #10068

 * It would be possible to generate TyConRepName (ie Typeable
   instances) selectively rather than all the time. We'd need to persist
   the information in interface files. Lacking a motivating reason I
have
   not done this, but it would not be difficult.

Refactoring
~~~~~~~~~~~
As is so often the case, I ended up refactoring more than I intended.
In particular

 * In TyCon, a type *family* (whether type or data) is repesented by a
   FamilyTyCon
     * a algebraic data type (including data/newtype instances) is
       represented by AlgTyCon This wasn't true before; a data family
       was represented as an AlgTyCon. There are some corresponding
       changes in IfaceSyn.

     * Also get rid of the (unhelpfully named) tyConParent.

 * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
   optionally promoted; and use it elsewhere in GHC.

 * Cleanup handling of knownKeyNames

 * Each TyCon, including promoted TyCons, contains its TyConRepName, if
   it has one. This is, in effect, the name of its Typeable instance.

Updates haddock submodule

Test Plan: Let Harbormaster validate

Reviewers: austin, hvr, goldfire

Subscribers: goldfire, thomie

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

GHC Trac Issues: #9858

This is needed for #10374 (but doesn't fix it yet).

Also rename DeriveConstants.hs to Main.hs, because the build
system has trouble with Main modules not called Main.hs.

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

The build system has trouble with Main modules not called Main.hs. This
change allows a hack in utils/runghc/ghc.mk to be removed.

This reverts commit bef2f03e.

This merge was botched

Also reverts haddock submodule.

This patch implements the idea floated in Trac #9858, namely that we
should generate type-representation information at the data type
declaration site, rather than when solving a Typeable constraint.

However, this turned out quite a bit harder than I expected. I still
think it's the right thing to do, and it's done now, but it was quite
a struggle.

See particularly

 * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
 * Note [The overall promotion story] in DataCon (clarifies existing stuff)

The most painful bit was that to generate Typeable instances (ie
TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
etc:

 * We need to have enough data types around to *define* a TyCon
 * Many of these types are wired-in

Also, to minimise the code generated for each data type, I wanted to
generate pure data, not CAFs with unpackCString# stuff floating about.

Performance
~~~~~~~~~~~
Three perf/compiler tests start to allocate quite a bit more. This isn't
surprising, because they all allocate zillions of data types, with
practically no other code, esp. T1969

 * T3294:   GHC allocates 110% more (filed #11030 to track this)
 * T1969:   GHC allocates 30% more
 * T4801:   GHC allocates 14% more
 * T5321FD: GHC allocates 13% more
 * T783:    GHC allocates 12% more
 * T9675:   GHC allocates 12% more
 * T5642:   GHC allocates 10% more
 * T9961:   GHC allocates 6% more

 * T9203:   Program allocates 54% less

I'm treating this as acceptable. The payoff comes in Typeable-heavy
code.

Remaining to do
~~~~~~~~~~~~~~~

 * I think that "TyCon" and "Module" are over-generic names to use for
   the runtime type representations used in GHC.Typeable. Better might be
   "TrTyCon" and "TrModule". But I have not yet done this

 * Add more info the the "TyCon" e.g. source location where it was
   defined

 * Use the new "Module" type to help with Trac Trac #10068

 * It would be possible to generate TyConRepName (ie Typeable
   instances) selectively rather than all the time. We'd need to persist
   the information in interface files. Lacking a motivating reason I have
   not done this, but it would not be difficult.

Refactoring
~~~~~~~~~~~
As is so often the case, I ended up refactoring more than I intended.
In particular

 * In TyCon, a type *family* (whether type or data) is repesented by a
   FamilyTyCon
     * a algebraic data type (including data/newtype instances) is
       represented by AlgTyCon This wasn't true before; a data family
       was represented as an AlgTyCon. There are some corresponding
       changes in IfaceSyn.

     * Also get rid of the (unhelpfully named) tyConParent.

 * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
   optionally promoted; and use it elsewhere in GHC.

 * Cleanup handling of knownKeyNames

 * Each TyCon, including promoted TyCons, contains its TyConRepName, if
   it has one. This is, in effect, the name of its Typeable instance.

Requires update of the haddock submodule.

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

This patch swaps the order of provided and required constraints in
a pattern signature, so it now goes

      pattern P :: req => prov => t1 -> ... tn -> res_ty

See the long discussion in Trac #10928.

I think I have found all the places, but I could have missed something
particularly in comments.

There is a Haddock changes; so a submodule update.

Add -fworker-wrapper flag which enables the worker-wrapper transformation. It
is implied by -O.

The expected users of this flag, which includes myself, are GHC API users.  In
my Haskell-to-Hardware compiler, which uses the GHC API, I have seen no
benifits of the worker-wrapper transformation. It does however induce longer
compilation times.

Further discussion can be seen here:
https://mail.haskell.org/pipermail/ghc-devs/2015-October/010096.html

Reviewed By: austin

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

GHC Trac Issues: #11020

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #10848

It is difficult for GHC developers to know if they have broken the API
Annotations.

This patch provides a utility that can be used as a test to show up
errors in the API Annotations.

It is based on the current tests for ghc-api/annotations which can parse
a file using the just-built GHC API, and check that no annotations are
disconnected from the ParsedSource in the output.

In addition, it should be able to dump the annotations to a file, so a
new feature developer can check that all changes to the parser do
provide annotations.

Trac ticket: #10917

Test Plan: ./validate

Reviewers: hvr, thomie, austin, bgamari

Reviewed By: bgamari

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

GHC Trac Issues: #10917

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

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>