| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |/
| | |
| | |
| | | |
This is consistent with the other unoptimized ways.
|
| |/ |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Unfortunately this was introduced in base-4.11.0 (GHC 8.4.1)
whereas the other locking primitives were added in base-4.10.0 (GHC
8.2.1).
|
| |
| |
| |
| |
| | |
Currently this routinely fails in the i386 job.
See #7653.
|
| |
| |
| |
| |
| |
| |
| | |
Replace the outer `MVar` in `QSemN` with an `IORef`. This should
probably be lighter, and it removes the need for `uninterruptibleMask`.
Previously Differential Revision https://phabricator.haskell.org/D4896
|
|/ |
|
|
|
|
| |
This fixes #17060.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add a reference to the documentation for Data.List in the description
for String.
On the generated Haddock for Data.String,
http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-String.html
there is curently no hyperlink to Data.List, which is where a reader will find most of the useful functions which can operate on Strings. I imagine this has confused beginners who came to this page looking for String operations.
|
|
|
|
|
| |
Use standalone kind signatures instead of complete user-specified kinds
in Data.Type.Equality and Data.Typeable
|
|
|
|
| |
mention of TypeError
|
| |
|
|
|
|
|
| |
The `Ix` class seems rather orthogonal to its original home in
`GHC.Arr`.
|
|
|
|
| |
Fixes #17181.
|
|
|
|
|
|
| |
Metric Increase:
haddock.base
T4029
|
| |
|
|
|
|
|
| |
This adds isResourceVanished, resourceVanishedErrorType, and
isResourceVanishedErrorType to System.IO.Error, resolving #14730.
|
| |
|
|
|
|
| |
Define MD5Context in terms of `uint*_t` and don't use `HsFFI.h`.
|
|
|
|
| |
While avoiding #16943.
|
|
|
|
|
|
|
|
|
|
|
| |
These kinds of imports are necessary in some cases such as
importing instances of typeclasses or intentionally creating
dependencies in the build system, but '-Wunused-imports' can't
detect when they are no longer needed. This commit removes the
unused ones currently in the code base (not including test files
or submodules), with the hope that doing so may increase
parallelism in the build system by removing unnecessary
dependencies.
|
| |
|
|
|
|
|
|
| |
This reverts commit 4e1dfc3767167dddd0e151a2df8305b12aa0f49c.
Due to #16943.
|
| |
|
|
|
|
| |
Generic1 instances to Kleisli
|
|
|
|
|
|
|
|
|
|
|
| |
Kqueue/kevent implementation used to ignore events to be unsubscribed
from when events to be subscribed to were provided. This resulted in a
lost notification subscription, when GHC runtime didn't listen for any
events, yet the kernel considered otherwise and kept waking up the IO
manager thread.
This commit fixes this issue by always adding and removing all of the
provided subscriptions.
|
| |
|
|
|
|
| |
As noted in #16909.
|
|
|
|
| |
Previously it was not marked as broken in profthreaded
|
|
|
|
|
|
|
| |
This prepares the way for making Int32# and Word32# the actual size they
claim to be.
Updates binary submodule for (de)serializing the new runtime reps.
|
| |
|
|
|
|
|
|
|
|
| |
These are unexploded minds as far as the linter is concerned. I don't
want to hit in my MRs by mistake!
I did this with `sed`, and then rolled back some changes in the docs,
config.guess, and the linter itself.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The compiler doesn't create uses nor compiles the uses that exist
specially. These are just plain C-- FFI.
These `await*` ones are especially important to so convert because "true"
primops are hard to make platform-specific currently.
The other exports are part of this commit so this module always exports
something, which avoids silly CPP elsewhere. More will be added later
once `foreign import prim` is extended.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously we would hackily evaluate a textual code snippet to compute
actions to disable I/O buffering and flush the stdout/stderr handles.
This broke in a number of ways (#15336, #16563).
Instead we now ship a module (`GHC.GHCi.Helpers`) with `base` containing
the needed actions. We can then easily refer to these via `Orig` names.
|
|
|
|
|
| |
Metric Increase:
haddock.base
|
| |
|
|
|
|
|
|
| |
Previously the Event enumeration produced by hsc2hs would sometimes
include a currently-unused POLLRDHUP item. This unused binding would
result in a build failure. Drop it.
|
|
|
|
|
|
| |
Previously there were a few cases where operations like `omit_ways`
were incorrectly passed a single way (e.g. `omit_ways('threaded2')`).
This won't work as the author expected.
|
|
|
|
| |
As noted in #16819, this operation is racy under concurrent execution.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC Proposal: 0013-unlifted-newtypes.rst
Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/98
Issues: #15219, #1311, #13595, #15883
Implementation Details:
Note [Implementation of UnliftedNewtypes]
Note [Unifying data family kinds]
Note [Compulsory newtype unfolding]
This patch introduces the -XUnliftedNewtypes extension. When this
extension is enabled, GHC drops the restriction that the field in
a newtype must be of kind (TYPE 'LiftedRep). This allows types
like Int# and ByteArray# to be used in a newtype. Additionally,
coerce is made levity-polymorphic so that it can be used with
newtypes over unlifted types.
The bulk of the changes are in TcTyClsDecls.hs. With -XUnliftedNewtypes,
getInitialKind is more liberal, introducing a unification variable to
return the kind (TYPE r0) rather than just returning (TYPE 'LiftedRep).
When kind-checking a data constructor with kcConDecl, we attempt to
unify the kind of a newtype with the kind of its field's type. When
typechecking a data declaration with tcTyClDecl, we again perform a
unification. See the implementation note for more on this.
Co-authored-by: Richard Eisenberg <rae@richarde.dev>
|
|
|
|
|
|
|
|
| |
Previously we used an awful hybrid batch script/Bourne shell script to
allow this test to run both on Windows and Linux (fixing #9399).
However, this breaks on some libc implementations (e.g. musl). Fix this.
Fixes #16798.
|
|
|
|
| |
As noted in #16536.
|
|
|
|
| |
As noted in #16535.
|
|
|
|
|
|
| |
As noted in #16224, CPUTime001 has been quite problematic, reporting
non-monotonic timestamps in CI. Unfortunately I've been unable to
reproduce this locally.
|
|
|
|
|
| |
Previously log and exp were primitives yet log1p and expm1 were FFI
calls. Fix this non-uniformity.
|
| |
|