| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
In !980 Richard noted that he could not approve the MR.
This mis-spelling was the reason.
[skip ci]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following the discussion under #16473, this change allows the
specializer to work on any dicts in a lambda, not just those that occur
at the beginning.
For example, if you use data types which contain dictionaries and
higher-rank functions then once these are erased by the optimiser you
end up with functions such as:
```
go_s4K9
Int#
-> forall (m :: * -> *).
Monad m =>
(forall x. Union '[State (Sum Int)] x -> m x) -> m ()
```
The dictionary argument is after the Int# value argument, this patch
allows `go` to be specialised.
|
|
|
|
|
|
|
|
| |
Libffi is ultimately built from a single archive file (e.g.
libffi-tarballs/libffi-3.99999+git20171002+77e130c.tar.gz).
The file can be seen as the shallow dependency for the whole
libffi build. Hence, in all libffi rules, the archive is
`need`ed and the build directory is `trackAllow`ed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit splits out a subset of GhcException which do not depend on
pretty printing (SDoc), as a new datatype called
PlainGhcException. These exceptions can be caught as GhcException,
because 'fromException' will convert them.
The motivation for this change is that that the Panic module
transitively depends on many modules, primarily due to pretty printing
code. It's on the order of about 130 modules. This large set of
dependencies has a few implications:
1. To avoid cycles / use of boot files, these dependencies cannot
throw GhcException.
2. There are some utility modules that use UnboxedTuples and also use
`panic`. This means that when loading GHC into GHCi, about 130
additional modules would need to be compiled instead of
interpreted. Splitting the non-pprint exception throwing into a new
module resolves this issue. See #13101
|
|
|
|
|
|
|
|
|
|
|
| |
15-tuple" #16688
Metrics increased on commit 5eb9445444c4099fc9ee0803ba45db390900a80f and
decreased on revert commit 535a26c90f458801aeb1e941a3f541200d171e8f.
Metric Decrease:
T9630
haddock.base
|
|
|
|
|
|
|
|
| |
* Tweak the parser to allow `deriving` clauses to mention explicit
`forall`s or kind signatures without gratuitous parentheses.
(This fixes #14332 as a consequence.)
* Allow Haddock comments on `deriving` clauses with explicit
`forall`s. This requires corresponding changes in Haddock.
|
|
|
|
| |
This fixes #16586, see `Note [NOINLINE someNatVal]` for details.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the '--hadrian' flag is passed to the validate script, we use hadrian
to build GHC, package it up in a binary distribution and later on run GHC's
testsuite against the said bindist, which gets installed locally in the process.
Along the way, this commit fixes a typo, an omission (build iserv binaries
before producing the bindist archive) and moves the Makefile that enables
'make install' on those bindists from being a list of strings in the code to
an actual file (it was becoming increasingly annoying to work with).
Finally, the Settings.Builders.Ghc part of this patch is necessary for being
able to use the installed binary distribution, in 'validate'.
|
|
|
|
|
|
| |
This reverts commit 5eb9445444c4099fc9ee0803ba45db390900a80f.
It has caused an increase in variance of performance test T9630,
causing CI to fail.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Associated type family default declarations behave strangely in a
couple of ways:
1. If one tries to bind the type variables with an explicit `forall`,
the `forall`'d part will simply be ignored. (#16110)
2. One cannot use visible kind application syntax on the left-hand
sides of associated default equations, unlike every other form
of type family equation. (#16356)
Both of these issues have a common solution. Instead of using
`LHsQTyVars` to represent the left-hand side arguments of an
associated default equation, we instead use `HsTyPats`, which is what
other forms of type family equations use. In particular, here are
some highlights of this patch:
* `FamEqn` is no longer parameterized by a `pats` type variable, as
the `feqn_pats` field is now always `HsTyPats`.
* The new design for `FamEqn` in chronicled in
`Note [Type family instance declarations in HsSyn]`.
* `TyFamDefltEqn` now becomes the same thing as `TyFamInstEqn`. This
means that many of `TyFamDefltEqn`'s code paths can now reuse the
code paths for `TyFamInstEqn`, resulting in substantial
simplifications to various parts of the code dealing with
associated type family defaults.
Fixes #16110 and #16356.
|
|
|
|
|
|
|
|
|
| |
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 e75a9afd2989e0460f9b49fa07c1667299d93ee9 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.
|
| |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
This removes a hack that copies libffi files to the rts
build directory. This was done in a libffi rule, but now
an rts rule correctly needs and copies the relevant
files from the libffi build dir to the rts build dir.
Issues: #16272 #16304
|
|
|
|
| |
Issue #16521
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
|
|
|
|
| |
Metric Decrease:
T9630
|
|
|
|
|
|
| |
We attempt to get 75 commit hashes via `git log`, but this only gave 10
hashes in a CI run (see #16662). Better logging may help solve this
error if it occurs again in the future.
|
|
|
|
|
|
| |
This was a bit unclear as we use both one-based and zero-based
tags in GHC.
[skip ci]
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
| |
... "all packages that are currently built as part of the GHC are
defined in src/Packages.hs"
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|