- Jul 20, 2019
-
-
- Jul 19, 2019
-
-
This was requested in #15650.
-
-
-
-
Ben Gamari authored
As noted in #16909.
-
Ben Gamari authored
Fixed in #14759.
-
Ben Gamari authored
This requires code loading and therefore can't be run in the profiled ways when GHC is dynamically linked.
-
Ben Gamari authored
As noted in #11645 and #8862, forking and profiling don't go well together. Bumps hpc and unix submodules.
-
Ben Gamari authored
-
Ben Gamari authored
-
Ben Gamari authored
Previously it was not marked as broken in profthreaded
-
Ben Gamari authored
As noted in #16914, the value `True` was used instead of `YES` here, in contrast to the other boolean fields emitted by `--info`. This confused the testsuite driver and broke the `ghc_debugged` testsuite predicate.
-
Ben Gamari authored
-
Ben Gamari authored
Otherwise the unique counter starts at 0, causing us to immediately underflow.
-
Ben Gamari authored
See #16803.
-
Ben Gamari authored
This should help identify a few cases where this is throwing warnings
-
Ben Gamari authored
-
Ben Gamari authored
Otherwise we don't compile the stage2 compiler with DEBUG, meaning the testsuite isn't checked with assertions. Metric Increase: haddock.Cabal
-
- Jul 17, 2019
-
-
By not building anything in the dynamic way on Windows, where we don't have a working story for DLLs yet. Also the ghcid command needs to call bash on the hadrian/ghci.sh script explicitly as the path gets interpreted differently otherwise.
-
This prepares the way for making Int32# and Word32# the actual size they claim to be. Updates binary submodule for (de)serializing the new runtime reps.
-
- Jul 16, 2019
-
-
-
Currently initProfiling gets defined by Profiling.c only if PROFILING is defined. Otherwise the ProfHeap.c defines it. This is just needlessly complicated so in this commit I make Profiling and ProfHeap into properly seperate modules and call their respective init functions from RtsStartup.c.
-
Unfortunately this will require more work; register allocation is quite broken. This reverts commit acd79558.
-
Hadrian used to have a separate flag --progress-colour to control colored output during the build. After introduction of a Shake flag with similar purpose Hadrian's flag became redundant. The commit removes --progress-colour and switches to Shake's flag. The only difference between the two is that Hadrian has special default mode when it tries to determine if the terminal support colored output. The user can override it using (Shake's) `--[no-]color`.
-
- Jul 15, 2019
-
-
-
-
Arnaud Spiwack authored
See also the discussion at #16592
-
Ben Gamari authored
-
- Jul 14, 2019
-
-
Found by @lehins.
-
-
These are unexploded minds as far as the linter is concerned. I don't want to hit in my MRs by mistake! I did this with `sed`, and then rolled back some changes in the docs, config.guess, and the linter itself.
-
- docs which document the lint and need to contain the unutterable - vendored code which is outside our purview
-
Instead following @angerman's suggestion put them in the config file. Maybe we could re-key llvm-targets someday, but this is good for now.
-
Since !712 the `settings` file is produced by the build system instead of autoconf. However, this introduced a subtle bug where we would fail to rebuild the `settings` file with what we have learned from the install-time `configure` invocation. Fix this by not packaging `settings` in the bindist tarball. The build system will take care of the rest. Also fix a bug where the value of `UseLibdw` was not being persisted to the install time `configure`.
-
Fixes #16920
-
The compiler doesn't create uses nor compiles the uses that exist specially. These are just plain C-- FFI. These `await*` ones are especially important to so convert because "true" primops are hard to make platform-specific currently. The other exports are part of this commit so this module always exports something, which avoids silly CPP elsewhere. More will be added later once `foreign import prim` is extended.
-