| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Fixes #22098
|
|
|
|
|
|
|
|
|
|
|
| |
Part of proposal 475 (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0475-tuple-syntax.rst)
Moves all tuples to GHC.Tuple.Prim
Updates ghc-prim version (and bumps bounds in dependents)
updates haddock submodule
updates deepseq submodule
updates text submodule
|
| |
|
|
|
|
|
|
|
|
|
| |
To 0.9.0 and 4.17.0 respectively.
Bumps array, deepseq, directory, filepath, haskeline, hpc, parsec, stm,
terminfo, text, unix, haddock, and hsc2hs submodules.
(cherry picked from commit ba47b95122b7b336ce1cc00896a47b584ad24095)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here we deprecate the eventlogging RTS ways and instead enable eventlog
support in the remaining ways. This simplifies packaging and reduces GHC
compilation times (as we can eliminate two whole compilations of the RTS)
while simplifying the end-user story. The trade-off is a small increase
in binary sizes in the case that the user does not want eventlogging
support, but we think that this is a fine trade-off.
This also revealed a latent RTS bug: some files which included `Cmm.h`
also assumed that it defined various macros which were in fact defined
by `Config.h`, which `Cmm.h` did not include. Fixing this in turn
revealed that `StgMiscClosures.cmm` failed to import various spinlock
statistics counters, as evidenced by the failed unregisterised build.
Closes #18948.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows ghc and its dependencies to be built using a normal
invocation of cabal-install. Each componenent which relied on generated
files or additional configuration now has a Setup.hs file.
There are also various fixes to the cabal files to satisfy
cabal-install.
There is a new hadrian command which will build a stage2 compiler and
then a stage3 compiler by using cabal.
```
./hadrian/build build-cabal
```
There is also a new CI job which tests running this command.
For the 9.4 release we will upload all the dependent executables to
hackage and then end users will be free to build GHC and GHC executables
via cabal.
There are still some unresolved questions about how to ensure soundness
when loading plugins into a reinstalled GHC (#20742) which will be
tighted up in due course.
Fixes #19896
|
| |
|
|
|
|
| |
Like -threaded, stage0 isn't guaranteed to have an event-logging RTS.
|
| |
|
|
|
|
| |
Bumps Win32 submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces all Word<N> = W<N># Word# and Int<N> = I<N># Int# with
Word<N> = W<N># Word<N># and Int<N> = I<N># Int<N>#, thus providing us
with properly sized primitives in the codegenerator instead of pretending
they are all full machine words.
This came up when implementing darwinpcs for arm64. The darwinpcs reqires
us to pack function argugments in excess of registers on the stack. While
most procedure call standards (pcs) assume arguments are just passed in
8 byte slots; and thus the caller does not know the exact signature to make
the call, darwinpcs requires us to adhere to the prototype, and thus have
the correct sizes. If we specify CInt in the FFI call, it should correspond
to the C int, and not just be Word sized, when it's only half the size.
This does change the expected output of T16402 but the new result is no
less correct as it eliminates the narrowing (instead of the `and` as was
previously done).
Bumps the array, bytestring, text, and binary submodules.
Co-Authored-By: Ben Gamari <ben@well-typed.com>
Metric Increase:
T13701
T14697
|
|
|
|
|
|
| |
Also bumps directory, Cabal, hpc, time, and unix submodules.
Closes #18847.
|
|
|
|
|
|
| |
We now have all sorts of great facilities using the
eventlog which were previously unavailable without
building a custom GHC. Fix this by linking with
`-eventlog` by default.
|
|
|
|
| |
Necessary for recent Win32 bump.
|
| |
|
|
|
|
| |
Also bumps Cabal, directory
|
|
|
|
|
| |
"ghci" as a flag name was confusing because it really enables the
internal-interpreter. Even the ghci library had a "ghci" flag...
|
|
|
|
| |
This is only for their respective codebases.
|
|
|
|
| |
Fixes #18279. Bumps the `text` submodule.
|
|
|
|
|
|
|
|
| |
Should make `member` queries faster and avoid messing up with missing
`nubSort`.
Metric Increase:
hie002
|
|
|
|
| |
Haskeline now depends upon exceptions. See #16752.
|
|
|
|
|
|
| |
You can always just not use or even build `iserv`. I don't think the
maintenance cost of the CPP is worth...I can't even tell what the
benefit is.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed in #16331, the GHCI macro, defined through 'ghci' flags
in ghc.cabal.in, ghc-bin.cabal.in and ghci.cabal.in, is supposed to indicate
whether GHC is built with support for an internal interpreter, that runs in
the same process. It is however overloaded in a few places to mean
"there is an interpreter available", regardless of whether it's an internal
or external interpreter.
For the sake of clarity and with the hope of more easily being able to
build stage 1 GHCs with external interpreter support, this patch splits
the previous GHCI macro into 3 different ones:
- HAVE_INTERNAL_INTERPRETER: GHC is built with an internal interpreter
- HAVE_EXTERNAL_INTERPRETER: GHC is built with support for external interpreters
- HAVE_INTERPRETER: HAVE_INTERNAL_INTERPRETER || HAVE_EXTERNAL_INTERPRETER
|
|
|
|
|
|
|
| |
Using `ghc-prim <= 0.6.1` is somewhat dodgy from a PVP point of view,
as it makes it awkward to support new minor releases of `ghc-prim`.
Let's instead use `< 0.7`, which is the idiomatic way of expressing
PVP-compliant upper version bounds.
|
| |
|
|
|
|
|
|
| |
As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail
Coauthored-by: Ben Gamari <ben@well-typed.com>
|
|
|
|
|
|
| |
See #13101 + #15454 for motivation. This change reduces the number of
modules that need to be compiled to object code when loading GHC into
GHCi.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
hadrian will explicitly enable this flag, but more importantly needs it
as otherwise we just never end up passing -threaded to GHC when building
a new GHC binary. We could quite likely unconditionally pass -threaded,
as the corresponding logic for GhcThreaded in mk/config.mk.in seems to
always lead to it being set to True, but we instead leave a way out for
anyone in need of a GHC linked against a non-threaded runtime system in
the future.
Test Plan: T8242 (with a GHC built by hadrian)
Reviewers: bgamari
Reviewed By: bgamari
Subscribers: rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5146
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change was previously part of
[D4904](https://phabricator.haskell.org/D4904), but is being split off
to aid in getting this reviewed and merged.
* The compiler code is built with `NoImplicitPrelude`, but GHCi's
modules are incompatible with it. So, this adds the pragma to all GHCi
modules that didn't have it, and adds imports of Prelude.
* In order to run GHC within itself, a `call of 'initGCStatistics`
needed to be skipped. This uses CPP to skip it when
`-DGHC_LOADED_INTO_GHCI` is set.
* There is an environment variable workaround suggested by Ben Gamari
[1], where `_GHC_TOP_DIR` can be used to specify GHC's top dir if `-B`
isn't provided. This can be used to solve a problem where the GHC being
run within GHCi attempts to look in `inplace/lib/lib/` instead of
`inplace/lib/`.
[1]: https://phabricator.haskell.org/D4904#135438
Reviewers: goldfire, bgamari, erikd, alpmestan
Reviewed By: alpmestan
Subscribers: alpmestan, lelf, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4986
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove unsafeCoerce introduced by a54c94f08b
Reviewers: simonmar, bgamari
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4901
|
|
|
|
| |
Bumps containers submodule, among others.
|
|
|
|
|
|
|
|
| |
This reverts commit 50e7bff7514ebbd74976c1a9fa0db7a8275178ae.
Reverts submodule changes.
Sigh, the haskeline commit isn't quite upstream yet.
|
|
|
|
| |
Bumps containers submodule, among others.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
(re-applying this patch now that D4659 is committed)
Space leaks in GHCi emerge from time to time and tend to come back again
after they get fixed. This is an attempt to limit regressions by
* adding a reliable detection for some classes of space leaks in GHCi
* turning on leak checking for all GHCi tests in the test suite, so that
we'll notice if the leak appears again.
The idea for detecting space leaks is quite simple:
* find some data that we expect to be GC'd later, make a weak pointer to it
* when we expect the data to be dead, do a `performGC` and then check
the status of the weak pointer.
It would be nice to apply this trick to lots of things in GHC,
e.g. ensuring that HsSyn is not retained after the desugarer, or
ensuring that CoreSyn from the previous simplifier pass is not retained.
Test Plan: validate
Reviewers: bgamari, simonpj, erikd, niteria
Subscribers: thomie, carter
GHC Trac Issues: #15111
|
|
|
|
| |
This reverts commit 5fe6aaa3756cda654374ebfd883fa8f064ff64a4.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Space leaks in GHCi emerge from time to time and tend to come back again
after they get fixed. This is an attempt to limit regressions by
* adding a reliable detection for some classes of space leaks in GHCi
* turning on leak checking for all GHCi tests in the test suite, so that
we'll notice if the leak appears again.
The idea for detecting space leaks is quite simple:
* find some data that we expect to be GC'd later, make a weak pointer to it
* when we expect the data to be dead, do a `performGC` and then check
the status of the weak pointer.
It would be nice to apply this trick to lots of things in GHC,
e.g. ensuring that HsSyn is not retained after the desugarer, or
ensuring that CoreSyn from the previous simplifier pass is not retained.
Test Plan: validate
Reviewers: bgamari, simonpj, erikd, niteria
Subscribers: thomie, carter
GHC Trac Issues: #15111
Differential Revision: https://phabricator.haskell.org/D4658
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Requires bumping several submodules.
Test Plan: ./validate
Reviewers: hvr, bgamari
Subscribers: thomie, carter
GHC Trac Issues: #15042
Differential Revision: https://phabricator.haskell.org/D4604
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update to Win32 2.6 which is the expected version release for 8.4
This involves moving Cabal forward which brings some backwards incompatible
changes that needs various fixups.
Bump a bunch of submodules
Test Plan: ./validate
Reviewers: austin, bgamari, angerman
Reviewed By: bgamari, angerman
Subscribers: angerman, thomie, rwbarton
Differential Revision: https://phabricator.haskell.org/D4133
|
|
|
|
|
|
| |
This reverts commit 561bdca16e2fe88d0b96fc10098955eabca81bba.
submodule
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Update to Win32 2.6 which is the expected version release for 8.4
This bumps the required submodule s as well.
Test Plan: ./validate
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D4117
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IOW, code compiles -Wnoncanonical-monoidfail-instances clean now
This is easy now since we require GHC 8.0/base-4.9 or later
for bootstrapping.
Note that we can easily enable `MonadFail` via
default-extensions: MonadFailDesugaring
in compiler/ghc.cabal.in
which currently would point out that NatM doesn't have
a proper `fail` method, even though failable patterns
are made use of:
compiler/nativeGen/SPARC/CodeGen.hs:425:25: error:
* No instance for (Control.Monad.Fail.MonadFail NatM)
arising from a do statement
with the failable pattern ‘(dyn_c, [dyn_r])’
|
|
|
|
| |
IOW, code compiles -Wnoncanonical-monoid-instances clean now
|
|
|
|
| |
Also bumps Cabal submodule due to version bound bump.
|
|
|
|
|
|
| |
Bumps containers, time, and unix submodules.
This reverts commit c347a121b07d22fb91172337407986b6541e319d.
|
|
|
|
|
|
|
|
| |
They broke everything and the solution will be non-trivial.
This reverts commit 8ccbc2e5252abd4fa67d155d4fff489ee9929906.
This reverts commit c8d995db5d743358b0583fe97f8113bf9047641e.
This reverts commit 7153370288e6075c4f8c996ff02227e48805da06.
|
|
|
|
|
| |
This unfortunately had quite a number of knock-on effects, including a need for
new releases of directory and unix.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bump the version of `Win32` to `2.5.0.0` which is a major update and includes
fixes for wrong alignments and wrong 64-bit types. Strangely enough this also
seems to resolve #12713, where `T10858` was failing due to too-low allocations.
The underlying type aliases have changed, so there is a potential
for user programs not to compile anymore, but the types were incorrect.
This also requires a bump in the `directory`, `Cabal`, and `process`
submodules.
Original author: Tamar Christina <tamar@zhox.com>
Test Plan: ./validate
Reviewers: bgamari, RyanGlScott, austin
Subscribers: hvr, RyanGlScott, thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D2938
|