| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail
Coauthored-by: Ben Gamari <ben@well-typed.com>
|
| |
|
|
| |
Fixes #16425
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When GHC attempts to unify a metavariable with a type containing
foralls, it will be rejected as an occurrence of impredicativity.
GHC was /not/ extending the same treatment to predicate types, such
as in the following (erroneous) example from #11514:
```haskell
foo :: forall a. (Show a => a -> a) -> ()
foo = undefined
```
This will attempt to instantiate `undefined` at
`(Show a => a -> a) -> ()`, which is impredicative. This patch
catches impredicativity arising from predicates in this fashion.
Since GHC is pickier about impredicative instantiations, some test
cases needed to be updated to be updated so as not to fall afoul of
the new validity check. (There were a surprising number of
impredicative uses of `undefined`!) Moreover, the `T14828` test case
now has slightly less informative types shown with `:print`. This is
due to a a much deeper issue with the GHCi debugger (see #14828).
Fixes #11514.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Place each section on a separate page to ensure required
alignment (wastes lots ot space, needs to be improved).
2. Unwire relocation logic from macho sections (the most fiddly part
is adjusting internal relocations).
Other todos:
0. Add a test for section alignment.
1. Investigate 32bit relocations!
2. Fix memory leak in ZEROPAGE section allocation.
3. Fix creating redundant jump islands for GOT.
4. Investigate more compact section placement.
|
| | |
|
| | |
|
| |
|
|
| |
I believe removing __mingw_vsnwprintf from RtsSymbols fixed #16387.
|
| |
|
|
| |
It doesn't fail reliably.
|
| |
|
|
|
| |
I think the linker is routinely eating through the timeout,
leading to many spurious failures.
|
| |
|
|
|
|
|
| |
This test, which is only run on Windows, seems to be reliably timing
out.
See #16390.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A few tests previously failed with various failure modes. For instance,
`plugin-recomp-change` fails with:
```
Wrong exit code for plugin-recomp-change()(expected 0 , actual 2 )
Stderr ( plugin-recomp-change ):
Simple Plugin Passes Queried
Got options:
Simple Plugin Pass Run
C://GitLabRunner//builds//8fc0e283//0//ghc//ghc//inplace//mingw//bin/ld.exe: cannot find -lHSplugin-recompilation-0.1-CPeObcGoBuvHdwBnpK9jQq
collect2.exe: error: ld returned 1 exit status
`gcc.exe' failed in phase `Linker'. (Exit code: 1)
make[2]: *** [Makefile:112: plugin-recomp-change] Error 1
*** unexpected failure for plugin-recomp-change(normal)
```
It's unclear whether the ghc-pkg concurrency issue mentioned in all.T is
the culprit but the set of tests that fail overlaps strongly with the
set of tests that lack the `multi_cpu_race` modifier. Let's see if
adding it fixes them.
|
| |
|
|
|
| |
There seems to be some filepath funniness due to TH embedding going on
here. See #16389.
|
| |
|
|
| |
It seems to look for some sort of manifest file. See #16388.
|
| |
|
|
| |
See #16387.
|
| |
|
|
|
| |
Broke as -Wimplicit-kind-vars no longer exists. Specifically ghci024,
ghci057 and T9293.
|
| |
|
|
| |
See #16386.
|
| | |
|
| |
|
|
|
|
|
| |
The extra-constraints wildcard had lost its location
(issue #16431).
Happily this is easy to fix. Lots of error improvements.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue #16418 showed that we were carrying on too eagerly after a bogus
type signature was identified (a bad telescope in fact), leading to a
subsequent crash.
This led me in to a maze of twisty little passages in the typechecker's
error recovery, and I ended up doing some refactoring in TcRnMonad.
Some specfifics
* TcRnMonad.try_m is now called attemptM.
* I switched the order of the result pair in tryTc,
to make it consistent with other similar functions.
* The actual exception used in the Tc monad is irrelevant so,
to avoid polluting type signatures, I made tcTryM, a simple
wrapper around tryM, and used it.
The more important changes are in
* TcSimplify.captureTopConstraints, where we should have been calling
simplifyTop rather than reportUnsolved, so that levity defaulting
takes place properly.
* TcUnify.emitResidualTvConstraint, where we need to set the correct
status for a new implication constraint. (Previously we ended up
with an Insoluble constraint wrapped in an Unsolved implication,
which meant that insolubleWC gave the wrong answer.
|
| |
|
|
| |
This addresses issue #16427. An easy fix.
|
| |
|
|
|
| |
This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GHCi debugger has never been that robust in the face of
higher-rank types, or even types that are _interally_ higher-rank,
such as the types of many class methods (e.g., `fmap`). In GHC 8.2,
however, things became even worse, as the debugger would start to
_panic_ when a user tries passing the name of a higher-rank thing
to `:print`. This all ties back to a strange `isUnliftedType` check
in `Debugger` that was mysteriously added 11 years ago
(in commit 4d71f5ee6dbbfedb4a55767e4375f4c0aadf70bb) with no
explanation whatsoever.
After some experimentation, no one is quite sure what this
`isUnliftedType` check is actually accomplishing. The test suite
still passes if it's removed, and I am unable to observe any
differences in debugger before even with data types that _do_ have
fields of unlifted types (e.g., `data T = MkT Int#`). Given that
this is actively causing problems (see #14828), the prudent thing
to do seems to be just removing this `isUnliftedType` check, and
waiting to see if anyone shouts about it. This patch accomplishes
just that.
Note that this patch fix the underlying issues behind #14828, as the
debugger will still print unhelpful info if you try this:
```
λ> f :: (forall a. a -> a) -> b -> b; f g x = g x
λ> :print f
f = (_t1::t1)
```
But fixing this will require much more work, so let's start with the
simple stuff for now.
|
| | |
|
| |
|
|
|
|
|
|
| |
The `dataConCannotMatch` function (which powers the
`-Wpartial-fields` warning, among other things) had special reasoning
for explicit equality constraints of the form `a ~ b`, but it did
not extend that reasoning to `a ~~ b` constraints, leading to #16411.
Easily fixed.
|
| |
|
|
| |
See #15382.
|
| |
|
|
|
|
| |
Commit 1f5cc9dc8aeeafa439d6d12c3c4565ada524b926 ended up
fixing #16347. Let's add a regression test to ensure that it stays
fixed.
|
| |
|
|
|
|
|
|
|
|
| |
Code in TcErrors was recursively using immSuperClasses,
which loops in the presence of UndecidableSuperClasses.
Better to use transSuperClasses instead, which has a loop-breaker
mechanism built in.
Fixes issue #16414.
|
| |
|
|
| |
It no longer gives a warning.
|
| |
|
|
|
|
|
|
|
| |
Prevents some tests from failing just due to mismatched version numbers.
These version numbers shouldn't cause tests to fail, especially since
we *expect* them to be regularly incremented. The motivation for this
particular set of changes came from the changes that came along with
the `base` version bump in 8f19ecc95fbaf2cc977531d721085d8441dc09b7.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, our test did something like this:
1. Typecheck p
2. Typecheck q (which made use of an instantiated p)
3. Build instantiated p
4. Build instantiated q
Cabal previously permitted this, under the reasoning that during
typechecking there's no harm in using the instantiated p even if we
haven't build it yet; we'll just instantiate it on the fly with p.
However, this is not true! If q makes use of a Template Haskell
splice from p, we absolutely must have built the instantiated p
before we typecheck q, since this typechecking will need to
run some splices. Cabal now complains that you haven't done
it correctly, which we indeed have not!
Reordering so that we do this:
1. Typecheck p
3. Build instantiated p
2. Typecheck q (which made use of an instantiated p)
4. Build instantiated q
Fixes the problem. If Cabal had managed the ordering itself, it would
have gotten it right.
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch GHC was trying to be too clever
(Trac #16344); it succeeded in kind-checking this
polymorphic-recursive declaration
data T ka (a::ka) b
= MkT (T Type Int Bool)
(T (Type -> Type) Maybe Bool)
As Note [No polymorphic recursion] discusses, the "solution" was
horribly fragile. So this patch deletes the key lines in
TcHsType, and a wodge of supporting stuff in the renamer.
There were two regressions, both the same: a closed type family
decl like this (T12785b) does not have a CUSK:
type family Payload (n :: Peano) (s :: HTree n x) where
Payload Z (Point a) = a
Payload (S n) (a `Branch` stru) = a
To kind-check the equations we need a dependent kind for
Payload, and we don't get that any more. Solution: make it
a CUSK by giving the result kind -- probably a good thing anyway.
The other case (T12442) was very similar: a close type family
declaration without a CUSK.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC represents String literals as ByteString internally for efficiency
reasons. However, until now it wasn't possible to efficiently create
large string literals with TH (e.g. to embed a file in a binary, cf #14741):
TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack
into a ByteString.
This patch adds the possibility to efficiently create a "string" literal
from raw bytes. We get the following compile times for different sizes
of TH created literals:
|| Size || Before || After || Gain ||
|| 30K || 2.307s || 2.299 || 0% ||
|| 3M || 3.073s || 2.400s || 21% ||
|| 30M || 8.517s || 3.390s || 60% ||
Ticket #14741 can be fixed if the original code uses this new TH feature.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #16376 showed the danger of failing to report an error
that exists only in the unsolved constraints, if an exception
is raised (via failM).
Well, the commit 5c1f268e (Fail fast in solveLocalEqualities)
did just that -- i.e. it found errors in the constraints, and
called failM to avoid a misleading cascade.
So we need to be sure to call captureTopConstraints to report
those insolubles. This was wrong in TcRnDriver.tcRnExpr and
in TcRnDriver.tcRnType.
As a result the error messages from test T13466 improved slightly,
a happy outcome.
|
| |
|
|
|
| |
Also, replace some tabs with spaces to avoid a "mixed indent" warning that vim
gives me.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #10069 revealed that small NOINLINE functions didn't get split
into worker and wrapper. This was due to `certainlyWillInline`
saying that any unfoldings with a guidance of `UnfWhen` inline
unconditionally. That isn't the case for NOINLINE functions, so we
catch this case earlier now.
Nofib results:
--------------------------------------------------------------------------------
Program Allocs Instrs
--------------------------------------------------------------------------------
fannkuch-redux -0.3% 0.0%
gg +0.0% +0.1%
maillist -0.2% -0.2%
minimax 0.0% -0.8%
--------------------------------------------------------------------------------
Min -0.3% -0.8%
Max +0.0% +0.1%
Geometric Mean -0.0% -0.0%
Fixes #10069.
-------------------------
Metric Increase:
T9233
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The type-variables-escaping-their-scope-via-kinds check in
`TcValidity` was failing to properly expand type synonyms, which led
to #16391. This is easily fixed by using `occCheckExpand` before
performing the validity check.
Along the way, I refactored this check out into its own function,
and sprinkled references to Notes to better explain all of the moving
parts. Many thanks to @simonpj for the suggestions.
Bumps the haddock submodule.
|
| |
|
|
|
|
|
|
|
| |
We revert CAFs when loading/adding modules in ghci (presumably to refresh
execution states and to allow for object code to be unloaded from the runtime).
However, with `-fexternal-interpreter` enabled, we are only doing it in the
ghci process instead of the external interpreter process where the cafs are
allocated and computed. This makes sure that revertCAFs is done in the
appropriate process no matter if that flag is present or not.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Now since we have been a bit more stringent in testsuite cleanliness we
have been marking a lot of tests as fragile using the `skip` modifier.
However, this unfortunately means that we lose the association with the
ticket number documenting the fragility.
Here we introduce `fragile` and `fragile_for` to retain this
information.
|
| |
|
|
|
|
|
|
|
| |
`instance forall c. c` claimed that `c` was out of scope because the
renamer was invoking `lookupGlobalOcc` on `c` (in
`RnNames.getLocalNonValBinders`) without binding `c` first. To avoid
this, this patch changes GHC to invoke `lookupGlobalOcc_maybe` on `c`
instead, and if that returns `Nothing`, then bail out, resulting
in a better error message.
|
| |
|
|
|
|
|
|
| |
The test case in #15918 no longer triggers an `ASSERT` failure on
GHC HEAD, likely due to commit
682783828275cca5fd8bf5be5b52054c75e0e22c (`Make a smart mkAppTyM`).
This patch adds a regression test for #15918 to finally put it to
rest.
|
| |
|
|
|
|
|
|
| |
This addresses Trac #16208 by marking newtype wrapper
unfoldings as compulsory.
Furthermore, we can remove the special case for newtypes
in exprIsConApp_maybe (introduced in 7833cf407d1f).
|
| |
|
|
|
|
| |
expected changes on the current commit.
Trac #16359
|
