[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 5 commits: Update GHCi :info type declaration printing (#24459)

Sat Dec 14 01:20:57 UTC 2024

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

Commits:
9c53489d by Andrei Borzenkov at 2024-12-12T15:06:42-05:00
Update GHCi :info type declaration printing (#24459)

- Do not print result's kind in type families
  because we have full kind in SAKS and we display
  invisible arity using @-binders

- Do not suppress significant invisible binders

An invisible binder is considered significant when it meets at least
one of the following two criteria:
  - It visibly occurs in the declaration's body
  - It is followed by a significant binder,
    so it affects positioning
For non-generative type declarations (type synonyms and type families)
there is one additional criterion:
  - It is not followed by a visible binder, so it
    affects the arity of a type synonym

See Note [Print invisible binders in interface declarations]
for more information about what is "visibly occurs"

- - - - -
13fe48d4 by Matthew Pickering at 2024-12-12T15:07:19-05:00
typechecker: Perform type family consistency checks in topological order

Consider a module M importing modules A, B and C.

We can waste a lot of work depending on the order that the modules are
checked for family consistency.

Consider that C imports A and B. When compiling C we must have already
checked A and B for consistency, therefore if C is processed first then
A and B will not need to be checked for consistency again.

If A and B are compared first, then the consistency checks will be
performed against (wasted as we already performed them for C).

At the moment the order which modules are checked is non-deterministic.

Clearly we should engineer that C is checked before B and A, but by what
scheme?

A simple one is to observe that if a module M is in the transitive
closure of X then the size of the consistent family set of M is less
than or equal to size of the consistent family set of X.

Therefore by sorting the imports by the size of the consistent family
set and processing the largest first, you make sure to process modules
in topological order.

In practice we have observed that this strategy has reduced the amount
of consistency checks performed.

One solution to #25554

- - - - -
b51d841f by Sylvain Henry at 2024-12-13T20:20:49-05:00
TNTC: set CmmProc entry_label properly (#25565)

Before this patch we were renaming the entry label of a CmmProc late in
the CmmToAsm pass. It led to inconsistencies and to some labels being
used in info tables but not being emitted (#25565).
Now we set the CmmProc entry label earlier in the StgToCmm monad and we
don't renamed it afterwards.

- - - - -
d3089a2c by Simon Hengel at 2024-12-13T20:20:51-05:00
Make filter functionality for system tools line-based

This is more efficient as:

- All existing filter functions were line-based anyway.  They broke up
  the input into lines and then joined it back together.
- We already break up the output from system tools into lines when
  processing it.

Splitting up the output of system tools once and then filtering and
processing it reduces both code and runtime complexity.

- - - - -
3c8fd6c7 by Simon Hengel at 2024-12-13T20:20:51-05:00
Refactoring: Don't use a `Chan` when parsing SysTools output

- - - - -

30 changed files:

- compiler/GHC/CmmToAsm/X86/Ppr.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Driver/Config/Linker.hs
- compiler/GHC/Iface/Syntax.hs
- compiler/GHC/Iface/Type.hs
- compiler/GHC/Linker/Config.hs
- compiler/GHC/StgToCmm/Monad.hs
- compiler/GHC/SysTools/Process.hs
- compiler/GHC/SysTools/Tasks.hs
- compiler/GHC/Tc/Instance/Family.hs
- compiler/GHC/Tc/Module.hs
- docs/users_guide/9.14.1-notes.rst
- docs/users_guide/ghci.rst
- testsuite/tests/backpack/should_fail/T19244a.stderr
- testsuite/tests/backpack/should_fail/T19244b.stderr
- testsuite/tests/backpack/should_fail/bkpfail46.stderr
- testsuite/tests/ghci/T18060/T18060.stdout
- testsuite/tests/ghci/scripts/ListTuplePunsPpr.stdout
- testsuite/tests/ghci/scripts/T15941.stdout
- testsuite/tests/ghci/scripts/T19310.stdout
- testsuite/tests/ghci/scripts/T21294a.stdout
- + testsuite/tests/ghci/scripts/T24459.script
- + testsuite/tests/ghci/scripts/T24459.stdout
- testsuite/tests/ghci/scripts/T8535.stdout
- testsuite/tests/ghci/scripts/T9181.stdout
- testsuite/tests/ghci/scripts/all.T
- testsuite/tests/ghci/scripts/ghci020.stdout
- testsuite/tests/ghci/should_run/T10145.stdout
- testsuite/tests/ghci/should_run/T18594.stdout
- testsuite/tests/interface-stability/base-exports.stdout

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/7698a505889cd590af93a18956188e339e3199c5...3c8fd6c74eb22e29f4f5397bf4deec1b6cded99f

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/7698a505889cd590af93a18956188e339e3199c5...3c8fd6c74eb22e29f4f5397bf4deec1b6cded99f
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/20241213/95356a45/attachment.html>