| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* SysTools
* Parser
* GHC.Builtin
* GHC.Iface.Recomp
* Settings
Update Haddock submodule
Metric Decrease:
Naperian
parsing001
|
|
|
|
|
|
|
|
| |
This allows us to remove several bits of CPP that are either always
true or no longer reachable. As an added bonus, we no longer need to
worry about importing `Control.Monad.Fail.fail` qualified to avoid
clashing with `Control.Monad.fail`, since the latter is now the same
as the former.
|
|
|
|
|
|
|
| |
Update Haddock submodule
Metric Increase:
haddock.compiler
|
|
|
|
|
|
|
| |
This fixes #17786, where the error parser fails to correctly handle the
drive name in absolute Windows paths.
Unfortunately I couldn't find a satisfactory way to test this.
|
| |
|
|
|
|
| |
submodule updates: nofib, haddock
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC should make calls using process jobs when calling out to GCC and LD.
The reason is these use the exec () family of posix functions. Window's
process model doesn't allow replacement of processes so this is emulated
by creating a new process and immediately exiting the old one. Because
of this when using normal Windows wait functions you would return even
without the child process having finished. In this case if you are
depending on data from the child you will enter a race condition.
The usual fix for this is to use process jobs and wait for the
termination of all children that have ever been spawn by the process you
called. But also waiting for the freeing of all resources.
|
|
|
|
|
|
|
|
|
| |
Issue #1110 was apparently due to a bug in Vista which prevented GCC
from finding its binaries unless we explicitly added it to PATH.
However, this workaround was incorrectly applied on non-Windows
platforms as well, resulting in ill-formed PATHs (#17266).
Fixes #17266.
|
|
|
|
|
| |
This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.
|
|
Summary:
SysTools and DriverTools have an annoying mutual dependency.
They also each contain pieces of the linker. In order for
changes to be shared between the library and the exe linking
code this dependency needs to be broken in order to avoid
using hs-boot files.
Reviewers: austin, bgamari, erikd
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D4071
|