| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This struct has a number of fields and we only care that the value is
initialized with zeros. This eliminates the warnings noted in #17905.
|
|
|
|
| |
Reverts 430f5c84dac1eab550110d543831a70516b5cac8
|
|
|
| |
The `MVar` lock in `Compact` was unnecessarily lazy, creating an extra indirection and wasting two words. Make it strict.
|
|
|
|
|
|
| |
Specifically the "Inline literal start-string without end-string"
warning, which typically means that the user neglected to separate
an inline code block from suffix text with a backslash.
|
| |
|
| |
|
|
|
|
|
|
|
| |
They are parsed as multiples of 1024. Not 1000. The docs
used to imply otherwise.
See decodeSize in rts/RtsFlags.c for the logic for this.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Data.OldList exports a monomorphized singleton function but
it is not re-exported by Data.List. Adding the export to
Data.List causes a conflict with a 14-year old function of the
same name and type by SPJ in GHC.Utils.Misc. We can't just remove
this function because that leads to a problems when building
GHC with a stage0 compiler that does not have singleton in
Data.List yet. We also can't hide the function in GHC.Utils.Misc
since it is not possible to hide a function from a module if the
module does not export the function. To work around this, all
places where the Utils.Misc singleton was used now use a qualified
version like Utils.singleton and in GHC.Utils.Misc we are very
specific about which version we export.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This wires in the definitions of the constraint tuple classes. The
key changes are in:
* `GHC.Builtin.Types`, where the `mk_ctuple` function is used to
define constraint tuple type constructors, data constructors, and
superclass selector functions, and
* `GHC.Builtin.Uniques`. In addition to wiring in the `Unique`s for
constraint tuple type and data constructors, we now must wire in
the superclass selector functions. Luckily, this proves to be not
that challenging. See the newly added comments.
Historical note: constraint tuples used to be wired-in until about
five years ago, when commit 130e93aab220bdf14d08028771f83df210da340b
turned them into known-key names. This was done as part of a larger
refactor to reduce the number of special cases for constraint tuples,
but the commit message notes that the main reason that constraint
tuples were made known-key (as opposed to boxed/unboxed tuples, which
are wired in) is because it was awkward to wire in the superclass
selectors. This commit solves the problem of wiring in superclass
selectors.
Fixes #18635.
-------------------------
Metric Decrease:
T10421
T12150
T12227
T12234
T12425
T13056
T13253-spj
T18282
T18304
T5321FD
T5321Fun
T5837
T9961
Metric Decrease (test_env='x86_64-linux-deb9-unreg-hadrian'):
T12707
Metric Decrease (test_env='x86_64-darwin'):
T4029
-------------------------
|
|
|
|
|
| |
Previously cabal-install wouldn't overwrite toolchain executables if
they already existed (as they likely would due to caching).
|
|
|
|
|
| |
Also, always invoke cabal-install to ensure that happy/alex symlinks are
up-to-date.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Libraries email: https://mail.haskell.org/pipermail/libraries/2018-April/028724.html
GHC issue: https://gitlab.haskell.org/ghc/ghc/issues/15028
Corresponding PRs for deepseq:
* https://github.com/haskell/deepseq/pull/55
* https://github.com/haskell/deepseq/pull/57
Bumps the deepseq submodule.
|
|
|
|
|
|
| |
Previously we would allocate a linked list cell for each foreign export.
Now we can avoid this by taking advantage of the fact that they are
already broken into groups.
|
|
|
|
|
|
|
|
|
| |
This avoids calling `libc` in the initializers which are responsible for
registering foreign exports. We believe this should avoid the corruption
observed in #18548.
See Note [Tracking foreign exports] in rts/ForeignExports.c for an
overview of the new scheme.
|
|
|
|
|
|
| |
When updating a TRec for a TVar already part of a transaction we
previously neglected to add the old value to the update remembered set.
I suspect this was the cause of #18587.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Add a type parameter for the environment required by OutputableP. It
avoids tying Platform with OutputableP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some types need a Platform value to be pretty-printed: CLabel, Cmm
types, instructions, etc.
Before this patch they had an Outputable instance and the Platform value
was obtained via sdocWithDynFlags. It meant that the *renderer* of the
SDoc was responsible of passing the appropriate Platform value (e.g. via
the DynFlags given to showSDoc). It put the burden of passing the
Platform value on the renderer while the generator of the SDoc knows the
Platform it is generating the SDoc for and there is no point passing a
different Platform at rendering time.
With this patch, we introduce a new OutputableP class:
class OutputableP a where
pdoc :: Platform -> a -> SDoc
With this class we still have some polymorphism as we have with `ppr`
(i.e. we can use `pdoc` on a variety of types instead of having a
dedicated `pprXXX` function for each XXX type).
One step closer removing `sdocWithDynFlags` (#10143) and supporting
several platforms (#14335).
|
|
|
|
| |
See #18641 'Documenting the Expected Undocumented Flags'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, we had this parser production:
ftype : ...
| ftype PREFIX_AT tyarg { ... }
And 'tyarg' is defined as follows:
tyarg : atype { ... }
| unpackedness atype { ... }
So one might get the (false) impression that that parser production is
intended to parse things like:
F @{-# UNPACK #-} X
However, the lexer wouldn't produce PREFIX_AT followed by 'unpackedness',
as the '@' operator followed by '{-' is not considered prefix.
Thus there's no point using 'tyarg' after PREFIX_AT,
and a simple 'atype' will suffice:
ftype : ...
| ftype PREFIX_AT atype { ... }
This change has no user-facing consequences. It just makes the grammar a
bit more clear.
|
| |
|
| |
|
|
|
|
|
|
| |
Bumps haskeline and haddock submodules.
(cherry picked from commit f218cfc92f7b1a1e01190851972bb9a0e0f3c682)
|
|
|
|
| |
Also bumps Cabal, directory
|
|
|
|
| |
These slipped through CI.
|
| |
|
|
|
|
| |
Solves #18252
|
| |
|
|
|
|
| |
The --recursive flag of git-clone has been replaced by the
--recurse-submodules flag since git 1.7.4, released in 2011.
|
|
|
|
|
|
|
|
|
| |
Ticket #18638 showed that Very Bad Things happen if we fail
to do absence analysis on stable unfoldings. It's all described
in Note [Absence analysis for stable unfoldings and RULES].
I'm a bit surprised this hasn't bitten us before. Fortunately
the fix is pretty simple.
|
|
|
| |
[skip ci]
|
|
|
|
|
| |
Packages don't have to import both ghc-boot and ghc-boot-th. It makes
the dependency graph easier to understand and to refactor.
|
|
|
|
|
| |
"ghci" as a flag name was confusing because it really enables the
internal-interpreter. Even the ghci library had a "ghci" flag...
|
|
|
|
|
|
|
| |
As pointed out in #18685, this should be snprintf not vsnprintf. This
appears to be due to a cut-and-paste error.
Fixes #18658.
|
|
|
|
|
|
|
| |
Previously, these were omitted from the flag reference due to a
layout oversight in `docs/users_guide/flags.{rst,py}`.
Fixes #18426.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This switches `deriv_clause_tys` so that instead of using a list of
`LHsSigType`s to represent the types in a `deriving` clause, it now
uses a sum type. `DctSingle` represents a `deriving` clause with no
enclosing parentheses, while `DctMulti` represents a clause with
enclosing parentheses. This makes pretty-printing easier and avoids
confusion between `HsParTy` and the enclosing parentheses in
`deriving` clauses, which are different semantically.
Fixes #18662.
|
| |
|
|
|
|
| |
This is useful for `ghcide`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two bugs, #18627 and #18649, had the same cause: we were not
account for the fact that a constaint tuple might hide an implicit
parameter.
The solution is not hard: look for implicit parameters in
superclasses. See Note [Local implicit parameters] in
GHC.Core.Predicate.
Then we use this new function in two places
* The "short-cut solver" in GHC.Tc.Solver.Interact.shortCutSolver
which simply didn't handle implicit parameters properly at all.
This fixes #18627
* The specialiser, which should not specialise on implicit parameters
This fixes #18649
There are some lingering worries (see Note [Local implicit
parameters]) but things are much better.
|
| |
|
| |
|
| |
|
| |
|