Ben Gamari authored 1 year ago and Marge Bot committed 1 year ago

Here we introduce the `Backtraces` type and associated machinery for
attaching these via `ExceptionContext`. These has a few compile-time
regressions (`T15703` and `T9872d`) due to the additional dependencies
in the exception machinery.

As well, there is a surprisingly large regression in the
`size_hello_artifact` test. This appears to be due to various `Integer` and
`Read` bits now being reachable at link-time. I believe it should be
possible to avoid this but I have accepted the change for now to get the
feature merged.

CLC Proposal: https://github.com/haskell/core-libraries-committee/issues/199
GHC Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/330

Metric Increase:
    T15703
    T9872d
    size_hello_artifact

jeffrey young authored 1 year ago and Marge Bot committed 1 year ago

closes: #23259

- adds -fprint-error-index-links={auto|always|never} flag

Torsten Schmits authored 1 year ago and Torsten Schmits committed 1 year ago

Tracking ticket: #20115

MR: !10350

This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.

Moritz Angermann authored 3 years ago and Marge Bot committed 3 years ago

We should have fixed clangs mess now.

While backporting MR !1806 to 8.8.2 (!1885) I learnt the following:

* Tests with `expect_fail` do not compare `*.stderr` output files. So a test using `expect_fail` will not detect future regressions on the `stderr` output.
* To compare the `*.stderr` output files, I have to use the `exit_code(n)` function.
* When a release is made, tests with `makefile_test` are converted to use `run_command`.
* For the test `T17171a` the return code is `1` when running `makefile_test`, however it's `2` when running `run_command`.

Therefore I decided:

* To improve my tests for #17171
* To change test T17171a from `expect_fail` to `exit_code(2)`
* To change both tests from  `makefile_test` to `run_command`

Ben Gamari authored 6 years ago and Marge Bot committed 5 years ago

Previously `makefile_test` and `run_command` tests could easily end up
in a situation where they wouldn't be run if the user used the
`only_ways` modifier. The reason is to build the set of a ways to run
the test in we first start with a candidate set determined by the test
type (e.g. `makefile_test`, `compile_run`, etc.) and then filter that
set with the constraints given by the test's modifiers.

`makefile_test` and `run_command` tests' candidate sets were simply
`{normal}`, and consequently most uses of `only_ways` would result in
the test being never run.

To avoid this we rather use all ways as the candidate sets for these
test types. This may result in a few more testcases than we would like
(given that some `run_command` tests are insensitive to way) but this
can be fixed by adding modifiers and we would much rather run too many
tests than too few.

This fixes #16042 and a number of other tests afflicted by the same issue.
However, there were a few cases that required special attention:

 * `T14028` is currently failing and is therefore marked as broken due
   to #17300

 * `T-signals-child` is fragile in the `threaded1` and `threaded2` ways
   (tracked in #17307)

Roland Senn authored 5 years ago and Marge Bot committed 5 years ago

If a main module doesn't contain a header, we omit the check whether the main module is exported.
With this patch GHC, GHCi and runghc use the same code.

This eliminates most uses of run_command in the testsuite in favor of the more
structured makefile_test.

This reverts commit 76c8fd67.

Michael Snoyman authored 8 years ago and Ben Gamari committed 8 years ago

As identified by Joachim, this test broke the Travis build. It appears
that this is due to the usage of the single-threaded runtime there. I've
confirmed that this fix causes the Travis build to pass:
https://travis-ci.org/snoyberg/ghc/builds/167368988.

Test Plan: Confirm tests now pass

Reviewers: austin, nomeata, bgamari

Reviewed By: nomeata, bgamari

Subscribers: thomie

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

It currently fails with,

    =====> T6132(normal) 1 of 1 [0, 0, 0]
    cd "./runghc/T6132.run" && "/Users/bgamari/ghc/inplace/test
    spaces/ghc-stage2" -c T6132.hs -dcore-lint -dcmm-lint
    -no-user-package-db -rtsopts -fno-warn-missed-specialisations
    -fshow-warning-groups -dno-debug-output
    Compile failed (exit code 1) errors were:

    T6132.hs:1:2: error: parse error on input ‘#!/’

    *** unexpected failure for T6132(normal)

Michael Snoyman authored 8 years ago and Ben Gamari committed 8 years ago

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

Summary:
Amazingly, there were zero changes to the byte code generator and very
few changes to the interpreter - mainly because we've used good
abstractions that hide the differences between profiling and
non-profiling.  So that bit was pleasantly straightforward, but there
were a pile of other wibbles to get the whole test suite through.

Note that a compiler built with -prof is now like one built with
-dynamic, in that to use TH you have to build the code the same way.
For dynamic, we automatically enable -dynamic-too when TH is required,
but we don't have anything equivalent for profiling, so you have to
explicitly use -prof when building code that uses TH with a profiled
compiler.  For this reason Cabal won't work with TH.  We don't expect
to ship a profiled compiler, so I think that's OK.

Test Plan: validate with GhcProfiled=YES in validate.mk

Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang

Reviewed By: ezyang

Subscribers: thomie

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

GHC Trac Issues: #4837, #545

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

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