- May 22, 2019
-
-
We can specify several of those, by using the flag multiple times or just once but combining the directories with ':'. Along the way, this patch also fixes the testsuite-related --only flag, so that we can use it many times instead of being force to specify a space-separated list of test in a single --only flag.
-
Commit e75a9afd added an `unsigned` cast to account for OSes that have signed `rlim_t` signed. Unfortunately, the `unsigned` cast has the unintended effect of narrowing `rlim_t` to only 4 bytes. This leads to some spurious out of memory crashes (in particular: Haddock crashes with OOM whenn building docs of `ghc`-the-library). In this case, `W_` is a better type to cast to: we know it will be unsigned too and it has the same type as `*len` (so we don't suffer from accidental narrowing).
-
-
See #13101 and #15454
-
The idea is to automatically enable -fobject-code for modules that use UnboxedTuples, along with all the modules they depend on. When looking into how to solve this, I was pleased to find that there was already highly similar logic for enabling code generation when -fno-code is specified but TemplateHaskell is used. The state before this patch was that if you used unboxed tuples then you had to enable `-fobject-code` globally rather than on a per module basis.
-
-
- May 21, 2019
-
-
-
Due to #16574.
-
Most places where we convert contexts in `Convert` are actually in positions that are to the left of some `=>`, such as in superclasses and instance contexts. Accordingly, these contexts need to be parenthesized at `funPrec`. To accomplish this, this patch changes `cvtContext` to require a precedence argument for the purposes of calling `parenthesizeHsContext` and adjusts all `cvtContext` call sites accordingly.
-
Otherwise, when `./configure`ing a GHC bindist, produced by either Make or Hadrian, we would try to generate the `settings` file from the `settings.in` template that we used to have around but which has been gone since d37d91e9. That commit generates the settings file using the build systems instead, but forgot to remove this mention to the `settings` file.
-
-
Doc-only change.
-
-
-
-
The following sections are not displayed due to a directive error: * -Wunused-record-wildcards * -Wredundant-record-wildcards I changed the location of the `since` directive. [skip ci]
-
- May 20, 2019
- May 16, 2019
-
-
Ben Gamari authored
This was a bit unclear as we use both one-based and zero-based tags in GHC. [skip ci]
-
- May 14, 2019
-
-
Alp Mestanogullari authored
Previously, changing one of the .rst files from the user guide would not cause the user guide to be rebuilt. This patch take a first stab at declaring the documentation source files that our documentation rules depend on, focusing on the .rst files only for now. We eventually might want to rebuild docs when we, say, change the haddock style file, but this level of tracking isn't really necessary for now. This fixes #16645.
-
happy-1.19.10 has been released with a fix for --coerce in the presence of higher rank types. This should result in about 10% performance improvement in the parser.
-
GHC Proposal #36 describes a transition plan away from CUSKs and to top-level kind signatures: 1. Introduce a new extension, -XCUSKs, on by default, that detects CUSKs as they currently exist. 2. We turn off the -XCUSKs extension in a few releases and remove it sometime thereafter. This patch implements phase 1 of this plan, introducing a new language extension to control whether CUSKs are enabled. When top-level kind signatures are implemented, we can transition to phase 2.
-
-
Useful progress indicator even when `make test VERBOSE=1`, and when you do something else, but have terminal title visible.
-
1. If GHC is to be multi-target, these cannot be baked in at compile time. 2. Compile-time flags have a higher maintenance than run-time flags. 3. The old way makes build system implementation (various bootstrapping details) with the thing being built. E.g. GHC doesn't need to care about which integer library *will* be used---this is purely a crutch so the build system doesn't need to pass flags later when using that library. 4. Experience with cross compilation in Nixpkgs has shown things work nicer when compiler's can *optionally* delegate the bootstrapping the package manager. The package manager knows the entire end-goal build plan, and thus can make top-down decisions on bootstrapping. GHC can just worry about GHC, not even core library like base and ghc-prim!
-
Can't use this config entry because it's about to go away
-
-
-
- May 13, 2019
-
-
... "all packages that are currently built as part of the GHC are defined in src/Packages.hs"
-
- May 10, 2019
-
-
-
As discussed in the Note, we now have a cron job to handle this and the cleanup job itself is quite fragile. [skip ci]
-
In Hadrian, building programs (e.g. `ghc` or `haddock`) requires libraries located in the ghc-pkg package database i.e. _build/stage1/lib/x86_64-linux-ghc-8.9.0.20190430/libHSdeepseq-1.4.4.0-ghc8.9.0.20190430.so Add the corresponding `need`s for these library files and the subsequent rules. -
-
Why 15? Because we have Eq instances up to 15. Metric Increase: T9630 haddock.base
-
- May 08, 2019
-
-
-
-
-
test: typecheck/should_fail/T16627
-
Continuation to ce23451c
-
-
