[Git][ghc/ghc][wip/T21623] 16 commits: Export liftA2 from Prelude
sheaf (@sheaf)
gitlab at gitlab.haskell.org
Wed Sep 14 00:58:13 UTC 2022
sheaf pushed to branch wip/T21623 at Glasgow Haskell Compiler / GHC
Commits:
77209ab3 by Georgi Lyubenov at 2022-09-08T17:14:36+03:00
Export liftA2 from Prelude
Changes:
In order to be warning free and compatible, we hide Applicative(..)
from Prelude in a few places and instead import it directly from
Control.Applicative.
Please see the migration guide at
https://github.com/haskell/core-libraries-committee/blob/main/guides/export-lifta2-prelude.md
for more details.
This means that Applicative is now exported in its entirety from
Prelude.
Motivation:
This change is motivated by a few things:
* liftA2 is an often used function, even more so than (<*>) for some
people.
* When implementing Applicative, the compiler will prompt you for either
an implementation of (<*>) or of liftA2, but trying to use the latter
ends with an error, without further imports. This could be confusing
for newbies.
* For teaching, it is often times easier to introduce liftA2 first,
as it is a natural generalisation of fmap.
* This change seems to have been unanimously and enthusiastically
accepted by the CLC members, possibly indicating a lot of love for it.
* This change causes very limited breakage, see the linked issue below
for an investigation on this.
See https://github.com/haskell/core-libraries-committee/issues/50
for the surrounding discussion and more details.
- - - - -
442a94e8 by Georgi Lyubenov at 2022-09-08T17:14:36+03:00
Add changelog entry for liftA2 export from Prelude
- - - - -
fb968680 by Georgi Lyubenov at 2022-09-08T17:14:36+03:00
Bump submodule containers to one with liftA2 warnings fixed
- - - - -
f54ff818 by Georgi Lyubenov at 2022-09-08T17:14:36+03:00
Bump submodule Cabal to one with liftA2 warnings fixed
- - - - -
a4b34808 by Georgi Lyubenov at 2022-09-08T17:14:36+03:00
Isolate some Applicative hidings to GHC.Prelude
By reexporting the entirety of Applicative from GHC.Prelude, we can save
ourselves some `hiding` and importing of `Applicative` in consumers of GHC.Prelude.
This also has the benefit of isolating this type of change to
GHC.Prelude, so that people in the future don't have to think about it.
- - - - -
9c4ea90c by Cheng Shao at 2022-09-08T17:49:47-04:00
CmmToC: enable 64-bit CallishMachOp on 32-bit targets
Normally, the unregisterised builds avoid generating 64-bit
CallishMachOp in StgToCmm, so CmmToC doesn't support these. However,
there do exist cases where we'd like to invoke cmmToC for other cmm
inputs which may contain such CallishMachOps, and it's a rather low
effort to add support for these since they only require calling into
existing ghc-prim cbits.
- - - - -
04062510 by Alexis King at 2022-09-11T11:30:32+02:00
Add native delimited continuations to the RTS
This patch implements GHC proposal 313, "Delimited continuation
primops", by adding native support for delimited continuations to the
GHC RTS.
All things considered, the patch is relatively small. It almost
exclusively consists of changes to the RTS; the compiler itself is
essentially unaffected. The primops come with fairly extensive Haddock
documentation, and an overview of the implementation strategy is given
in the Notes in rts/Continuation.c.
This first stab at the implementation prioritizes simplicity over
performance. Most notably, every continuation is always stored as a
single, contiguous chunk of stack. If one of these chunks is
particularly large, it can result in poor performance, as the current
implementation does not attempt to cleverly squeeze a subset of the
stack frames into the existing stack: it must fit all at once. If this
proves to be a performance issue in practice, a cleverer strategy would
be a worthwhile target for future improvements.
- - - - -
ee471dfb by Cheng Shao at 2022-09-12T07:07:33-04:00
rts: fix missing dirty_MVAR argument in stg_writeIOPortzh
- - - - -
a5f9c35f by Cheng Shao at 2022-09-12T13:29:05-04:00
ci: enable parallel compression for xz
- - - - -
3a815f30 by Ryan Scott at 2022-09-12T13:29:41-04:00
Windows: Always define _UCRT when compiling C code
As seen in #22159, this is required to ensure correct behavior when MinGW-w64
headers are in the `C_INCLUDE_PATH`.
Fixes #22159.
- - - - -
65a0bd69 by sheaf at 2022-09-13T10:27:52-04:00
Add diagnostic codes
This MR adds diagnostic codes, assigning unique numeric codes to
error and warnings, e.g.
error: [GHC-53633]
Pattern match is redundant
This is achieved as follows:
- a type family GhcDiagnosticCode that gives the diagnostic code
for each diagnostic constructor,
- a type family ConRecursInto that specifies whether to recur into
an argument of the constructor to obtain a more fine-grained code
(e.g. different error codes for different 'deriving' errors),
- generics machinery to generate the value-level function assigning
each diagnostic its error code; see Note [Diagnostic codes using generics]
in GHC.Types.Error.Codes.
The upshot is that, to add a new diagnostic code, contributors only need
to modify the two type families mentioned above. All logic relating to
diagnostic codes is thus contained to the GHC.Types.Error.Codes module,
with no code duplication.
This MR also refactors error message datatypes a bit, ensuring we can
derive Generic for them, and cleans up the logic around constraint
solver reports by splitting up 'TcSolverReportInfo' into separate
datatypes (see #20772).
Fixes #21684
- - - - -
362cca13 by sheaf at 2022-09-13T10:27:53-04:00
Diagnostic codes: acccept test changes
The testsuite output now contains diagnostic codes, so many tests need
to be updated at once.
We decided it was best to keep the diagnostic codes in the testsuite
output, so that contributors don't inadvertently make changes to the
diagnostic codes.
- - - - -
08f6730c by Adam Gundry at 2022-09-13T10:28:29-04:00
Allow imports to reference multiple fields with the same name (#21625)
If a module `M` exports two fields `f` (using DuplicateRecordFields), we can
still accept
import M (f)
import M hiding (f)
and treat `f` as referencing both of them. This was accepted in GHC 9.0, but gave
rise to an ambiguity error in GHC 9.2. See #21625.
This patch also documents this behaviour in the user's guide, and updates the
test for #16745 which is now treated differently.
- - - - -
c14370d7 by Cheng Shao at 2022-09-13T10:29:07-04:00
ci: remove unused appveyor config
- - - - -
dc6af9ed by Cheng Shao at 2022-09-13T10:29:45-04:00
compiler: remove unused lazy state monad
- - - - -
f052b555 by Simon Peyton Jones at 2022-09-14T02:57:49+02:00
Start work
Not ready for review
More progress
Wibbles
Stage1 compiles
More wibbles
More wibbles
More -- almost working
Comments
Wibbles
Wibbles
Wibble inlineId
Wibbles
Infinite loop somewhere
More wibbles. Maybe can build stage2
Make FuNCo a thing by itself
Wibble
Wibble
Wibbles
Fix OptCoercion
Wibble
Wibble to optCoercion
Replace SORT with TYPE and CONSTRAINT
Wibble
Delete unused import
Delete TypeOrConstraint from ghc-prim:GHC.Types
Move from NthCo to SelCo
Wibbles
Wibbles in RepType
Wibble
Add mkWpEta
Really add mkWpEta
Wibble Typeable binds etc
Improve error messages
More wibbles, mainly to error messages
Wibbles
Wibbles to errors
Wibbles
But especially: treat Constraint as Typeable
More wibbles
More changes
* Move role into SelTyCon
* Get rid of mkTcSymCo and friends
Unused variable
Wibbles
Wibble
Accept error message changes
Refactoring...
Remove tc functions like tcKind, tcGetTyVar.
Move tyConsOfType, occCheckExpand to TyCo.FVs.
Introduce GHC.Core.TyCo.Compare
Lots of import changes!
Update haddock submodule (I hope)
Wibbles (notably: actually add GHC.Core.TyCo.Compare)
Wibbles
Wibble output of T16575
Wibbles
More wibbles
Remove infinite loop in T1946
See Note [ForAllTy and type equality]
Deal with rejigConRes
Needs a Note to be written by Richard
Some renaming
AnonArgFlag --> FunTyFlag
ArgFlag --> ForAllTyFlag
Update haddock submodule
Rename TyCoBinder to ForAllTyBinder
Wibbles
Update haddock
Wibble
Update unix submodule
I think I accidentally got it out of sync with HEAD;
this puts it back.
Rename TyCoBinder to PiTyBinder
Update Haddock submodule
Wrap dictionaries in tuples
This fixes the kind bugs in arrow desugaring. Needs some Notes,
but I want to try CI.
More on boxing data cons
Rebase and update GHC.Tc.Errors/GHC.Tc.Errors.Ppr
- - - - -
18 changed files:
- − .appveyor.sh
- .gitlab/ci.sh
- − appveyor.yml
- compiler/GHC.hs
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/Types.hs
- compiler/GHC/Builtin/Types.hs-boot
- compiler/GHC/Builtin/Types/Literals.hs
- compiler/GHC/Builtin/Types/Prim.hs
- − compiler/GHC/Builtin/Types/Prim.hs-boot
- compiler/GHC/Builtin/Uniques.hs
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/CmmToC.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Coercion.hs-boot
- compiler/GHC/Core/Coercion/Opt.hs
- compiler/GHC/Core/DataCon.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5fbc43a597387c2df50549b48b9f720dc27e471d...f052b55546d8a026417e3f2f1096ef521746d712
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5fbc43a597387c2df50549b48b9f720dc27e471d...f052b55546d8a026417e3f2f1096ef521746d712
You're receiving this email because of your account on gitlab.haskell.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20220913/d50196d6/attachment-0001.html>
More information about the ghc-commits
mailing list