| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
I am not happy with this solution; a better way is to use uniformly
unicode or bytes in both Pythons, but this seems too disruptive for now.
|
| |
|
| |
|
|
|
|
| |
This allows ^C during test discovery
|
| |
|
|
|
|
| |
Python 3 does not like it
|
| |
|
| |
|
|
|
|
| |
Mostly done by manually checking 2to3 output
|
|
|
|
| |
Thanks to aspidites <emarshall85@gmail.com> who provided the patch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces the entities in Data.List conflicting with Data.Foldable
with re-exports of the generalised version from Data.Foldable.
As of this commit, the following compiles w/o error
module XPrelude (module X) where
import Control.Monad as X
import Data.Foldable as X
import Data.List as X
import Prelude as X
Reviewed By: austin, dfeuer, ekmett
Differential Revision: https://phabricator.haskell.org/D229
|
|
|
|
|
|
|
|
|
|
| |
Turn `toList`, `elem`, `sum`, `product`, `maximum`, and `minimum` into
`Foldable` methods. This helps avoiding regressions (and semantic
differences) while implementing #9586
Reviewed By: austin, dfeuer, ekmett
Differential Revision: https://phabricator.haskell.org/D231
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This renames the Data.List module to Data.OldList, and puts a new
Data.List module into its place re-exporting all list functions.
The plan is to leave the monomorphic versions of the list functions in
Data.OldList to help smooth the transition.
The new Data.List module then will simply re-export entities from
Data.OldList and Data.Foldable.
This refactoring has been placed in a separate commit to be able to
better isolate any regressions caused by the actual list function
generalisations when implementing #9586
This also updates the haskell2010, haskell98, and array submodules
Reviewed By: austin, ekmett
Differential Revision: https://phabricator.haskell.org/D228
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, the linker status logging output such as
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
is suppressed unless verbosity level is `-v2` or higher. This is done
to reduce the compiler message noise when TH is involved, which can
reduce the visibiliy of compile warnings.
Reviewed By: ekmett, austin
Differential Revision: https://phabricator.haskell.org/D232
|
|
|
|
|
|
|
|
|
| |
T4801 is deactived for now because it's currently too volatile
and causes too much noise in Phabricator's CI
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D230
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This was probably just an oversight. With this change the fixity matches
that from `Data.List.{elem,notElem`}`.
Addresses #9610
Reviewed By: austin, ekmett
Differential Revision: https://phabricator.haskell.org/D227
|
|
|
|
| |
This was broken in eae19112462fe77a3f1298bff12b409b205a581d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes Trac #9580, in which the Coercible machinery succeeded
even though the relevant data constructor was not in scope.
As usual I got dragged into a raft of refactoring changes,
all for the better.
* Delete TcEvidence.coercionToTcCoercion (now unused)
* Move instNewTyConTF_maybe, instNewTyCon_maybe to FamInst,
and rename them to tcInstNewTyConTF_maybe, tcInstNewTyCon
(They both return TcCoercions.)
* tcInstNewTyConTF_maybe also gets more convenient type,
which improves TcInteract.getCoercibleInst
* Define FamInst.tcLookupDataFamInst, and use it in TcDeriv,
(as well as in tcInstNewTyConTF_maybe)
* Improve error report for Coercible errors, when data familes
are involved Another use of tcLookupDataFamInst
* In TcExpr.tcTagToEnum, use tcLookupDataFamInst to replace
local hacky code
* Fix Coercion.instNewTyCon_maybe and Type.newTyConInstRhs to deal
with eta-reduced newtypes, using
(new) Type.unwrapNewTyConEtad_maybe and (new) Type.applyTysX
Some small refactoring of TcSMonad.matchFam.
|
| |
|
| |
|
|
|
|
| |
Thanks to Gabor for pointing this out
|
|
|
|
| |
Fixes Trac #9523
|
|
|
|
| |
Fixes Trac #9529
|
|
|
|
| |
Fixes Trac #9528
|
|
|
|
| |
This addresses Trac #5395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In `base`, the instances
instance Show ()
instance Show Bool
instance Show Ordering
instance Show a => Show (Maybe a)
where defined manually, even though we can leverage GHC's auto-deriver
which is perfectly capable by standalone derivation to avoid boiler-plate
code such as this.
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D219
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit reverts the commits
e12a6a8 Propositional equality for Datatype meta-information
0a8e6fc Make constructor metadata parametrized (with intended parameter <- datatype)
f097b77 Implement sameConstructor
cc618e6 get roles right and fix a FIXME
79c7125 Actually parametrize the Constructor with the Datatype
7bd4bab Supply a reasonable name (should be derived from d_name tho)
09fcd70 Use 'd_name' as the name (should be derived from d_name tho)
4d90e44 Add default case (fixes -Werror)
and effectively resets ghc.git to the state it was at commit
8c79dcb4dc2c6b8b663fa0c2e61d40d0ac0e9996
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This warning (enabled by default) reports places where a context
implicitly binds a type variable, for example
type T a = {-forall m.-} Monad m => a -> m a
Also update Haddock submodule.
Test Plan: validate
Reviewers: hvr, goldfire, simonpj, austin
Reviewed By: austin
Subscribers: simonmar, ezyang, carter
Differential Revision: https://phabricator.haskell.org/D211
GHC Trac Issues: #4426
|
|
|
|
| |
This reverts commit a8d7f81d1f6a9ea658c6f1a965bb3e7717b11e40.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|