GitLab

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

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

A `make` build after running `./validate` earlier should use the normal
mk/build.mk settings, without having to manually delete the leftover
file mk/are-validating or run `make clean` first.

Reviewed by: austin

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

Reviewers: austin, bgamari

Subscribers: erikd

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

	modified:   configure.ac

`configure` currently detects when the docbook and hscolour tools aren't
available, and instead of failing outright (as it does for missing alex
and happy), sets some variables in mk/config.mk to tell `make` not to
build the documentation.

Sometimes, however, you want to really make sure all documentation gets
built, fully colourized. For example when making a release. To do so,
you can override the mentioned variables from mk/config.mk in
mk/build.mk (e.g. set HSCOLOUR_SRCS=YES).

This patch adds some error checking to make sure that doing so will not
result in weird build failures when those tools are still missing.

Test Plan: ran `make` a couple of times, with different mk/config.mk settings.

Reviewed by: austin

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

Summary:
See Note [CrossCompiling vs Stage1Only] in mk/config.mk.in.
See Note [Stage1Only vs stage=1] in mk/config.mk.in.
See Note [No stage2 packages when CrossCompiling or Stage1Only].

Also:
  * use stage2 to build mkUserGuidePart, as was probably intended.
    Now the following represent the same set of packages:
    - packages that we build with ghc-stage2
    - packages that depend on the ghc library
    Those packages are: haddock, mkUserGuidePart and ghctags.
  * don't let utils that don't depend on the ghc library depend on its
    package-data.mk file. Instead, let those utils directly depend on
    the package-data.mk files of the stage1 packages. Not sure if it
    improves anything, but I found it easier to explain what's going on
    this way.

(partially) reviewed by: austin

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

Just install all packages that are built. Don't make an exception for
the dph and extra packages.

You can control whether the dph and extra packages should be build using
the variables BUILD_DPH and BUILD_EXTRA_PKGS. These variables didn't
exist before. But now that they do, InstallExtraPackages isn't really
needed anymore.

Reviewed by: austin

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

Reviewed by: bgamari

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

This will allow fixing #1851 more easily
("make install-strip" should work).

This reverts 57e2a81c:
  "On Cygwin, use a Cygwin-style path for /bin/install's destination"

Update submodule haddock and hsc2hs.

stm and parallel have an 'extra' tag in the ./packages file, so would get
added to PACKAGES_STAGE2 by default, and subsequently build by the stage2
compiler.

With this patch, this happens only when you set BUILD_EXTRA_PKGS=YES in
build.mk. A normal validate still builds (and tests) the 'extra'
packages, but they are skipped for `validate --fast`. Maybe this brings
us closer to finishing within the 50 minute Travis limit as well.

We can later try to give random, primitive and vector an 'extra' tag as
well (now they have a 'dph' tag), but some tests will probably fail at
first.

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

Ever since we ship xhtml, terminfo and haskeline (#8919), commit
4caadb7c, REGULAR_INSTALL_DYNLIBS is
always empty.

REGULAR_INSTALL_PACKAGES =
  PACKAGES_STAGE1 + compiler + PACKAGES_STAGE2

REGULAR_INSTALL_DYNLIBS =
  PACKAGES_STAGE1 + PACKAGES_STAGE2 - REGULAR_INSTALL_PACKAGES

So we can delete it, and all the places where it is used. This
simplifies ghc.mk a bit.

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

...to prevent accidental use of `make bindist`, when `make binary-dist`
is called for.

Summary:
When we introduced user-friendly library names
(e.g. unix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d instead of
unix_G4Yo1pNtYrk8nCq1cx8P9d) we added a new variable to
be written out by ghc-cabal, $1_$2_LIB_NAME.

What I didn't realize at the time was that this conflicts
with an existing variable in the build system, $1_$2_$3_LIB_NAME,
which (confusingly) refers to something like
'libHSunix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d.so'.  This is pretty
confusing (despite never conflicting), so I renamed this variable
to LIB_FILE for enhanced greppability.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin

Subscribers: thomie, bgamari

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

Summary:
Previously, we'd install them to something like
xhtml_0ACfOp3hebWD9jGWE4v4G which was fairly ugly; this
commit changes the default install path to contain the full
package name and version, as well as the package key.

Needs a Cabal submodule update for the commit for install paths support
"Add libname install-dirs variable, use it by default. Fixes #2437".
It also contains some miscellaneous fixes for Cabal HEAD.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin

Subscribers: bgamari, thomie

Trac Issues: #10479

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

When making the `sdist` tarball, we don't really need anything inside
$(TOP)/testsuite in order to do our thing. So make sure we clean it
first to avoid situations like #10406.

With D917 landed, this can actually avoided entirely by fixing the
official release process to instead build an `sdist` //first// from the
clean git repository and then build that (to fixpoint) and test it. Then
the originall clean tarball can be shipped.

But it's nice to be safe in the general case where someone might want to
(in the future) `sdist` out of their build tree.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Reviewed By: thomie

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

GHC Trac Issues: #10406

Make it possible to run `make sdist` right after configure, without completing
a complete build first.

Test Plan:
I compared the contents of the created `.tar.bz2` files in the `sdistprep`
directory, after running `make sdist` both before and after completing a full
build, using `diff -r`. There weren't any differences (after applying the
patches from D914).

Note that the `.tar.bz2` files were not exactly the same size, but they aren't
either when tarring and bzipping the same directory twice. It seems tarring
and bzipping is not deterministic (on my system).

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

Summary:
Haddock outputs well over a thousand lines of file output just to give
its executive summary about coverage. Kill this by default, since we
really don't need it in any setting.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Test Plan: Crossed my fingers.

Reviewers: nomeata, thomie

Reviewed By: thomie

Subscribers: bgamari, thomie

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

To test:
  * run `make clean` in utils/runghc
  * make sure inplace/bin doesn't contain runghc
  * set GhcWithInterpreter=NO in build.mk
  * run `make`
  * note that inplace/bin doesn't contain runghc

It won't be installed either, nor will runhaskell.

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

Do what this comment was suggesting:

    "Ideally we'd like to have 'make -r' turned on by default, because
    that disables all the implicit rules, but there doesn't seem to be a
    good way to do that."

This change doesn't seem to have much effect on the time it takes to run
make. Apparently clearing .SUFFIXES was enough for that. But it does
make the output of `make -d` quite a bit shorter, which is nice.

Note: ghc.mk is always called indirectly, so no need to set .SUFFIXES or
MAKEFLAGS there again.

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

[skip ci]

[skip ci]

We only ever check if CLEANING=YES.

[skip ci]

To check if we're cleaning, always check the $CLEANING variable, instead
of sometimes $CLEANING, sometimes $MAKECMDGOALS.

[skip ci]

Summary:
This commit adds stage 1 support for Template Haskell
quoting, e.g. [| ... expr ... |], which is useful
for authors of quasiquoter libraries that do not actually
need splices.  The TemplateHaskell extension now does not
unconditionally fail; it only fails if the renamer encounters
a splice that it can't run.

In order to make sure the referenced data structures
are consistent, template-haskell is now a boot library.
There are some minor BC changes to template-haskell to make it boot
on GHC 7.8.

Note for reviewer: big diff changes are simply code
being moved out of an ifdef; there was no other substantive
change to that code.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, goldfire

Subscribers: bgamari, thomie

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

GHC Trac Issues: #10382

Revert "Quick fix: drop base bound on template-haskell."

This reverts commit 3c70ae03.

Revert "Always do polymorphic typed quote check, c.f. #10384"

This reverts commit 9a43b2c1.

Revert "RnSplice's staging test should be applied for quotes in stage1."

This reverts commit eb0ed403.

Revert "Split off quotes/ from th/ for tests that can be done on stage1 compiler."

This reverts commit 21c72e7d.

Revert "Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382."

This reverts commit 28257cae.

Summary:
This commit adds stage 1 support for Template Haskell
quoting, e.g. [| ... expr ... |], which is useful
for authors of quasiquoter libraries that do not actually
need splices.  The TemplateHaskell extension now does not
unconditionally fail; it only fails if the renamer encounters
a splice that it can't run.

In order to make sure the referenced data structures
are consistent, template-haskell is now a boot library.

In the following patches, there are:

    - A few extra safety checks which should be enabled
      in stage1
    - Separation of the th/ testsuite into quotes/ which
      can be run on stage1

Note for reviewer: big diff changes are simply code
being moved out of an ifdef; there was no other substantive
change to that code.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, goldfire

Subscribers: bgamari, thomie

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

GHC Trac Issues: #10382

[skip ci]

The default validate settings currently disable some warnings in the
libraries. This patch moves those settings to a new file called
`mk/warnings.mk`, and applies them also to normal builds.

Through uncommenting a line in build.mk, developers can now build with
-Werror.

-Werror is not the default, because:
* We can not guarantee that the build is warning free on platforms we
  don't run regularly run validate (as part of continuous integration
  systems), and we still want the build to go through on those
  platforms.
* quoting rwbarton on irc > "I think -Werror by default has come up in
  the past and the argument was that it is too annoying when you are
  doing nontrivial development"

Reviewed By: austin

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

This completes what c774b28f (#9281)
started.  `integer-gmp-1.0` was added as an additional
`libraries/integer-gmp2` folder while retaining the ability to configure
GHC w/ the old `integer-gmp-0.5` to have a way back, and or the ability
to easily switch between old/new `integer-gmp` for benchmark/debugging
purposes.

This commit removes the old `libraries/integer-gmp` folder and moves
`libraries/integer-gmp2` into its place, while removing any mentions of
"gmp2" as well as the to support two different `integer-gmp` packages in
GHC's source-tree.

Reviewed By: austin

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

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

There's no reason to have two files, and this is one step towards a
cleaner root directory.
Signed-off-by: Austin Seipp <austin@well-typed.com>

This gives a very quick rundown on installation for end-users (HACKING
etc is for developers/possible contributors).
Signed-off-by: Austin Seipp <austin@well-typed.com>

Summary:
This allows GHC HEAD to be bootstrapped using 7.10.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin

Subscribers: carter, thomie

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

GHC Trac Issues: #9652

Summary: Signed-off-by: Joe Hillenbrand <joehillen@gmail.com>

Reviewers: thomie, austin

Reviewed By: thomie, austin

Subscribers: carter, thomie

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

GHC Trac Issues: #9876

This makes `VERSION` updating a bit more robust (the file gets only
updated if its content would actually change), as well as moving the
dependency of `VERSION` and `GIT_COMMIT_ID` to the `sdist-ghc-prep`
target, as that's where it's actually needed.

This fixes the specialised target `make sdist-ghc` not properly
creating/updating the `VERSION` and `GIT_COMMIT_ID` files before
creating the ghc source-dist tarball, as well as avoiding stale
`VERSION` files.

Since we switched to a Git submodule based GHC Git repo, `ghc.git`'s
commit id uniquely identifies the state of the GHC source-tree. So
having that information embedded into the `ghc` executable provides
valuable information to track accurately (especially when created by
buildbots) from which source-tree-state a given `ghc` snapshot
(distribution) was generated.

So this commit adds a new field `"Project Git commit id"` to the
`ghc --info` meta-data containing the `./configure`-time Git commit id
as reported by `git rev-parse HEAD`.

This field can also be queried with `ghc --print-project-git-commit-id`.

For source distributions, the file `GIT_COMMIT_ID` is created (with some
sanity checking to detect stale commit ids, as that would render this
information rather useless)

Reviewed By: austin

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