| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes the following types levity-polymorphic in their
last argument:
- Array# a, SmallArray# a, Weak# b, StablePtr# a, StableName# a
- MutableArray# s a, SmallMutableArray# s a,
MutVar# s a, TVar# s a, MVar# s a, IOPort# s a
The corresponding primops are also made levity-polymorphic, e.g.
`newArray#`, `readArray#`, `writeMutVar#`, `writeIOPort#`, etc.
Additionally, exception handling functions such as `catch#`, `raise#`,
`maskAsyncExceptions#`,... are made levity/representation-polymorphic.
Now that Array# and MutableArray# also work with unlifted types,
we can simply re-define ArrayArray# and MutableArrayArray# in terms
of them. This means that ArrayArray# and MutableArrayArray# are no
longer primitive types, but simply unlifted newtypes around Array# and
MutableArrayArray#.
This completes the implementation of the Pointer Rep proposal
https://github.com/ghc-proposals/ghc-proposals/pull/203
Fixes #20911
-------------------------
Metric Increase:
T12545
-------------------------
-------------------------
Metric Decrease:
T12545
-------------------------
|
|
|
|
|
|
|
| |
Fixes #15531 by ensuring that we know the corresponding C type for all
marshalling wrappers.
Closes #15531.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here we refactor WinIO's IO completion scheme, squashing a memory leak
and fixing #18382.
To fix #18382 we drop the special thread status introduced for IoPort
blocking, BlockedOnIoCompletion, as well as drop the non-threaded RTS's
special dead-lock detection logic (which is redundant to the GC's
deadlock detection logic), as proposed in #20947.
Previously WinIO relied on foreign import ccall "wrapper" to create an
adjustor thunk which can be attached to the OVERLAPPED structure passed
to the operating system. It would then use foreign import ccall
"dynamic" to back out the original continuation from the adjustor. This
roundtrip is significantly more expensive than the alternative, using a
StablePtr. Furthermore, the implementation let the adjustor leak,
meaning that every IO request would leak a page of memory.
Fixes T18382.
|
| |
|
|
|
|
| |
that note was removed in 4196969c53c55191e644d9eb258c14c2bc8467da
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test only wants 1000 descriptors, so changing the limit to double
that *in the context of just this test* makes no sense.
This is a manual revert of 8f7194fae23bdc6db72fc5784933f50310ce51f9.
The justification given in the description doesn't instill confidence.
As of HEAD, the test fails on OpenBSD where ulimit -n is hard-limited
to 1024. The test suite attempts to change it to 2048, which
fails. The test proceeds with the unchanged default of 512 and
naturally the test program fails due to the low ulimit. The fixed test
now passes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reqlib modifer was supposed to indicate that a test needed a certain
library in order to work. If the library happened to be installed then
the test would run as normal.
However, CI has never run these tests as the packages have not been
installed and we don't want out tests to depend on things which might
get externally broken by updating the compiler.
The new strategy is to run these tests in head.hackage, where the tests
have been cabalised as well as possible. Some tests couldn't be
transferred into the normal style testsuite but it's better than never
running any of the reqlib tests. https://gitlab.haskell.org/ghc/head.hackage/-/merge_requests/169
A few submodules also had reqlib tests and have been updated to remove
it.
Closes #16264 #20032 #17764 #16561
|
| |
|
|
|
|
|
|
|
|
| |
We used to attempt compiling `foo_t val; *val;` to determine if `foo_t`
is a pointer type in C. This doesn't work if `foo_t` points to an
incomplete type, and autoconf will detect `foo_t` as a floating point
type in that case. Now we use `memset(val, 0, 0)` instead, and it works
for incomplete types as well.
|
|
|
|
|
|
|
|
|
| |
type for C pointers
When autoconf detects a C pointer type, we used to specify `Ptr ()` as
the Haskell type. This doesn't work in some cases, e.g. in `wasi-libc`,
`clockid_t` is a pointer type, but we expected `CClockId` to be an
integral type, and `Ptr ()` lacks various integral type instances.
|
| |
|
|
|
|
| |
Closes #20607.
|
|
|
|
| |
fixes #20412
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to providing stack traces, the scary HasCallStack will
hopefully make people think whether they want to use these functions,
i.e. act as a documentation hint that something weird might happen.
A single metric increased, which doesn't visibly
use any method with `HasCallStack`.
-------------------------
Metric Decrease:
T9630
Metric Decrease:
T19695
T9630
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
| |
As pointed out in #20776, placing quotes in this way linked to the
'Integral' type class which is nothing to do with 'readInt', the text
should rather just be "integral", to suggest that the argument must be
an integer.
Closes #20776
|
|
|
|
|
|
|
| |
* Make 'mtimesDefault' use 'stimes' for the underlying monoid
rather than the default 'stimes'.
* Explain in the documentation why one might use `mtimesDefault`.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Amazing nobody had reported the "Foldabla" typo. :-(
The Traversable docs got overhauled, leaving a stale
link in Foldable to a section that got replaced. Gave
the new section an anchor and updated the link.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several times in the past, it has happened that things from GHC.Types
were not re-exported from GHC.Exts, forcing users to import either
GHC.Types or GHC.Prim, which are subject to internal change without
notice.
We now re-export GHC.Types from GHC.Exts, which should avoid this
happening again in the future.
In particular, we now re-export `Multiplicity` and `MultMul`,
which we didn't before.
Fixes #20695
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While a *strict* (i.e. constant space) right-fold on lists is not
possible, the default `foldr'` is optimised for structures like
`Seq`, that support efficient access to the right-most elements.
The original default implementation seems to have a better
constant factor for lists, so we add a monomorphic implementation
in GHC.List.
Should this be re-exported from `Data.List`? That would be a
user-visible change if both `Data.Foldable` and `Data.List` are
imported unqualified...
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit bddecda1a4c96da21e3f5211743ce5e4c78793a2.
This implements the first step in the plan formulated in #20025 to
improve the communication and migration strategy for the proposed
changes to Data.List.
Requires changing the haddock submodule to update the test output.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Several additions since 4.15 had not been recorded in the changelog:
- newtypes And, Ior, Xor and Iff,
- oneBits
- symbolic synonyms `.^.`, `.>>.`, `!>>.`, `.<<.` and `!<<.`.
Fixes #20608.
|
|
|
|
|
|
|
|
| |
We can inline a bit earlier than the previous pragmas said. I think
they dated from an era in which the InitialPhase did no inlining.
I don't think this patch will have much effect, but it's
a bit cleaner.
|
|
|
| |
This reverts commit 41117d71bb58e001f6a2b6a11c9314d5b70b9182
|
|
|
|
| |
They were added in 33173a51c77d9960d5009576ad9b67b646dfda3c, which constitutes GHC 8.10.1 / base-4.14.0.0
|
|
|
|
|
|
| |
Haddock doesn't know how to render SAKS, so the only current way to make
the documentation show the kind is to write what it should say into the
type family declaration.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many small things to fix:
* Hadrian: platform triple is "x86_64-w64-mingw32" and this wasn't recognized by
Hadrian (note "w64" instead of "unknown")
* Hadrian was using the build platform ("isWindowsHost") to detect
the use of the Windows toolchain, which was wrong. We now use the
"targetOs" setting.
* Hadrian was doing the same thing for Darwin so we fixed both at once,
even if cross-compilation to Darwin is unlikely to happen afaik (cf
"osxHost" vs "osxTarget" changes)
* Hadrian: libffi name was computed in two different places and one of
them wasn't taking the different naming on Windows into account.
* Hadrian was passing "-Irts/include" when building the stage1 compiler
leading to the same error as in #18143 (which is using make).
stage1's RTS is stage0's one so mustn't do this.
* Hadrian: Windows linker doesn't seem to support "-zorigin" so we
don't pass it (similarly to Darwin)
* Hadrian: hsc2hs in cross-compilation mode uses a trick (taken from
autoconf): it defines "static int test_array[SOME_EXPR]" where
SOME_EXPR is a constant expression. However GCC reports an error
because SOME_EXPR is supposedly not constant. This is fixed by using
another method enabled with the `--via-asm` flag of hsc2hs. It has been
fixed in `make` build system (5f6fcf7808b16d066ad0fb2068225b3f2e8363f7)
but not in Hadrian.
* Hadrian: some packages are specifically built only on Windows but they
shouldn't be when building a cross-compiler (`touchy` and
`ghci-wrapper`). We now correctly detect this case and disable these
packages.
* Base: we use `iNVALID_HANDLE_VALUE` in a few places. It fixed some
hsc2hs issues before we switched to `--via-asm` (see above). I've kept
these changes are they make the code nicer.
* Base: `base`'s configure tries to detect if it is building for Windows
but for some reason the `$host_alias` value is `x86_64-windows` in my
case and it wasn't properly detected.
* Base: libraries/base/include/winio_structs.h imported "Windows.h" with
a leading uppercase. It doesn't work on case-sensitive systems when
cross-compiling so we have to use "windows.h".
* RTS: rts/win32/ThrIOManager.c was importin "rts\OSThreads.h" but this
path isn't valid when cross-compiling. We replaced "\" with "/".
* DeriveConstants: this tool derives the constants from the target
RTS header files. However these header files define `StgAsyncIOResult`
only when `mingw32_HOST_OS` is set hence it seems we have to set it
explicitly.
Note that deriveConstants is called more than once (why? there is
only one target for now so it shouldn't) and in the second case this
value is correctly defined (probably coming indirectly from the import
of "rts/PosixSource.h"). A better fix would probably be to disable the
unneeded first run of deriveconstants.
|
|
|
|
|
|
|
|
| |
- Fix cut/paste error by adding missing `c` pattern in `Vec3`
traversable instance.
- Add a bit of contextual prose above the Vec2/Vec3 instance
sample code.
|
| |
|
|
|
|
|
|
|
|
| |
Performance improvement:
T15185(normal) run/alloc 51112.0 41032.0 -19.7% GOOD
Metric Decrease:
T15185
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Primops types were dependent on the target word-size at *compiler*
compilation time. It's an issue for multi-target as GHC may not have the
correct primops types for the target.
This patch fixes some primops types: if they take or return fixed 64-bit
values they now always use `Int64#/Word64#`, even on 64-bit
architectures (where they used `Int#/Word#` before). Users of these
primops may now need to convert from Int64#/Word64# to Int#/Word# (a
no-op at runtime).
This is a stripped down version of !3658 which goes the all way of
changing the underlying primitive types of Word64/Int64. This is left
for future work.
T12545 allocations increase ~4% on some CI platforms and decrease ~3% on
AArch64.
Metric Increase:
T12545
Metric Decrease:
T12545
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ticket #20562 revealed that Solo, which is a wired-in TyCon, had
a record field that wasn't being added to the type env. Why not?
Because wired-in TyCons don't have record fields.
It's not hard to change that, but it's tiresome for this one use-case,
and it seems easier simply to make `getSolo` into a standalone
function.
On the way I refactored the handling of Solo slightly, to put it
into wiredInTyCons (where it belongs) rather than only in
knownKeyNames
|
|
|
|
|
| |
Otherwise the instances aren't good list producers.
See Note [Stable Unfolding for list producers].
|
| |
|
|
|
|
|
| |
It seems more clear to think of lines as LF-terminated rather than
LF-separated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Users of `undefined` don’t want to see
```
files.hs: Prelude.undefined:
CallStack (from HasCallStack):
error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err
undefined, called at file.hs:151:19 in main:Main
```
but want to see
```
files.hs: Prelude.undefined:
CallStack (from HasCallStack):
undefined, called at file.hs:151:19 in main:Main
```
so let’s make that so.
The function for that is `withFrozenCallStack`, but that is not usable
here (module dependencies, and also not representation-polymorphic). And
even if it were, it could confuse GHC’s strictness analyzer, leading to
big regressions in some perf tests (T10421 in particular).
So after shuffling modules and definitions around, I eventually noticed
that the easiest way is to just not call `error` here.
Fixes #19886
|
| |
|