GitLab

This allows several modules to avoid importing Control.Monad and thus break
import cycles that manifest themselves when implementing #9586

Reviewed By: austin, ekmett

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

This allows GHC.Stack to avoid importing Control.Monad, and
is preparatory work for implementing #9586

Reviewed By: austin

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

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

Summary: The imports of Data.Monoid and Data.Maybe in GHC.Event.KQueue are unnecessary and cause validate to fail.

Test Plan: Validate successfully (though I get some unrelated failures).

Reviewers: austin

Subscribers: simonmar, ezyang, carter

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

The existing `decodeDouble_2Int#` primop is rather inconvenient to use
(and in fact is not even used by `integer-gmp`) as the mantissa is split
into 3 components which would actually fit in an `Int64#` value.

However, `decodeDouble_Int64#` is to be used by the new `integer-gmp2`
re-implementation (see #9281).

Moreover, `decodeDouble_2Int#` performs direct bit-wise operations on the
IEEE representation which can be replaced by a combination of the
portable standard C99 `scalbn(3)` and `frexp(3)` functions.

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

They were dropped because `Maybe` wasn't available in GHC.Base, but now
it is thanks to b4752199.

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

This is preparatory work for reintroducing SPECIALISEs that were lost
in d94de872

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

Summary:
This reverts commit 4748f593. The fix for #9423
was reverted because this commit introduced a C function setIOManagerControlFd()
(defined in Schedule.c) defined for all OS types, while the prototype
(in includes/rts/IOManager.h) was only included when mingw32_HOST_OS is
not defined. This broke Windows builds.

This commit reverts the original commit and resolves the problem by only defining
setIOManagerControlFd() when mingw32_HOST_OS is defined. Hence the missing prototype
error should not occur on Windows.

In addition, since the io_manager_control_wr_fd field of the Capability struct is only
usd by the setIOManagerControlFd, this commit includes the io_manager_control_wr_fd
field in the Capability struct only when mingw32_HOST_OS is not defined.

Test Plan: Try to compile successfully on all platforms.

Reviewers: austin

Reviewed By: austin

Subscribers: simonmar, ezyang, carter

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

Summary:
While researching D176, I came across the following simplification
opportunity:

Not all functions that call utf8DecodeChar actually need the address
of the next char. And some need the 'number of bytes' read. So returning
nBytes instead of nextAddr should save a few addition and subtraction
operations, and makes the code a bit simpler.

Test Plan: it validates

Reviewers: simonmar, ezyang, austin

Reviewed By: austin

Subscribers: simonmar, ezyang, carter

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

Summary:
The dynamic linking code was already there but it was not called
on flag changes in ghci.

Test Plan: validate

Reviewers: hvr, simonmar, austin

Reviewed By: austin

Subscribers: simonmar, ezyang, carter

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

GHC Trac Issues: #1407

Summary:
exprIsConApp_maybe now detects string literals and correctly
splits them. This means case-statemnts on string literals can
now push the literal into the cases.

fix trac issue #9400

Test Plan: validate

Reviewers: austin, simonpj

Reviewed By: austin, simonpj

Subscribers: simonmar, ezyang, carter

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

GHC Trac Issues: #9400

Summary:
Cppcheck found a few defects in win32 IOManager and a typo in rts
testsuite. This commit fixes them.

Cppcheck 1.54 founds three possible null pointer dereferences of ioMan
pointer. It is dereferenced and checked for NULL after that.

testheapalloced.c contains typo in printf statement, which should print
percent sign but treated as parameter placement by compiler. To properly
print percent sign one need to use "%%" string.

FYI: Cppcheck 1.66 cannot find possible null pointer dereferences in
mentioned places, mistakenly thinking that some memory leaking instead.
I probably fill a regression bug to Cppcheck.

Test Plan:
Build project, run 'make fulltest'. It finished with 28 unexpected
failures. I don't know if they are related to my fix.

    Unexpected results from:
    TEST="T3500b T7891 tc124 T7653 T5321FD T5030 T4801 T6048 T5631 T5837 T5642 T9020 T3064 parsing001 T1969 T5321Fun T783 T3294"

    OVERALL SUMMARY for test run started at Tue Sep  9 16:46:27 2014 NOVT
     4:23:24 spent to go through
        4101 total tests, which gave rise to
       16075 test cases, of which
        3430 were skipped

         315 had missing libraries
       12154 expected passes
         145 expected failures

           3 caused framework failures
           0 unexpected passes
          28 unexpected failures

    Unexpected failures:
       ../../libraries/base/tests  T7653 [bad exit code] (ghci,threaded1,threaded2)
       perf/compiler               T1969 [stat not good enough] (normal)
       perf/compiler               T3064 [stat not good enough] (normal)
       perf/compiler               T3294 [stat not good enough] (normal)
       perf/compiler               T4801 [stat not good enough] (normal)
       perf/compiler               T5030 [stat not good enough] (normal)
       perf/compiler               T5321FD [stat not good enough] (normal)
       perf/compiler               T5321Fun [stat not good enough] (normal)
       perf/compiler               T5631 [stat not good enough] (normal)
       perf/compiler               T5642 [stat not good enough] (normal)
       perf/compiler               T5837 [stat not good enough] (normal)
       perf/compiler               T6048 [stat not good enough] (optasm)
       perf/compiler               T783 [stat not good enough] (normal)
       perf/compiler               T9020 [stat not good enough] (optasm)
       perf/compiler               parsing001 [stat not good enough] (normal)
       typecheck/should_compile    T7891 [exit code non-0] (hpc,optasm,optllvm)
       typecheck/should_compile    tc124 [exit code non-0] (hpc,optasm,optllvm)
       typecheck/should_run        T3500b [exit code non-0] (hpc,optasm,threaded2,dyn,optllvm)

Reviewers: austin

Reviewed By: austin

Subscribers: simonmar, ezyang, carter

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

Summary:
"./configure --target=TARGET" was broken; it would use the host gcc.
(So you had to explicitly specify "--with-gcc=TARGET-gcc" also,
as a workaround.)

This was broken by commit fc4856f9
for #8148. A comment claimed that FP_ARG_WITH_PATH_GNU_PROG_OPTIONAL
was the same as FP_ARG_WITH_PATH_GNU_PROG except for not raising
an error when the program isn't found; but that wasn't true --
the former didn't prepend the target name when cross-compiling.

We actually need three versions of FP_ARG_WITH_PATH_GNU_PROG since
the LLVM tools are usually not prefixed with the target name even
when cross-compiling. So I generalized the logic in a single macro.

Test Plan:
Built with "./configure --target=i386-unknown-linux"
and BuildFlavour=quick, successfully

Reviewers: ezyang, austin

Reviewed By: ezyang, austin

Subscribers: simonmar, ezyang, carter

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

Summary:
This is identical to the x86 output from bug #4290,
and fixes the hClose002 test when running under
x86_64-unknown-solaris2.

Test Plan: Re-run 'make TEST=hClose002' under x64 Solaris.

Reviewers: ezyang, austin

Reviewed By: ezyang, austin

Subscribers: simonmar, ezyang, carter

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

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

The new versions should work better under MSYS2

A few submodules' `config.{guess,sub}` files were updated as well

With this commit, all config.{guess,sub} files in the GHC tree have the md5sums

    0fb81517303511f05a01b14f41cec2cf  config.guess
    d2a165dceaa5ac1edba3c512f6ca7bd1  config.sub

This addresses #9597

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

Effective immediately, pushing to libraries/filepath requires
pushing to ssh://git@github.com/haskell/filepath.git.

It was annoying to test GHCi directly, so I added a ghc-api unit test
of the function instead.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

See Note [Recursive bindings for Applicative/Monad]. This documents the
tricky little details that kept me occupied for so long with this patch,
and why exactly we deviate from the original proposal.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Without 'join' as a part of Monad, this default implementation is bogus,
and is a leftover from d94de872.
Signed-off-by: Austin Seipp <austin@well-typed.com>

This exposes *only* the type-classes w/o any of their methods.
This is the very first step for implementing BPP (see #9586), which
already requires breaking up several import-cycles leading back to `Prelude`.

Ideally, importing `Prelude` should be avoided in most `base` modules,
as `Prelude` does not define any entities, but rather re-exports
existing ones.

Test Plan: validate passes

Reviewers: ekmett, austin

Reviewed By: ekmett, austin

Subscribers: simonmar, ezyang, carter

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

GHC Trac Issues: #9586

Right now, Phab's buildbot complains about

  Unexpected failures:
    perf/compiler T1969 [stat too good] (normal)
    perf/compiler T4801 [stat not good enough] (normal)

However, on my workstation, those tests don't fail (c.f. P14).
So this commit tries to blindly tweak those numbers and see if
if Phabricator succeeds to build this code-revision...

Test Plan: Let Harbormaster build it

Reviewers: austin

Subscribers: simonmar, ezyang, carter

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

...to kill "Kill CPP conditionals for HUGS and old GHCs"

The documentation for `seq` was recently augmented via #9390 &
cbfa1076. However, it doesn't show
up in the Haddock generated docs because `#ifdef __HADDOCK__` doesn't
work as expected.  Also, it's easier to just fix the problem at the
origin (which in this is case is the primops.txt.pp file).

The benefit/downside of this is that now the extended documentation
shows up everywhere `seq` is re-exported directly.

Forgot to fix-up the `haskell2010` and `haskell98` submodules in the previous
commit

I don't see any reason why this needs to be in Prelude, where it makes
life harder to avoid import cycles involving Prelude. Ideally, the
`Prelude` module should only re-export entities from other modules, and
not define anything on its own.

So this moves `($!)` close to the definition of its `($)` cousin.

Since 527bcc41 we require GHC >=7.6 for bootstrapping anyway.
This also allows to avoid the CPP-processing overhead for these two modules.

as spotted by David Feuer and reported as #9585.
The comment was right until ceb68b91,
which is only 13 years ago :-).