| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This finally takes the gloves off, and performs the first actual
generalization in order to implement #9586. This re-exports the
respective definitions for the 4 combinators defined in Data.Foldable.
This way, importing Data.Foldable and Control.Monad unqualified won't bring
conflicting definitions of those 4 entities into scope anymore.
This change seems to have some minor effect on rule-firing, which
causes some wibble in the test-case T4007
Reviewed By: ekmett, austin
Differential Revision: https://phabricator.haskell.org/D226
|
|
|
|
|
|
|
|
|
| |
This is the last preparation needed before generalizing entities in
Control.Monad conflicting with those from Data.Foldable (re #9586)
Reviewed By: ekmett, austin
Differential Revision: https://phabricator.haskell.org/D225
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both modules still export `void`, but `void`'s implementation now lives in
Data.Functor where it actually belongs in (as it doesn't need a Monad context)
The desired side-effect of this is to invert the import-dep
between Control.Monad and Data.Functor.
Reviewed By: ekmett, austin
Differential Revision: https://phabricator.haskell.org/D224
|
|
|
|
|
|
|
|
|
|
|
| |
This is necessary in order to invert the import-dependency between
Data.Foldable and Control.Monad (for addressing #9586)
This also updates the `binary` submodule to qualify a GHC.Base import
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D223
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
They were dropped because `Maybe` wasn't available in GHC.Base, but now
it is thanks to b47521991a7574f4f3554f7c5444a8c60cfe9efd.
Differential Revision: https://phabricator.haskell.org/D215
|
|
|
|
|
|
|
| |
This is preparatory work for reintroducing SPECIALISEs that were lost
in d94de87252d0fe2ae97341d186b03a2fbe136b04
Differential Revision: https://phabricator.haskell.org/D214
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This reverts commit 4748f5936fe72d96edfa17b153dbfd84f2c4c053. 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:
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
|
|
|
|
|
|
|
|
| |
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 d94de87252d0fe2ae9.
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
|
|
|
|
| |
...to kill "Kill CPP conditionals for HUGS and old GHCs"
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation for `seq` was recently augmented via #9390 &
cbfa107604f4cbfaf02bd633c1faa6ecb90c6dd7. 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 527bcc41630918977c7 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 ceb68b9118fa883e88abfaa532fc78f6640cf17f,
which is only 13 years ago :-).
|
|
|
|
|
|
|
| |
This also updates a few submodules to have their upper-bounds on
`time` relaxed to allow `time-1.5`. The only package that can't be
upgraded yet is `Cabal` due to API changes breaking `ghc-cabal`. This
needs to be addressed in a future commit.
|
|
|
|
|
|
|
| |
Since we now had to major bump due to AMP being landed, `base-4.7.1.0` is not
gonna happen, as we're going straight for a `base-4.8.0.0` release.
[skip ci] since this is a doc-only change
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit updates several submodules in order to bump
the upper bounds on `base` of most boot packages
Moreover, this updates some of the test-suite cases which have
version numbers hardcoded within.
However, I'm not sure if this commit didn't introduce the following
two test-failures
ghc-api T8628 [bad stdout] (normal)
ghc-api T8639_api [bad stdout] (normal)
This needs investigation
|
|
|
|
|
|
|
|
| |
This reverts commit 0829f4c829a92d1287b820b12102a64dac91d35a.
This fails to build, because I'm dumb and hasty, obviously.
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This includes pretty much all the changes needed to make `Applicative`
a superclass of `Monad` finally. There's mostly reshuffling in the
interests of avoid orphans and boot files, but luckily we can resolve
all of them, pretty much. The only catch was that
Alternative/MonadPlus also had to go into Prelude to avoid this.
As a result, we must update the hsc2hs and haddock submodules.
Signed-off-by: Austin Seipp <austin@well-typed.com>
Test Plan: Build things, they might not explode horribly.
Reviewers: hvr, simonmar
Subscribers: simonmar
Differential Revision: https://phabricator.haskell.org/D13
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
to allow GHC to maybe remove the Maybe. See the code comment for more
commentary. This fixes #9369.
Test Plan: see what happens on ghcspeed (once it is merged)
Reviewers: austin
Reviewed By: austin
Subscribers: simonmar, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D198
GHC Trac Issues: #9369
|
|
|
|
|
| |
This is a follow-up commit to
e428b5b8cc1448dcff7d7cdcbeb738eb0bea102f (refs D195 & #9550)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As discussed in
http://www.haskell.org/pipermail/libraries/2014-July/023314.html and
submitted at #9550.
Test Plan: Submit to phab, see what happens.
Reviewers: austin
Subscribers: simonmar, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D195
GHC Trac Issues: #9550
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The property
countLeadingZeros . negate = const 0
doesn't generally hold and it's not such a useful property to state, as
it simply follows from "sign-bit == most-significant-bit" for FiniteBits
types which use twos-complement representation for negative values, and
even then it breaks down for 0...
TLDR, remove thinko from documentation of `countLeadingZeros`
|
|
|
|
|
|
| |
...some files more or less recently touched by me
[ci skip]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This exposes the newly added CLZ/CTZ primops from
e0c1767d0ea8d12e0a4badf43682a08784e379c6 (re #9340)
via two new methods `countLeadingZeros` and `countTrailingZeros`
in the `Data.Bits.FiniteBits` class.
The original proposal can be found at
http://www.haskell.org/pipermail/libraries/2014-August/023567.html
Test Plan: successful validate
Reviewers: ekmett, tibbe
GHC Trac Issues: #9532
Differential Revision: https://phabricator.haskell.org/D158
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original proposal text can be found at
http://www.haskell.org/pipermail/libraries/2014-August/023491.html
The proposal passed with a clear majority, and was additionally
confirmed by the core libraries committee.
*Compatibility Note*
Only code that imports `Data.Word` for the sole purpose of using `Word`
*and* requires to be `-Werror`-clean (due to `-fwarn-unused-imports`)
is affected by this change.
In order to write warning-free forward/backward compatible against `base`,
a variant of the following CPP-based snippet can be used:
-- Starting with base>4.7.0 or GHC>7.8 Prelude re-exports 'Word'
-- The following is needed, if 'Word' is the *only* entity needed from Data.Word
#ifdef MIN_VERSION_base
# if !MIN_VERSION_base(4,7,1)
import Data.Word (Word)
# endif
-- no cabal_macros.h -- fallback to __GLASGOW_HASKELL__
#elif __GLASGOW_HASKELL__ < 709
import Data.Word (Word)
#endif
This also updates the haddock submodule in order to avoid a compile warning
|
|
|
|
| |
Patch written by Pali Gabor Janos <pali.gabor@gmail.com>
|
|
|
|
|
|
| |
In particular, Cabal was still in one place using old file-style package
databases. Haddock just needed simple changes to follow the change of
representation of packages in the ghc library.
|
|
|
|
| |
Some others addressed as part of other recent patches.
|
|
|
|
| |
in the previous patches in this series
|
| |
|
|
|
|
|
| |
The ghc-pkg program of course still depends on Cabal, it's just the
bin-package-db library (shared between ghc and ghc-pkg) that does not.
|
|
|
|
|
|
|
|
| |
Also start using the new package db file format properly, by using the
ghc-specific section.
This is the main patch in the series for removing the compiler's dep
on the Cabal lib.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of the new format is to make it possible for the compiler
to not depend on the Cabal library. The new cache file format contains
more or less the same information duplicated in two different sections
using different representations.
One section is basically the same as what the package db contains now,
a list of packages using the types defined in the Cabal library. This
section is read back by ghc-pkg, and used for things like ghc-pkg dump
which have to produce output using the Cabal InstalledPackageInfo text
representation.
The other section is a ghc-local type which contains a subset of the
information from the Cabal InstalledPackageInfo -- just the bits that
the compiler cares about.
The trick is that the compiler can read this second section without
needing to know the representation (or types) of the first part. The
ghc-pkg tool knows about both representations and writes both.
This patch introduces the new cache file format but does not yet use it
properly. More patches to follow. (As of this patch, the compiler reads
the part intended for ghc-pkg so it still depends on Cabal and the
ghc-local package type is not yet fully defined.)
|
|
|
|
|
|
|
| |
We can serialise directly, without having to convert some fields to
string first.
(Part of preparitory work for removing the compiler's dep on Cabal)
|
|
|
|
|
|
|
|
|
|
| |
This was previously happening by a fluke -- they were called with those types
in GHC.Real itself -- but my recent changes to specialisation mean that auto
specialisations like these are not necessarily exported.
Losing those specialisations made a huge difference to two performance tests
perf/should_run/MethSharing
perf/should_run/T9339
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| |
|
|
|
|
|
| |
Specialise liftM, foldM, etc, and make them specialisable
for new monads at their call sites by using INLINEABLE
|