| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
To install lndir and un-break the source distribution job.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The user's guide uses the `ghc-wiki` macro, and substitution rules
are complicated. So I manually edited `.rst` files without sed.
I changed `Commentary/Latedmd` only to a different page.
It is more appropriate as an example.
[ci skip]
|
|
|
|
|
| |
Metric Increase:
haddock.Cabal
|
| |
|
| |
|
| |
|
|
|
|
| |
This ends up being much easier to use than Debian 9 under NixOS.
|
| |
|
|
|
|
|
|
| |
See #13101 + #15454 for motivation. This change reduces the number of
modules that need to be compiled to object code when loading GHC into
GHCi.
|
|
|
|
|
|
| |
This function allows the user to compute the (non-transitive) size of a
heap object in words. The "closure" in the name is admittedly confusing
but we are stuck with this nomenclature at this point.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
As discussed in #16450, this feature regresses CI on Windows, causing
non-deterministic failures due to missing files.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We make liveness information for global registers
available on `JMP` and `BCTR`, which were the last instructions
missing. With complete liveness information we do not need to
reserve global registers in `freeReg` anymore. Moreover we
assign R9 and R10 to callee saves registers.
Cleanup by removing `Reg_Su`, which was unused, from `freeReg`
and removing unused register definitions.
The calculation of the number of floating point registers is too
conservative. Just follow X86 and specify the constants directly.
Overall on PowerPC this results in 0.3 % smaller code size in nofib
while runtime is slightly better in some tests.
|
|
|
|
| |
This addresses issue #16427. An easy fix.
|
|
|
|
|
| |
This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.
|
|
|
|
| |
[skip ci]
|
|
|
|
| |
Issue #12770
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
With all the recent fixes to the binary-dist rule in Hadrian, we can now run
that rule in CI and keep the bindists around in gitlab as artifacts, just like
we do for the make CI jobs.
To get 'autoreconf' to work in the Windows CI, we have to run it through the
shell interpreter, so this commit does that along the way.
|
|
|
|
| |
See #15382.
|
| |
|
| |
|
|
|
|
|
|
| |
Commit 1f5cc9dc8aeeafa439d6d12c3c4565ada524b926 ended up
fixing #16347. Let's add a regression test to ensure that it stays
fixed.
|
|
|
|
| |
Also remove unused arg from get_Regtable_addr_from_offset
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
This is a separate build job to the other hadrian jobs as it only takes
about 2-3 minutes to run from cold. The CI tests that the
`./hadrian/ghci` script loads `ghc/Main.hs` successfully.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running the `./hadrian/ghci` target will load the main compiler into
a ghci session. This is intended for fast development feedback, modules are only
typechecked so it isn't possible to run any functions in the repl.
You can also use this target with `ghcid`.
The first time this command is run hadrian will need to compile a few dependencies
which will take 1-2 minutes. Loading GHC into GHCi itself takes about 30 seconds.
Internally this works by calling a new hadrian target called `tool-args`.
This target prints out the package and include flags which are necessary
to load files into ghci. The same target is intended to be used by other
tooling which uses the GHC API in order to set up the correct GHC API
session. For example, using this target it is also possible to use HIE
when developing on GHC.
|
|
|
|
|
|
| |
After being copied all the shared objects end up in the same directory.
Therefore the correct rpath is `$ORIGIN` rather than the computed
path which is relative to the directory where it is built.
|