| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
David (@treeowl) writes:
> Following @kcsongor, I've used ridiculous data family result kind
> polymorphism in `linear-generics`, and am currently working on getting
> it into `staged-gg`. If it should be removed, I'd appreciate a heads up,
> and I imagine Csongor would too.
>
> What do I need by ridiculous polymorphic result kinds? Currently, data
> families are allowed to have result kinds that end in `Type` (or maybe
> `TYPE r`? I'm not sure), but not in concrete data kinds. However, they
> *are* allowed to have polymorphic result kinds. This leads to things I
> think most of us find at least quite *weird*. For example, I can write
>
> ```haskell
> data family Silly :: k
> data SBool :: Bool -> Type where
> SFalse :: SBool False
> STrue :: SBool True
> SSSilly :: SBool Silly
> type KnownBool b where
> kb :: SBool b
> instance KnownBool False where kb = SFalse
> instance KnownBool True where kb = STrue
> instance KnownBool Silly where kb = Silly
> ```
>
> Basically, every kind now has potentially infinitely many "legit" inhabitants.
>
> As horrible as that is, it's rather useful for GHC's current native
> generics system. It's possible to use these absurdly polymorphic result
> kinds to probe the structure of generic representations in a relatively
> pleasant manner. It's a sort of "formal type application" reminiscent of
> the notion of a formal power series (see the test case below). I suspect
> a system more like `kind-generics` wouldn't need this extra probing
> power, but nothing like that is natively available as yet.
>
> If the ridiculous result kind polymorphism is banished, we'll still be
> able to do what we need as long as we have stuck type families. It's
> just rather less ergonomical: a stuck type family has to be used with a
> concrete marker type argument.
Closes #20996
Co-authored-by: Matthew Pickering <matthewtpickering@gmail.com>
|
| | |
|
| |
|
|
| |
Fixes #20995
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The insert_overlapping used in lookupInstEnv used to return different
results depending on the order in which instances were processed.
The problem was that we could end up discarding an overlapping instance
in favour of a more specific non-overlapping instance. This is a
problem because, even though we won't choose the less-specific instance
for matching, it is still useful for pruning away other instances,
because it has the overlapping flag set while the new instance doesn't.
In insert_overlapping, we now keep a list of "guard" instances, which
are instances which are less-specific that one that matches (and hence
which we will discard in the end), but want to keep around solely for
the purpose of eliminating other instances.
Fixes #20946
|
| |
|
|
| |
This fixes #20938.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test has been the scourge of contributors for a long time.
It has caused many failed CI runs and wasted hours debugging a test
which barely does anything. The fact is does nothing is the reason for
the flakiness and it's very sensitive to small changes in initialisation costs,
in particular adding wired-in things can cause this test to fluctuate
quite a bit.
Therefore we admit defeat and just bump the threshold up to 10% to catch
very large regressions but otherwise don't care what this test does.
Fixes #19414
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, `DeriveGeneric` would look up the fixity of a data constructor
using `getFixityEnv`, but this is subtly incorrect for data constructors
defined in external modules. This sort of situation can happen with
`StandaloneDeriving`, as noticed in #20994. In fact, the same bug has occurred
in the past in #9830, and while that bug was fixed for `deriving Read` and
`deriving Show`, the fix was never extended to `DeriveGeneric` due to an
oversight. This patch corrects that oversight.
Fixes #20994.
|
| |
|
|
|
| |
deb9 is now end-of-life so we are dropping support for producing
bindists.
|
| | |
|
| |
|
|
| |
Fixes #20984.
|
| |
|
|
| |
Fixes bootstrap with GHC 9.0 after 5a6efd218734dbb5c1350531680cd3f4177690f1
|
| | |
|
| |
|
|
|
|
|
|
| |
As requested by Simon after review of !7342.
I also took liberty to define the `Functor` instance by hand, as the derived one
subverts the invariants maintained by the pattern synonym (as already stated in
`Note [The one-shot state monad trick]`).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives users the choice to enable __compact_unwind sections
when linking. These were previously hardcoded to be removed.
This can be used to solved the problem "C++ does not catch
exceptions when used with Haskell-main and linked by ghc",
https://gitlab.haskell.org/ghc/ghc/-/issues/11829
It does not change the default behavior, because I can not
estimate the impact this would have.
When Apple first introduced the compact unwind ABI, a number of
open source projects have taken the easy route of disabling it,
avoiding errors or even just warnings shortly after its
introduction.
Since then, about a decade has passed, so it seems quite possible
that Apple itself, and presumably many programs with it, have
successfully switched to the new format, to the point where the
old __eh_frame section support is in disrepair. Perhaps we should
get along with the program, but for now we can test the waters
with this flag, and use it to fix packages that need it.
|
| |
|
|
|
|
|
| |
Fixes #15531 by ensuring that we know the corresponding C type for all
marshalling wrappers.
Closes #15531.
|
| |
|
|
| |
See #20939
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The test reads a 16 bit value from an array of 8 bit values. Naturally,
that leads to different values read on big-endian architectures than
on little-endian. In this case the value read is 0x8081 on big-endian
and 0x8180 on little endian. This patch changes the argument of the `and`
machop to mask bit 7 which is the only bit different. The test still checks
that bit 15 is zero, which was the original issue in #20638.
Fixes #20906.
|
| |
|
|
|
|
|
| |
Newer lld versions may include vendor info in --version output and
thus the version string may not start with ‘LLD’.
Fixes #20907
|
| |
|
|
| |
Closed #20904
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
I found it weird that most of the combinators weren't actually strict. Making
`pure` strict in the state should hopefully give Nested CPR an easier time to
unbox the nested state.
|
| |
|
|
| |
Issue was reported on #13306
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The simplest way to do this seemed to be to persist the whole type in
the extension field from the typechecker so that the few relevant places
* Desugaring can work out the return type by splitting this type rather
than calling `dsExpr` (slightly more efficient).
* hsExprType can just return the correct type.
* Zonking has to now zonk the type as well
The other option we considered was wiring in StaticPtr but that is
actually quite tricky because StaticPtr refers to StaticPtrInfo which
has field selectors (which we can't easily wire in).
Fixes #20150
|
| |
|
|
|
|
| |
like we do for the non-Hadrian wrapper script.
Otherwise if $bindir/ghc is a different ghc version then versioned ghci will incorrectly run the other ghc version instead.
(Normally this would only happen if there are parallel ghc versions installed in bindir.)
All the other wrapper scripts already have versioned executablename
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously (9ebda74ec5331911881d734b21fbb31c00a0a22f) `environ` was
added to `RtsSymbols` to ensure that environment was correctly
propagated when statically linking. However, this introduced #20577
since platforms are inconsistent in whether they provide a prototype for
`environ`. I fixed this by providing a prototype but while doing so
dropped symbol-table entry, presumably thinking that it was redundant
due to the entry in the mingw-specific table.
Here I reintroduce the symbol table entry for `environ` and move libc
symbols shared by Windows and Linux into a new macro,
`RTS_LIBC_SYMBOLS`, avoiding this potential confusion.
|
| | |
|
| | |
|
| | |
|
| |
|
| |
This reverts commit c0b854e929f82c680530e944e12fad24f9e14f8e
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
See #20802.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Avoid requiring to pass DynFlags to mkDataConRep/buildDataCon. When we
load an interface file, these functions don't use the flags.
This is preliminary work to decouple the loader from the type-checker
for #14335.
|
| |
|
|
| |
Fixes #20928
|
| |
|
|
|
|
| |
(Fixes #10616 and #10617)
Co-authored-by: Roland Senn <rsx@bluewin.ch>
|
| | |
|
| |
|
|
|
| |
They are likely broken for the same reason as FreeBSD where the tests
are already disabled.
|
| |
|
|
|
|
|
| |
The test currently times out waiting for end of stdin in getContents.
The expected output indicates that nothing should come for the test to
pass as written. It is unclear how the test was supposed to pass, but
this looks like a sufficient hack to make it work.
|
