| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
| |
As #23024 showed, in GHC.Core.Opt.Specialise.specImports, we were
generating specialisations (a locally-define function) for imported
functions; and then generating specialisations for those
locally-defined functions. The RULE for the latter should be
attached to the local Id, not put in the rules-for-imported-ids
set.
Fix is easy; similar to what happens in GHC.HsToCore.addExportFlagsAndRules
|
| |
|
|
|
|
|
| |
hs_cmpxchg64 must return a StgWord64, otherwise incorrect runtime
results of 64-bit MO_Cmpxchg will appear in 32-bit unregisterised
builds, which go unnoticed at compile-time due to C implicit casting
in .hc files.
|
| |
|
|
| |
See #22520
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using incoherent instances, there can be situations where two
occurrences of the same overloaded function at the same type use two
different instances (see #22448). For incoherently resolved instances,
we must mark them with `nospec` to avoid the specialiser rewriting one
to the other. This marking is done during the desugaring of the
`WpEvApp` wrapper.
Fixes #22448
Metric Increase:
T15304
|
| | |
|
| |
|
|
|
|
|
|
| |
As #23012 showed, GHC.Core.Opt.Simplify.Utils.prepareAlts was
using an OutType to construct an InAlt. When shadowing is in play,
this is outright wrong.
See Note [Shadowing in prepareAlts].
|
| |
|
|
|
|
|
|
|
| |
This patch makes it so vars from one block of a parallel list
comprehension are not in scope in a subsequent block during type
checking. This was causing GHC to emit a faulty suggestion when an out
of scope variable shared the occ name of a var from a different block.
Fixes #22940
|
| |
|
|
|
|
| |
This significantly cuts down on the amount of
noise in the job log.
Addresses #22861.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Don't use BigInt for wordAdd2, mulWord32, and timesInt32.
Co-authored-by: Matthew Craven <5086-clyring@users.noreply.gitlab.haskell.org>
|
| |
|
|
|
|
|
|
|
| |
This patch updates the warning message introduced in commit
9fb4ca89bff9873e5f6a6849fa22a349c94deaae to specify an explicit
migration timeline: GHC will no longer support this constraint solving
mechanism starting from GHC 9.10.
Fixes #22912
|
| |
|
|
|
|
|
|
|
| |
This commit also adds a new -Dk RTS option to the debug RTS to assist
debugging continuation captures. Currently, the printed information is
quite minimal, but more can be added in the future if it proves to be
useful when debugging future issues.
fixes #23001
|
| | |
|
| |
|
|
|
|
|
| |
Closes #23008
Additionally batches some fixes to pointers to the Note [Wired-in units],
and a typo in said note.
|
| |
|
|
| |
Fixes #22708
|
| |
|
|
|
|
|
|
|
| |
This patch changes the pointer-equality comparison operations in
GHC.Prim.PtrEq to work with arrays of unlifted values, e.g.
sameArray# :: forall {l} (a :: TYPE (BoxedRep l)). Array# a -> Array# a -> Int#
Fixes #22976
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements GHC proposal 496, which allows record wildcards
to be used for nullary constructors, e.g.
data A = MkA1 | MkA2 { fld1 :: Int }
f :: A -> Int
f (MkA1 {..}) = 0
f (MkA2 {..}) = fld1
To achieve this, we add arity information to the record field
environment, so that we can accept a constructor which has no fields
while continuing to reject non-record constructors with more than 1
field. See Note [Nullary constructors and empty record wildcards],
as well as the more general overview in Note [Local constructor info in the renamer],
both in the newly introduced GHC.Types.ConInfo module.
Fixes #22161
|
| | |
|
| |
|
|
|
| |
We don't want to allow users to conjure up values of a `type data` type using
`tagToEnum#`, as these simply don't exist at the value level.
|
| |
|
|
|
|
|
| |
The data constructors for a `type data` declaration don't exist at the value
level, so we don't want GHC to warn users to match on them.
Fixes #22964.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Data constructor wrappers only make sense for _value_-level data constructors,
but data constructors for `type data` declarations only exist at the _type_
level. This patch does the following:
* The criteria in `GHC.Types.Id.Make.mkDataConRep` for whether a data
constructor receives a wrapper now consider whether or not its parent data
type was declared with `type data`, omitting a wrapper if this is the case.
* Now that `type data` data constructors no longer receive wrappers, there is a
spot of code in `refineDefaultAlt` that panics when it encounters a value
headed by a `type data` type constructor. I've fixed this with a special case
in `refineDefaultAlt` and expanded `Note [Refine DEFAULT case alternatives]`
to explain why we do this.
Fixes #22948.
|
| |
|
|
|
|
| |
Because of #20791, the plugins tests often fail. This is a temporary
fix to stop the tests from failing due to unflushed outputs on windows
and the explicit flush should be removed when #20791 is fixed.
|
| |
|
|
| |
Fixes #22376.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
register mapping
The wasm NCG used to map CCCS to a wasm global, based on the
observation that CCCS is a transient register that's already handled
by thread state load/store logic, so it doesn't need to be backed by
the rCCCS field in the register table.
Unfortunately, this is wrong, since even when Cmm execution hasn't
yielded back to the scheduler, the Cmm code may call enterFunCCS,
which does use rCCCS.
This breaks cost centre profiling in a subtle way, resulting in
inaccurate stack traces in some test cases. The fix is simple though:
just remove the CCCS mapping.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It wasn't behaving right when inst_final=False, and the
function had no type variables
f :: Foo => Int
Rather a corner case, but we might as well do it right.
Fixes #22908
Unexpectedly, three test cases (all using :type in GHCi) got
slightly better output as a result:
T17403, T14796, T12447
|
| |
|
|
|
|
|
|
|
|
| |
`libiserv` serves no purpose. As it depends on `ghci` and doesn't have
more dependencies than the `ghci` package, its code could live in the
`ghci` package too.
This commit also moves most of the code from the `iserv` program into
the `ghci` package as well so that it can be reused. This is especially
useful for the implementation of TH for the JS backend (#22261, !9779).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
These functions are
* recursive
* overloaded
So it's important to add an `INLINABLE` pragma to each so that they can be
specialised at the use site when the specific numeric type is known.
Adding these pragmas improves the LazyText replicate benchmark (see https://gitlab.haskell.org/ghc/ghc/-/issues/22886#note_481020)
https://github.com/haskell/core-libraries-committee/issues/129
|
| |
|
|
|
|
| |
Prefer to use the Ubuntu 20.04 and 18.04 binary distributions on Ubuntu
and Linux Mint. Prefer to use the Rocky 8 binary distribution on
unknown distributions.
|
| |
|
|
| |
Add the released testsuite tarball to the generated ghcup metadata.
|
| |
|
|
|
|
|
|
|
|
|
| |
We were failing to expand type synonyms in the function
GHC.Core.RoughMap.typeToRoughMatchLookupTc, even though the
RoughMap infrastructure crucially relies on type synonym expansion
to work.
This patch adds the missing type-synonym expansion.
Fixes #22985
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
generalCategory contains a huge literal string but is marked INLINE,
this will duplicate the string into any use site of generalCategory. In
particular generalCategory is used in functions like isSpace and the
literal gets inlined into this function which makes it massive.
https://github.com/haskell/core-libraries-committee/issues/130
Fixes #22949
-------------------------
Metric Decrease:
T4029
T18304
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Commit cfc8e2e2 introduced a mechanism for handling of exceptions
that occur during Handle finalization, and 372cf730 set the default
handler to print out the error to stderr.
However, #21680 pointed out we might not want to set this by default,
as it might pollute users' terminals with unwanted information.
So, for the time being, the default handler discards the exception.
Fixes #21680
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following #22924 this patch narrows the test that stops
us decomposing newtypes. The key change is the use of
noGivenNewtypeReprEqs in GHC.Tc.Solver.Canonical.canTyConApp.
We went to and fro on the solution, as you can see in #22924.
The result is carefully documented in
Note [Decomoposing newtype equalities]
On the way I had revert most of
commit 3e827c3f74ef76d90d79ab6c4e71aa954a1a6b90
Author: Richard Eisenberg <rae@cs.brynmawr.edu>
Date: Mon Dec 5 10:14:02 2022 -0500
Do newtype unwrapping in the canonicaliser and rewriter
See Note [Unwrap newtypes first], which has the details.
It turns out that
(a) 3e827c3f makes GHC behave worse on some recursive newtypes
(see one of the tests on this commit)
(b) the finer-grained test (namely noGivenNewtypeReprEqs) renders
3e827c3f unnecessary
|
| |
|
|
| |
Fixes #22883.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
See #22970.
|
