| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
This requires bumping the `exceptions` and `text` submodules to bring in
commits that bump their respective upper version bounds on `template-haskell`.
Fixes #19083.
|
| | |
|
| |
|
|
| |
(cherry picked from commit 4f334120c8e9cc4aefcbf11d99f169f648af9fde)
|
| |
|
|
|
| |
Currently we are suffering from issues that appear to be
caused by non-hermetic builds. Try avoiding this by setting
`GIT_STRATEGY` to `clone`.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
It seems like I imported "GHC.Types ()" thinking that it would
transitively import GHC.Num.Integer when I wrote that module; but it
doesn't.
This led to build failures.
See https://mail.haskell.org/pipermail/ghc-devs/2021-March/019641.html
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All credit to @hsyl20, who in
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717#note_338560
figured out this was a problem.
To fix this, we use casts in addition to the shrinking and suffixing
that is already done. It might make for more verbose code, I don't think
that matters too much.
In the future, perhaps some of the shrinking and suffixing can be
removed for being redundant. That proved less trivial than it sounds, so
this wasn't done at this time.
Progress towards #19026
Metric Increase:
T12707
T13379
Co-authored-by: Sylvain Henry <hsyl20@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's quite backend-dependent whether we will actually handle that case
right, so let's just always do this as a precaution.
In particular, once we replace the native primops used here with the new
sized primops, the 16-bit ones on x86 will begin to use 16-bit sized
instructions where they didn't before.
Though I'm not sure of any arch which has 8-bit scalar instructions, I
also did those for consistency. Plus, there are *vector* 8-bit ops in
the wild, so if we ever got into autovectorization or something maybe
it's prudent to put this here as a reminder not to forget about
catching overflows.
Progress towards #19026
|
| |
|
|
|
|
|
|
| |
As #19522 points out, we did not account for visible type
application when trying to reject naked levity-polymorphic
functions that have no binding.
This patch tidies up the code, and fixes the bug too.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While fixing #19232, it became increasingly clear that the vestigial
hack described in `Note [Optimistic field binder CPR]` is complicated
and causes reboxing. Rather than make the hack worse, this patch
gets rid of it completely in favor of giving deeply unboxed parameters
the Nested CPR property. Example:
```hs
f :: (Int, Int) -> Int
f p = case p of
(x, y) | x == y = x
| otherwise = y
```
Based on `p`'s `idDemandInfo` `1P(1P(L),1P(L))`, we can see that both
fields of `p` will be available unboxed. As a result, we give `p` the
nested CPR property `1(1,1)`. When analysing the `case`, the field
CPRs are transferred to the binders `x` and `y`, respectively, so that
we ultimately give `f` the CPR property.
I took the liberty to do a bit of refactoring:
- I renamed `CprResult` ("Constructed product result result") to plain
`Cpr`.
- I Introduced `FlatConCpr` in addition to (now nested) `ConCpr` and
and according pattern synonym that rewrites flat `ConCpr` to
`FlatConCpr`s, purely for compiler perf reasons.
- Similarly for performance reasons, we now store binders with a
Top signature in a separate `IntSet`,
see `Note [Efficient Top sigs in SigEnv]`.
- I moved a bit of stuff around in `GHC.Core.Opt.WorkWrap.Utils` and
introduced `UnboxingDecision` to replace the `Maybe DataConPatContext`
type we used to return from `wantToUnbox`.
- Since the `Outputable Cpr` instance changed anyway, I removed the
leading `m` which we used to emit for `ConCpr`. It's just noise,
especially now that we may output nested CPRs.
Fixes #19398.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit reduces allocations by the simplifier by 3% for the
Cabal test at -O2.
We do this by making a few select fields, bindings and arguments strict
which reduces allocations for the simplifier by around 3% in total
for the Cabal test. Which is about 2% fewer allocations in total at
-O2.
-------------------------
Metric Decrease:
T18698a
T18698b
T9233
T9675
T9872a
T9872b
T9872c
T9872d
T10421
T12425
T13253
T5321FD
T9961
-------------------------
|
| |
|
|
|
|
| |
tuples and sums.
fixes #1257
|
| |
|
|
|
| |
Metric Increase:
MultiLayerModules
|
| | |
|
| |
|
|
|
| |
The 'id' type is now determined by the pass, using the XTickishId
type family.
|
| |
|
|
|
|
|
|
| |
GHCi needs to know the types of all breakpoints, but it's
not possible to get the exprType of any expression in STG.
This is preparation for the upcoming change to make GHCi
bytecode from STG instead of Core.
|
| |
|
|
| |
In the `comments` and `literals` tests, since they contain file paths.
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously we would use `writeFile` to write the intermediate files to
check for round-tripping. However, this will open the output handle as a
text handle, which on Windows will change line endings. Avoid this by
opening as binary.
Explicitly use utf8 encoding.
This is for tests only, do not need to worry about user compatibility.
|
| |
|
|
|
|
|
|
| |
Metric Increase:
T10370
parsing001
Updates haddock submodule
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MR introducing the API Annotations, !2418 is huge.
Conceptually it is two parts, the one deals with introducing the new
types to be used for annotations, and outlining how they will be
used. This is a small change, localised to
compiler/GHC/Parser/Annotation.hs and is contained in this commit.
The follow-up, larger commit deals with mechanically working this
through the entire AST and updating all the parts affected by it.
It is being split so the part that needs good review feedback can be
seen in isolation, prior to the rest coming in.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current documentation for the `Ord` typeclass is inconsistent. It
simultaneously mentions that:
> The 'Ord' class is used for totally ordered datatypes.
And:
> The Haskell Report defines no laws for 'Ord'. However, '<=' is
> customarily expected to implement a non-strict partial order […]
The Haskell report (both 98 and 2010 versions) mentions total ordering,
which implicitly does define laws. Moreover, `compare :: Ord a => a -> a
-> Ordering` and `data Ordering = LT | EQ | GT` imply that the order is
indeed total (there is no way to say that two elements are not
comparable). This MR fixes the Haddock comment, and adds a comparability
law to the list of suggested properties.
|
| |
|
|
|
|
|
|
| |
Currently we have far too many merge failures due to cumulative
performance improvements. Avoid this by accepting metric decreases in
marge-bot jobs.
Fixes #19562.
|
| |
|
|
| |
Allow skipping of only increases/decreases.
|
| |
|
|
|
| |
Co-authored-by: Daniel Rogozin <daniel.rogozin@serokell.io>
Co-authored-by: Rinat Stryungis <rinat.stryungis@serokell.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds some bullet points to the GHC User's Guide section on `GADTs` to
explain some subtleties in how GHC typechecks GADT patterns. In particular,
this adds examples of programs being rejected for matching on GADTs in a way
that does not mesh with GHC's left-to-right, outside-in order for checking
patterns, which can result in programs being rejected for seemingly
counterintuitive reasons. (See #12018 for examples of confusion that arose
from this.) In addition, now that we have visible type application in data
constructor patterns, I mention a possible workaround of using
`TypeApplications` to repair programs of this sort.
Resolves #12018.
|
| | |
|
| |
|
|
|
|
| |
CmmToAsm.Reg.Linear: More strictness
More strictness
|
| |
|
|
| |
Avoid top-level recursion.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #19194 mpickering detailed that there are a LOT of allocations
of IfaceTyConInfo:
There are just two main cases: IfaceTyConInfo IsPromoted IfaceNormalTyCon
and IfaceTyConInfo NotPromoted IfaceNormalTyCon. These should be made into
CAFs and shared. From my analysis, the most common case is
IfaceTyConInfo NotPromoted IfaceNormalTyCon (53 000)
then IfaceTyConInfo IsPromoted IfaceNormalTyCon (28 000).
This patch makes it so these are properly shared by using a smart
constructor.
Fixes #19194.
|
| |
|
|
|
|
|
|
| |
When we use `withTiming` we need to force the results of each timed pass
to better represent the time spent in each phase. This patch forces
some results that weren't before.
It also retrieve timings for the CoreToStg and WriteIface passes.
|
| |
|
|
|
|
|
| |
Previously we would support only one LLVM major version. Here we
generalize this to accept a range, taking this range to be LLVM 10 to 11,
as 11 is necessary for Apple M1 support. We also accept 12, as that is
what apple ships with BigSur on the M1.
|
| |
|
|
|
|
|
|
| |
integerToFloat# and integerToDouble# were moved from ghc-bignum to base.
GHC.Integer.floatFromInteger and doubleFromInteger were removed.
Fixes #15926, #17231, #17782
|
| | |
|
| |
|
|
| |
This fixes !18744
|
| |
|
|
| |
closes #19362
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
According to the proposal, we have the following equivalence:
e{lbl1 = val1}.val2 == (e{lbl1 = val1}).val2
This is a matter of parsing. Record construction/update must have the
same precedence as dot access.
Add a test case to ensure this.
|
| |
|
|
|
| |
By moving the handling of TIGHT_INFIX_PROJ to the correct place,
we can remove the isGetField hack and fix a bug at the same time.
|
| |
|
|
|
|
|
|
|
| |
StandaloneKindSignatures
This documents a limitation of `StandaloneKindSignatures`—namely, that it
does not bring type variables bound by an outermost `forall` into scope over
a type-level declaration—in the GHC User's Guide. See #19498 for more
discussion.
|
| | |
|
| | |
|
| |
|
|
| |
This means it will be reposted everytime the eventlog is started.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes `guessConLikeUnivTyArgsFromResTy` consider required
Thetas of PatSynCons, by treating them as Wanted constraints to be
discharged with the constraints from the Nabla's TyState and saying
"does not match the match type" if the Wanted constraints are unsoluble.
It calls out into a new function `GHC.Tc.Solver.tcCheckWanteds` to do
so.
In pushing the failure logic around call sites of `initTcDsForSolver`
inside it by panicking, I realised that there was a bunch of dead code
surrounding `pmTopMoraliseType`: I was successfully able to delete the
`NoChange` data constructor of `TopNormaliseTypeResult`.
The details are in `Note [Matching against a ConLike result type]` and
`Note [Instantiating a ConLike].
The regression test is in `T19475`. It's pretty much a fork of `T14422`
at the moment.
Co-authored-by: Cale Gibbard <cgibbard@gmail.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC Proposal: 0265-unlifted-datatypes.rst
Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/265
Issues: https://gitlab.haskell.org/ghc/ghc/-/issues/19523
Implementation Details: Note [Implementation of UnliftedDatatypes]
This patch introduces the `UnliftedDatatypes` extension. When this extension is
enabled, GHC relaxes the restrictions around what result kinds are allowed in
data declarations. This allows data types for which an unlifted or
levity-polymorphic result kind is inferred.
The most significant changes are in `GHC.Tc.TyCl`, where
`Note [Implementation of UnliftedDatatypes]` describes the details of the
implementation.
Fixes #19523.
|
| | |
|
