GitLab

`enqueueCommands` should always force exception in commands. Otherwise
the exception thrown in `:cmd` (e.g. `:cmd return $ head []`) will cause
GHCi to terminate with panic.

Test Plan: `cd testsuite/tests/ghci/ && make`

Reviewed By: austin

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

GHC Trac Issues: #10501

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

Summary:
Refactor wild card error reporting

* Merge `HsWildcardTy` and `HsNamedWildcardTy` into one constructor
  `HsWildCardTy` with as field the new type `HsWildCardInfo`, which has two
  constructors: `AnonWildCard` and `NamedWildCard`.

* All partial type checks are removed from `RdrHsSyn.hs` and are now done
  during renaming in order to report better error messages. When wild cards
  are allowed in a type, the new function `rnLHsTypeWithWildCards` (or
  `rnHsSigTypeWithWildCards`) should be used. This will bring the named wild
  cards into scope before renaming them. When this is not done, renaming will
  trigger "Unexpected wild card..." errors.

  Unfortunately, this has to be done separately for anonymous wild cards
  because they are given a fresh name during renaming, so they will not cause
  an out-of-scope error. They are handled in `tc_hs_type`, as a special case
  of a lookup that fails.

  The previous opt-out approach is replaced with an opt-in approach. No more
  panics because of forgotten checks!

* `[t| _ |]` isn't caught by the above two checks, so it is currently handled
  by a special case. The error message (generated in the `DsM` monad) doesn't
  provide as much context information as the other cases.

* Instead of three (!) functions that walk `HsType`, there is now only one
  pure function called `collectWildCards`.

* Alternative approach: catch all unwanted wild cards in `rnHsTyKi` by looking
  at the `HsDocContext`. This will reduce the number of places to catch
  unwanted wild cards form three to one, and make the error messages more
  uniform, albeit less informative, as the error context for renaming is not
  as informative as the one for type checking. A new constructor of
  `HsDocContext` will be required for pattern synonyms signatures.

  Small problem: currently type-class type signatures can't be distinguished
  from type signatures using the `HsDocContext`.

This requires an update to the Haddock submodule.

Test Plan: validate

Reviewers: goldfire, simonpj, austin

Reviewed By: simonpj

Subscribers: bgamari, thomie, goldfire

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

GHC Trac Issues: #10098

This causes the buildbots and other users to choke when building the
user documentation, but I haven't figured out why.

This reverts commit dcaaa980.

In a situaion where we have some statically-linked code and we want to
load and unload a series of objects, we need the CAFs in the
statically-linked code to be retained indefinitely, while the CAFs in
the dynamically-linked code should be GC'd as normal, so that we can
detect when the code is unloadable.  This was wrong before - we GC'd
CAFs in the static code, leading to a crash in the rare case where we
use a CAF, GC it, and then load a new object that uses it again.

I also did some tidy up: RtsConfig now has a field keep_cafs to
indicate whether we want CAFs to be retained in static code.

The default (perf) build, which sets SplitObjs=YES, was broken with
commit 5dd02864.

I accidently removed the wrong `endif`. This should fix it.

Since commit 824e34e30338b4b1de0ab5467ffd29da4c7c805a, building ghc from
a source distribution doesn't work.

The error is:

    make[3]: *** No rule to make target
    'utils/genprimopcode/dist/build/Lexer.hs', needed by
    'utils/genprimopcode/dist/build/Lexer.o'.  Stop.

This commit fixes that. See note [Implicit rule search algorithm].

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

Don't let the output of tests that either have missing libraries or are
expected to be broken obscure real failures.

This makes it easier to analyse the testlogs.

The only consequence is that when a test fails because a certain library
isn't installed, you have to check the all.T file in which the test is
defined to actually find out _which_ library that is. Before it would
print something like

    Compile failed (status 256) errors were:

    stm052.hs:10:8: error:
     Could not find module ‘System.Random’
     Use -v to see a list of the files searched for.

And now it doesn't. I think this is an acceptable tradeoff.

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

Summary:
Apparently this was broken by b30c6012

,
but I can't reproduce the issue described there at all.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Test Plan: Use my eyes to read the resulting user manual.

Reviewers: hvr, thomie

Reviewed By: thomie

Subscribers: bgamari, thomie

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

GHC Trac Issues: #10416

Dang, roles are annoying.

Test case: typecheck/should_compile/T10489

Summary:
Previously, I had forgotten to unwrap vanilla type synonyms in the
"flattener" that is used around the closed-type-family apartness
check.

Test Plan: validate

Reviewers: austin

Subscribers: bgamari, thomie

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

GHC Trac Issues: #10488

Check for each submodule repository url if the user made its own fork.
If so, use that. Otherwise, fall back on the one from github.com/ghc.

As suggested by Richard in this mailinglist discussion:
https://mail.haskell.org/pipermail/ghc-devs/2014-November/007300.html

Documentation is at [wiki:TestingPatches#Travis].

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

This info is not needed in the testlogs, and was actually making these
tests fail on my machine because of some bug with the timeout program:
...
[1 of 1] Compiling Main ( OutOfHeap.hs, tmp_T9579_outofheap_rtssome/Main.o )
Linking T9579_outofheap_rtsnone ...
...

That warning is only shown on some platforms, and is I believe harmless.

* extra_clean argument should be a list
  Add an assert to prevent regressions.

* properly clean package conf direcories
  They are directories now, which was causing problems.

* properly clean write_interface_* tests
  We were getting these errors:

  [Errno 21] Is a directory: './driver/write_interface_oneshot'
  [Errno 39] Directory not empty: './driver/write_interface_oneshot'
  [Errno 21] Is a directory: './driver/write_interface_make'
  [Errno 39] Directory not empty: './driver/write_interface_make'

* outputdir() is better than -outputdir, as it knows how to (pre)clean
  itself.

  * By default use V=0, and call the testsuite with VERBOSE=2, which we
    did before only with validate --quiet. This disables printing the
    test commands it runs.

  * When --quiet is used, call the testsuite with VERBOSE=1. This
    disables printing the '====> Scanning' lines, and doesn't print
    which test is being run. So it only prints something when a test
    accidentally prints to stdout or when it fails.

    Don't set this option on Travis, as Travis will cancel a build if it
    doesn't see any output for more than 10 minutes.

  * When --quiet is used, set the new test option NO_PRINT_SUMMARY,
    which skips printing the test summary. Only the list of unexpected
    failures is printed, if there are any. Note that the full summary
    can still be found in testsuite_summary.txt

  * When --quiet is used, don't pass the `-v` flag to `ghc-pkg check`

  * When --quiet is used, don't print the Oops! header. It shoud be
    clear from the list of failing tests that something is wrong.

This is all done to get the most out of 30 lines of logfile. These changes can
be disabled later by simply not passing the --quiet flag to validate.

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

All these checks that CLEANING/=YES are no longer needed, because
nowadays $1_$2_PROGNAME is always set explicitly, and $1_$2_PROG isn't.

They were once introduce to allow `make clean` before `./configure`. I
checked, and it still works.

Remove the checks to make the build system a tiny bit shorter, and to
no longer wonder why they are there.

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

The comment "INPLACE_BIN might be empty if we're distcleaning" is no
longer true, and the check that CLEANING isn't YES isn't necessary.

It was introduced in cd12c32d, to
"make repeated 'make distclean' not fail", and and later revised in
39253008. It was needed because
INPLACE_BIN was defined in config.mk.

Commit 6793a033 however, two days
later, introduced a better solution to this problem: "Move the fixed
paths out of config.mk, so cleaning works without configuring"

So here we remove the original comment and check. One less thing to
worry about when trying to understand the build system.

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

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

Only print and exit on errors. Warnings of the type
'PackageDistSuspicious' are not very useful.

The following show up in the build logs currently:
  * The 'license' field is missing.
  * No 'maintainer' field
  * No 'category' field
  * 'ghc-options: -O2' is rarely needed. Check that it is giving a real
    benefit and not just imposing longer compile times on your users.

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

Only when V=0.

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

Summary:
Phabricator/Harbormaster measured the following allocation numbers for
haddock.compiler:

Expected:     33562468736
June 2nd [1]: 36740649320
Upper bound:  36918715610
June 3rd [2]: 36956620504

So although this test didn't start failing until June 2nd/3rd, the
biggest increase in allocation must have occured sometime before that.

[1] 2f0011ac
[2] 942cfa4e

Test Plan: validate

Reviewers: austin

Subscribers: bgamari, thomie

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

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

Test Plan: validate

Reviewers: austin

Subscribers: bgamari, thomie

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

GHC Trac Issues: #9507

This is the Travis default. It should only spam people who have an
GitHub account and are a member of the ghc organization on GitHub, as
noted by thomie on https://phabricator.haskell.org/D939#25497. Let's see
how that works out.

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

Summary:
This should make it a lot easier to define Lift instances.
See https://mail.haskell.org/pipermail/libraries/2015-May/025728.html


for motivating discussion.

I needed to muck out some code from Quote into Syntax to get
the definition in the right place; but I would argue that code
never really belonged in Quote to begin with.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: austin, ekmett, goldfire

Subscribers: bgamari, thomie

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

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

Test Plan: validate

Reviewers: simonpj, goldfire, austin

Subscribers: bgamari, thomie

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

GHC Trac Issues: #10460

Trac #7672 has a data type T in module A that is in scope
*both* locally-bound *and* imported (with a qualified) name.
The Provenance of a GlobalRdrElt simply couldn't express that
before. Now you can.

In doing so, I flattened out Provenance into GlobalRdrElt,
so quite a lot of modules are touched in a not-very-interesting
way.

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

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

Test Plan: none

Reviewers: rwbarton, austin

Subscribers: bgamari, thomie

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

GHC Trac Issues: #10474

The filename of temporary files, especially the basename of C files, can
end up in the output in some form, e.g. as part of linker debug
information. In the interest of bit-wise exactly reproducible
compilation (#4012), the basename of the temporary file no longer
contains random information (it used to ontain the process id).

This is ok, as the temporary directory used contains the pid (see
getTempDir).

This patch has been applied to the Debian package (version 7.10.1-5) and
allowed a fully bit-wise reproducible build:
https://reproducible.debian.net/rb-pkg/experimental/amd64/ghc.html

Reviewed By: austin, rwbarton

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

GHC Trac Issues: #4012

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

I refactored TcType FFI functions to return Validity rather than Bool,
which turned out to be an easy way to solve Trac #10461.

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

When using GHCi, we explicitly reject optimization, because the
compilers optimization passes can introduce unboxed tuples, which the
interpreter is not able to handle. But this goes the other way too: using
GHCi on optimized code may cause the optimizer to float out breakpoints
that the interpreter introduces. This manifests itself in weird ways,
particularly if you as an API client use custom DynFlags to introduce
optimization in combination with HscInterpreted.

It turns out we weren't checking for consistent DynFlag settings when
doing `setSessionDynFlags`, as #10052 showed. While the main driver
handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this
elsewhere.

This does a little refactoring to split out some of the common code, and
immunizes the various `DynFlags` utilities in the `GHC` module from this
particular bug. We should probably be checking other general invariants
too.

This fixes #10052, and adds some notes about the behavior in `GHC` and
`FloatOut`

As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it
didn't exist (somehow).
Signed-off-by: Austin Seipp <austin@well-typed.com>

Reviewed By: edsko

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

GHC Trac Issues: #10052