- Mar 23, 2019
-
-
Ben Gamari authored
-
- Mar 22, 2019
-
-
Ben Gamari authored
When computing the merge base for the linters don't rely on the target branch name as this is rather fragile. Instead we can just use `$CI_MERGE_REQUEST_TARGET_BRANCH_SHA`.
-
Ben Gamari authored
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`.
-
Ben Gamari authored
-
Ben Gamari authored
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>
-
Ben Gamari authored
-
-
-
This depends on the windows build which is still allowed to fail. If that job fails then the packaging job will also fail.
-
-
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.
-
-
- Mar 21, 2019
-
-
-
-
!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.
-
-
- Mar 20, 2019
-
-
-
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.
-
