[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 7 commits: haddock: Remove unused pragmata, qualify usages of Data.List functions, add...

Fri Jun 21 12:05:44 UTC 2024

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

Commits:
c872e09b by Hécate Kleidukos at 2024-06-20T19:28:36-04:00
haddock: Remove unused pragmata, qualify usages of Data.List functions, add more sanity checking flags by default

This commit enables some extensions and GHC flags in the cabal file in a way
that allows us to reduce the amount of prologuing on top of each file.

We also prefix the usage of some List functions that removes ambiguity
when they are also exported from the Prelude, like foldl'.
In general, this has the effect of pointing out more explicitly
that a linked list is used.

Metric Increase:
    haddock.Cabal
    haddock.base
    haddock.compiler

- - - - -
8c87d4e1 by Arnaud Spiwack at 2024-06-20T19:29:12-04:00
Add test case for #23586

- - - - -
568de8a5 by Arnaud Spiwack at 2024-06-20T19:29:12-04:00
When matching functions in rewrite rules: ignore multiplicity

When matching a template variable to an expression, we check that it
has the same type as the matched expression. But if the variable `f` has
type `A -> B` while the expression `e` has type `A %1 -> B`, the match was
previously rejected.

A principled solution would have `f` substituted by `\(%Many x) -> e
x` or some other appropriate coercion. But since linearity is not
properly checked in Core, we can be cheeky and simply ignore
multiplicity while matching. Much easier.

This has forced a change in the linter which, when `-dlinear-core-lint`
is off, must consider that `a -> b` and `a %1 -> b` are equal. This is
achieved by adding an argument to configure the behaviour of
`nonDetCmpTypeX` and modify `ensureEqTys` to call to the new behaviour
which ignores multiplicities when comparing two `FunTy`.

Fixes #24725.

- - - - -
c8a8727e by Simon Peyton Jones at 2024-06-20T19:29:12-04:00
Faster type equality

This MR speeds up type equality, triggered by perf regressions that
showed up when fixing #24725 by parameterising type equality over
whether to ignore multiplicity.

The changes are:

* Do not use `nonDetCmpType` for type /equality/. Instead use a specialised
  type-equality function, which we have always had!

  `nonDetCmpType` remains, but I did not invest effort in refactoring
  or optimising it.

* Type equality is parameterised by
    - whether to expand synonyms
    - whether to respect multiplicities
    - whether it has a RnEnv2 environment
  In this MR I systematically specialise it for static values of these
  parameters.  Much more direct and predictable than before.  See
  Note [Specialising type equality]

* We want to avoid comparing kinds if possible.  I refactored how this
  happens, at least for `eqType`.
  See Note [Casts and coercions in type comparison]

* To make Lint fast, we want to avoid allocating a thunk for <msg> in
      ensureEqTypes ty1 ty2 <msg>
  because the test almost always succeeds, and <msg> isn't needed.
  See Note [INLINE ensureEqTys]

Metric Decrease:
    T13386
    T5030

- - - - -
032b6b2d by Sebastian Graf at 2024-06-21T08:05:33-04:00
Derive previously hand-written `Lift` instances (#14030)

This is possible now that #22229 is fixed.

- - - - -
bff20301 by Sebastian Graf at 2024-06-21T08:05:33-04:00
Implement the "Derive Lift instances for data types in template-haskell" proposal (#14030)

After #22229 had been fixed, we can finally derive the `Lift` instance for the
TH AST, as proposed by Ryan Scott in
https://mail.haskell.org/pipermail/libraries/2015-September/026117.html.

Fixes #14030, #14296, #21759 and #24560.

- - - - -
d48159c5 by Matthew Pickering at 2024-06-21T08:05:34-04:00
bindist: Use complete relative paths when cding to directories

If a user has configured CDPATH on their system then `cd lib` may change
into an unexpected directory during the installation process.

If you write `cd ./lib` then it will not consult `CDPATH` to determine
what you mean.

I have added a check on ghcup-ci to verify that the bindist installation
works in this situation.

Fixes #24951

- - - - -

30 changed files:

- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Multiplicity.hs
- compiler/GHC/Core/TyCo/Compare.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Unify.hs
- compiler/GHC/Tc/Utils/TcType.hs
- hadrian/bindist/Makefile
- libraries/ghc-internal/src/GHC/Internal/TH/Lift.hs
- libraries/template-haskell/changelog.md
- libraries/template-haskell/template-haskell.cabal.in
- testsuite/tests/ghci/scripts/all.T
- testsuite/tests/interface-stability/template-haskell-exports.stdout
- + testsuite/tests/simplCore/should_run/T23586.hs
- + testsuite/tests/simplCore/should_run/T23586.stdout
- testsuite/tests/simplCore/should_run/all.T
- testsuite/tests/th/TH_Lift.hs
- + testsuite/tests/th/TH_Lift.stderr
- testsuite/tests/th/all.T
- utils/haddock/haddock-api/haddock-api.cabal
- utils/haddock/haddock-api/src/Haddock.hs
- utils/haddock/haddock-api/src/Haddock/Backends/Xhtml.hs
- utils/haddock/haddock-api/src/Haddock/Backends/Xhtml/Layout.hs
- utils/haddock/haddock-api/src/Haddock/GhcUtils.hs
- utils/haddock/haddock-api/src/Haddock/Interface.hs
- utils/haddock/haddock-api/src/Haddock/Interface/AttachInstances.hs
- utils/haddock/haddock-api/src/Haddock/Interface/Create.hs
- utils/haddock/haddock-api/src/Haddock/Options.hs
- utils/haddock/haddock-api/src/Haddock/Types.hs
- utils/haddock/haddock-library/fixtures/Fixtures.hs

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/7392a0120b1d38e022108eb47e55f19f2d4e1ad3...d48159c5dca07c172e2126926c66e420e92fdf41

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/7392a0120b1d38e022108eb47e55f19f2d4e1ad3...d48159c5dca07c172e2126926c66e420e92fdf41
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/20240621/7ace62b9/attachment.html>