delta/haskell.git, branch wip/windows-tests gitlab.haskell.org: ghc/ghc.git testsuite: Mark ghci058 as broken on Windows 2019-06-24T22:32:12+00:00 Ben Gamari ben@smart-cactus.org 2019-06-24T22:31:50+00:00 86a4893a4db45a102b607f023715939bf50cd3a7 Due to #16858. 
Due to #16858.
testsuite: Fix expected output for caf_crash 2019-06-24T22:32:12+00:00 Ben Gamari ben@smart-cactus.org 2019-06-24T17:29:50+00:00 8f5e9e571213109597f958b6589f05bcddbe309b 






testsuite: Don't run T16525a with -DS unless compiler_debugged
2019-06-24T22:32:11+00:00

Ben Gamari
ben@smart-cactus.org

2019-06-23T15:23:15+00:00

1b1735120713c909d7b4e11711922cdd7af3ed6a

Originally I was thinking of just skipping the test unless
compiled_debugged==True. However, the test will likely be useful even
without -DS, so let's run it either way.





Originally I was thinking of just skipping the test unless
compiled_debugged==True. However, the test will likely be useful even
without -DS, so let's run it either way.







Add MonadFail instance for ParserM
2019-06-24T05:12:22+00:00

Erik de Castro Lopo
erikd@mega-nerd.com

2019-06-22T03:50:14+00:00

581cbc28e143a4ed8e7f794ed1618161222a5646












Fixes for LLVM 7
2019-06-24T05:11:46+00:00

Erik de Castro Lopo
erikd@mega-nerd.com

2019-06-22T00:13:51+00:00

71aca77c780dad8496054a06a7fe65704a13a742

LLVM version numberinf changed recently. Previously, releases were numbered
4.0, 5.0 and 6.0 but with version 7, they dropped the redundant ".0".

Fix requires for Llvm detection and some code.





LLVM version numberinf changed recently. Previously, releases were numbered
4.0, 5.0 and 6.0 but with version 7, they dropped the redundant ".0".

Fix requires for Llvm detection and some code.







Refactor UnliftedNewtypes-relation kind signature validity checks
2019-06-23T21:20:41+00:00

Ryan Scott
ryan.gl.scott@gmail.com

2019-06-16T00:21:34+00:00

9bbcc3be51180dcefde0c89daf8ad6f69c680b40

This fixes three infelicities related to the programs that are
(and aren't) accepted with `UnliftedNewtypes`:

* Enabling `UnliftedNewtypes` would permit newtypes to have return
  kind `Id Type`, which had disastrous results (i.e., GHC panics).
* Data family declarations ending in kind `TYPE r` (for some `r`)
  weren't being accepted if `UnliftedNewtypes` wasn't enabled,
  despite the GHC proposal specifying otherwise.
* GHC wasn't warning about programs that _would_ typecheck if
  `UnliftedNewtypes` were enabled in certain common cases.

As part of fixing these issues, I factored out the logic for checking
all of the various properties about data type/data family return
kinds into a single `checkDataKindSig` function. I also cleaned up
some of the formatting in the existing error message that gets
thrown.

Fixes #16821, fixes #16827, and fixes #16829.





This fixes three infelicities related to the programs that are
(and aren't) accepted with `UnliftedNewtypes`:

* Enabling `UnliftedNewtypes` would permit newtypes to have return
  kind `Id Type`, which had disastrous results (i.e., GHC panics).
* Data family declarations ending in kind `TYPE r` (for some `r`)
  weren't being accepted if `UnliftedNewtypes` wasn't enabled,
  despite the GHC proposal specifying otherwise.
* GHC wasn't warning about programs that _would_ typecheck if
  `UnliftedNewtypes` were enabled in certain common cases.

As part of fixing these issues, I factored out the logic for checking
all of the various properties about data type/data family return
kinds into a single `checkDataKindSig` function. I also cleaned up
some of the formatting in the existing error message that gets
thrown.

Fixes #16821, fixes #16827, and fixes #16829.







ghci: Load static objects in batches
2019-06-23T21:19:48+00:00

Ben Gamari
ben@smart-cactus.org

2019-06-14T20:53:12+00:00

5a502cd1431b535a12dced0479b75c5f7dbfb01c

Previously in the case where GHC was dynamically linked we would load
static objects one-by-one by linking each into its own shared object and
dlopen'ing each in order. However, this meant that the link would fail
in the event that the objects had cyclic symbol dependencies.

Here we fix this by merging each "run" of static objects into a single
shared object and loading this.

Fixes #13786 for the case where GHC is dynamically linked.





Previously in the case where GHC was dynamically linked we would load
static objects one-by-one by linking each into its own shared object and
dlopen'ing each in order. However, this meant that the link would fail
in the event that the objects had cyclic symbol dependencies.

Here we fix this by merging each "run" of static objects into a single
shared object and loading this.

Fixes #13786 for the case where GHC is dynamically linked.







testsuite: Test for #13786
2019-06-23T21:19:48+00:00

Ben Gamari
ben@smart-cactus.org

2019-06-14T21:38:04+00:00

ade3db5392d0f98cbd2e917fca926f4e08ca4fa7












testsuite: Add caf_crash testcase
2019-06-22T14:06:05+00:00

Ben Gamari
ben@smart-cactus.org

2019-06-18T16:17:48+00:00

1f2fff89afebb065b27eba0f6e1f89e25c1c158d












rts: Reset STATIC_LINK field of reverted CAFs
2019-06-22T14:06:05+00:00

Ben Gamari
ben@smart-cactus.org

2019-06-18T16:07:50+00:00

b0d6bf2a34d5e2e0cfb2410f58e768935d527be0

When we revert a CAF we must reset the STATIC_LINK field lest the GC
might ignore the CAF (e.g. as it carries the STATIC_FLAG_LIST flag) and
will consequently overlook references to object code that we are trying
to unload. This would result in the reachable object code being
unloaded. See Note [CAF lists] and Note [STATIC_LINK fields].

This fixes #16842.

Idea-due-to: Phuong Trinh <lolotp@fb.com>





When we revert a CAF we must reset the STATIC_LINK field lest the GC
might ignore the CAF (e.g. as it carries the STATIC_FLAG_LIST flag) and
will consequently overlook references to object code that we are trying
to unload. This would result in the reachable object code being
unloaded. See Note [CAF lists] and Note [STATIC_LINK fields].

This fixes #16842.

Idea-due-to: Phuong Trinh <lolotp@fb.com>