| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
By separating these two lines, if the first command fails then `ghci` is
not loaded. Before it would still load ghci but display lots of errors
about not being able to find modules.
|
| |
|
|
|
| |
ghci always exits with exit code 0 so you have to check the output
to see if the modules loaded succesfully.
|
| |
|
|
|
|
|
| |
Adds the mention that extensions "AllowAmbiguousTypes" and "RankNTypes"
are not always compatible with each other.
Specifies the conditions and causes of failing in resolving
of ambiguity.
|
| |
|
| |
They are broken and I don't have time to fix them at the moment.
|
| |
|
|
|
| |
`git fetch`, which we used previously, doesn't update the remote
tracking branches.
|
| |
|
|
|
|
|
| |
Previously we would use the local branch with the name
`$CI_MERGE_REQUEST_TARGET_BRANCH_NAME` to compute the merge base when
linting. However, this branch isn't necessarily up-to-date. We should
rather use `origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME`.
|
| | |
|
| |
|
|
|
| |
I'm not sure why these steps were done but they seem counterproductive
and unnecessary.
|
| |
|
|
|
|
| |
As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail
Coauthored-by: Ben Gamari <ben@well-typed.com>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This depends on the windows build which is still allowed to fail. If
that job fails then the packaging job will also fail.
|
| |
|
|
| |
Due to https://github.com/haskell/cabal/issues/5953.
|
| |
|
|
|
|
|
|
|
| |
Otherwise configure fails in the 32-bit case with
```
This GHC (c:/GitLabRunner/builds/8fc0e283/0/ghc/ghc/toolchain/bin/ghc) does not generate code for the build platform
GHC target platform : x86_64-unknown-mingw32
Desired build platform : i386-unknown-mingw32
```
|
| | |
|
| |
|
|
|
|
| |
It seems that it has failed to execute at all since it was implemented.
We now run the linters on merge requests.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
!301 removed the `HsArrApp` and `HsArrForm` constructors, which
renders the corresponding extension points `XArrApp` and `XArrForm`
useless. This patch finally rips them out.
|
| |
|
|
|
|
|
| |
As noted in #16466, `System.Environment.getExecutablePath` depends upon
`PathFileExistsW` which is defined by `shlwapi`.
Fixes #16466.
|
| | |
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The `build` stage is meant to be a minimal smoke test to weed out broken
commits. The `validate-x86_64-linux-deb9` build will generally catch a
subset of issues caught by `validate-x86_64-linux-deb9-debug` so only
the latter should be in `build`.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
As described in #16387, this is already defined by mingw and
consequently defining it in the RTS as well leads to multiple definition
errors from the RTS linker at runtime.
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
To install lndir and un-break the source distribution job.
|
