[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 5 commits: Merge ghc-bignum into ghc-internal (#24453)

[Marge Bot (@marge-bot)]

Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC


Commits:
3f7ebc58 by Sylvain Henry at 2024-12-19T20:40:14-05:00
Merge ghc-bignum into ghc-internal (#24453)

First step towards merging ghc-bignum and ghc-prim into ghc-internal.

After this patch, ghc-bignum is deprecated and is just a shallow package
reexporting modules from ghc-internal and base. Use those directly
instead.

Move `gmp` submodule into ghc-internal directory.

- - - - -
ee0150c2 by Rodrigo Mesquita at 2024-12-19T20:40:51-05:00
Improve performance of deriving Show

Significantly improves performance of deriving Show instances by
avoiding using the very polymorphic `.` operator in favour of inlining
its definition. We were generating tons of applications of it, each
which had 3 type arguments!

Improves on #9557

-------------------------
Metric Decrease:
    InstanceMatching
    T12707
    T3294
------------------------

- - - - -
8b266671 by Rodrigo Mesquita at 2024-12-19T20:40:51-05:00
Don't eta expand cons when deriving Data

This eta expansion was introduced with the initial commit for Linear
types.

I believe this isn't needed any longer. My guess is it is an artifact
from the initial linear types implementation: data constructors are
linear, but they shouldn't need to be eta expanded to be used as higher
order functions. I suppose in the early days this wasn't true.

For instance, this works now:

    data T x = T x
    f = \(x :: forall y. y -> T y) -> x True
    f T -- ok!

T is linear, but can be passed where an unrestricted higher order
function is expected. I recall there being some magic around to make
this work for data constructors...

Since this works, there's no need to eta_expand the data constructors in
the derived Data instances.

- - - - -
1c347a6d by Andrei Borzenkov at 2024-12-24T04:00:06-05:00
Flip the order of arguments of setField (#24668)

GHC Proposal 583 "HasField redesign" specifies the
following order of a setField function arguments as this:

  setField :: forall fld a b. SetField fld a b. b -> a -> a

This patch flips the application order to match the spec.

- - - - -
38e22ea0 by Ben Gamari at 2024-12-24T04:00:07-05:00
rel-eng/upload: Add set_symlink mode

This slightly eases updating of the `latest` symlinks.

- - - - -


30 changed files:

- .gitlab/rel_eng/upload.sh
- .gitmodules
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Driver/Config/Core/Rules.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/Tc/Deriv/Generate.hs
- compiler/GHC/Tc/Gen/Default.hs
- compiler/GHC/Tc/Utils/Env.hs
- compiler/GHC/Unit/Types.hs
- docs/users_guide/9.14.1-notes.rst
- docs/users_guide/exts/overloaded_record_update.rst
- hadrian/src/CommandLine.hs
- hadrian/src/Rules/Gmp.hs
- hadrian/src/Rules/Library.hs
- hadrian/src/Rules/Register.hs
- hadrian/src/Rules/SourceDist.hs
- hadrian/src/Settings/Packages.hs
- libraries/base/base.cabal.in
- + libraries/base/src/GHC/Num/BigNat.hs
- + libraries/base/src/GHC/Num/Integer.hs
- + libraries/base/src/GHC/Num/Natural.hs
- − libraries/ghc-bignum/.gitignore
- + libraries/ghc-bignum/Dummy.hs
- − libraries/ghc-bignum/Setup.hs
- − libraries/ghc-bignum/aclocal.m4
- libraries/ghc-bignum/changelog.md
- − libraries/ghc-bignum/config.mk.in


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e4b1f64351c1f64bbb6769dd2efc51d302597e13...38e22ea07fc5585f82b136b7cf439742e6357d02

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e4b1f64351c1f64bbb6769dd2efc51d302597e13...38e22ea07fc5585f82b136b7cf439742e6357d02
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/20241224/8323e49e/attachment.html>