- Jun 12, 2019
-
-
Ben Gamari authored
(cherry picked from commit 983ada70)
-
-
This fixes a regression, introduced by 67c422ca, where we mprotect'd the global offset table (GOT) region to PROT_READ before we had finished filling it, resulting in a linker crash. Fixes #16779.
-
-
[skip ci]
-
Fixes #15208. [skip ci]
-
- Jun 11, 2019
-
-
Make/shell variable names which contain dashes can cause problems under some conditions. The 'ghc-config-mk' variable from testsuite/mk/boilerplate.mk that I made overridable (by Hadrian) in ba0aed2e was working as expected when our Hadrian/Linux job was based off the deb8 Docker image, but broke when I switched the job to use our deb9-based image, in 3d97bad6. The exact circumstances/tool versions that trigger this problem are unknown, but changing the variable's name to 'ghc_config_mk' lets us work around the issue. This fixes the annth_compunits and annth_make test failures that showed up when we switched the Hadrian/Linux job to use the deb9 environment.
-
-
The PLT needs to be located within a close distance of the code calling it under the small memory model. Fixes #16784.
-
This extends mmapForLinker to use the same low-memory mapping strategy used on x86_64 on AArch64. See #16784.
-
As discussed in #16744, both the Make and Hadrian build systems have special code to always pass -eventlog whenever -prof or -debug are passed. However, there is some similar logic in the RTS itself only for defining TRACING when the DEBUG macro is defined, but no such logic is implemented to define TRACING when the PROFILING macro is defined. This patch adds such a logic and therefore fixes #16744.
-
-
Suppose you've made changes that affect the output of `haddockHtmlTest` so that the following is failing: ./hadrian/build.sh -c --only=haddockHtmlTest test Then, the following will accept new output for Haddock's test cases. ./hadrian/build.sh -c --only=haddockHtmlTest test --test-accept You still do need to make sure those new changes (which show up in Haddock's tree) get committed though. Fixes #16694 -
As discussed in #16331, the GHCI macro, defined through 'ghci' flags in ghc.cabal.in, ghc-bin.cabal.in and ghci.cabal.in, is supposed to indicate whether GHC is built with support for an internal interpreter, that runs in the same process. It is however overloaded in a few places to mean "there is an interpreter available", regardless of whether it's an internal or external interpreter. For the sake of clarity and with the hope of more easily being able to build stage 1 GHCs with external interpreter support, this patch splits the previous GHCI macro into 3 different ones: - HAVE_INTERNAL_INTERPRETER: GHC is built with an internal interpreter - HAVE_EXTERNAL_INTERPRETER: GHC is built with support for external interpreters - HAVE_INTERPRETER: HAVE_INTERNAL_INTERPRETER || HAVE_EXTERNAL_INTERPRETER
-
Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: hvr, simonpj, mpickering, rwbarton, carter GHC Trac Issues: #15838 Differential Revision: https://phabricator.haskell.org/D5285
-
This adds a new test, only run in the `normal` way, to verify the size of FUNs and PAPs.
-
This was previously broken in several ways. This is fixed and it also now tests arrays. Unfortunately I was unable to find a way to continue testing PAP and FUN sizes; these simply depend too much upon the behavior of the simplifier. I also tried to extend this to test non-empty arrays as well but unfortunately this was non-trivial as the array card size constant isn't readily available from haskell. Fixes #16531.
-
Currently the rule for .hi files just triggers (via need) the rule for the .o file, and .o rule generates both the .o and .hi file. Likewise for .o-boot and .hi-boot files. This is a bit of an abuse of Shake, and in fact shake supports rules with multiple output with the &%> function. This exact use case appears in Neil Mitchell's paper *Shake Before Building* section 6.3.
-
-
- Jun 10, 2019
-
-
-
As noted in #16224, CPUTime001 has been quite problematic, reporting non-monotonic timestamps in CI. Unfortunately I've been unable to reproduce this locally.
-
- Jun 09, 2019
-
-
When pop() returns with `*c == NULL` retainerProfile will immediately return. All other code paths is pop() continue with the next stackElement when this happens so it seems weird to me that TREC_CHUNK we would suddenly abort everything even though the stack might still have elements left to process.
-
It shouldn't be needed these days, and those primops are "highly deprecated" anyways. This fits with my plans because it removes one bit of target-dependence of the builtin primops, and this is the hardest part of GHC to make multi-target. CC @carter
-
-
-
-
-
Previously these two orthogonal concerns were both implemented in postHeaderEvents which made it difficult to send header events after RTS initialization.
-
This patch adds two new commands `:enable` and `:disable` to the GHCi debugger. Opposite to `:set stop <n> :continue` a breakpoint disabled with `:disable` will not loose its previously set stop command. A new field breakEnabled is added to the BreakLocation data structure to track the enable/disable state. When a breakpoint is disabled with a `:disable` command, the following happens: The corresponding BreakLocation data element is searched dictionary of the `breaks` field of the GHCiStateMonad. If the break point is found and not already in the disabled state, the breakpoint is removed from bytecode. The BreakLocation data structure is kept in the breaks list and the new breakEnabled field is set to false. The `:enable` command works similar. The breaks field in the GHCiStateMonad was changed from an association list to int `IntMap`.
-
There were actually two bugs fixed here: 1. candidateQTyVarsOfType needs to be careful that it does not try to zap metavariables from an outer scope as "naughty" quantification candidates. This commit adds a simple check to avoid doing so. 2. We weren't bumping the TcLevel in kcHsKindSig, which was used only for class method sigs. This mistake led to the acceptance of class C a where meth :: forall k. Proxy (a :: k) -> () Note that k is *locally* quantified. This patch fixes the problem by using tcClassSigType, which correctly bumps the level. It's a bit inefficient because tcClassSigType does other work, too, but it would be tedious to repeat much of the code there with only a few changes. This version works well and is simple. And, while updating comments, etc., I noticed that tcRnType was missing a pushTcLevel, leading to #16767, which this patch also fixes, by bumping the level. In the refactoring here, I also use solveEqualities. This initially failed ghci/scripts/T15415, but that was fixed by teaching solveEqualities to respect -XPartialTypeSignatures. This patch also cleans up some Notes around error generation that came up in conversation. Test case: typecheck/should_fail/T16517, ghci/scripts/T16767 -
Package DB directories with trailing separator (provided via GHC_PACKAGE_PATH or via -package-db) resulted in incorrect calculation of ${pkgroot} substitution variable. Keep the trailing separator while resolving as directory or file, but remove it before dropping the last path component with takeDirectory. Closes #16360. -
-
-
-
As noted in #16741, this test otherwise breaks when `base` is compiled with `-g`.
-
Previously if you build the `ghc` package then it would has the default opts and the library opts. This is different behaviour to make where the library opts are only reserved for things in the `libraries` subdirectory (I believe) Fixes #16716
-
-
- Jun 08, 2019
-
-
Ben Gamari authored
The previous commit reworked things such that the submodule linter would only run on the head commit. However, the linter only checks the submodules which are touched by the commits it is asked to lint. Consequently it would be possible for a bad submodule to sneak through. Thankfully, we can use the handy CI_COMMIT_BEFORE_SHA attribute to find the base commit of the push.
-
Ben Gamari authored
There is no notion of a base commit when we aren't checking a merge request. Just check the HEAD commit.
-
Ben Gamari authored
Previously we were passing `--unshallow` to `git fetch` in the linting rules to ensure that the base commit which we were linting with respect to was available. However, this breaks due to GitLab's re-use of working directories since `git fetch --unshallow` fails on a repository which is not currently shallow. Given that `git fetch --unshallow` circumvents the efficiencies provided by shallow clones anyways, let's just disable them entirely. There is no documented way to do disable shallow clones but on checking the GitLab implementation it seems that setting `GIT_DEPTH=0` should do the trick.
-
