[Git][ghc/ghc][wip/T25437] 24 commits: testsuite: Unmark T14028 as broken on FreeBSD

Thu Dec 12 21:03:48 UTC 2024

Simon Peyton Jones pushed to branch wip/T25437 at Glasgow Haskell Compiler / GHC

Commits:
4a8fc928 by Ben Gamari at 2024-12-11T12:33:42+00:00
testsuite: Unmark T14028 as broken on FreeBSD

This now appears to pass on FreeBSD 14.

Closes #19723.

- - - - -
d7c0eb5a by Ben Gamari at 2024-12-11T12:33:42+00:00
gitlab-ci: Migrate FreeBSD runner tag to FreeBSD 14

- - - - -
7246dacc by Ben Gamari at 2024-12-11T12:33:42+00:00
gitlab-ci: Reintroduce FreeBSD 14 job

- - - - -
4af936da by Ben Gamari at 2024-12-11T12:33:42+00:00
gitlab-ci: Allow use of newer cabal-install bindists

Newer cabal-install bindists have internal directory structure.
Here we detect and account for the presence of such structure.

- - - - -
cbf38c1b by Ben Gamari at 2024-12-11T12:33:42+00:00
gitlab-ci: Enable documentation build on FreeBSD 14

- - - - -
d68107fb by Ben Gamari at 2024-12-11T12:33:42+00:00
gitlab-ci: Use system libffi on FreeBSD

- - - - -
fea3b590 by Ben Gamari at 2024-12-11T12:33:42+00:00
testsuite: Mark linker_unload as broken on FreeeBSD

Due to #25491.

- - - - -
ccf171ee by Ben Gamari at 2024-12-11T12:33:42+00:00
gitlab-ci: Prefer system toolchain on FreeBSD

It's not uncommon to find machines with gcc installed via ports. We
should be using the system's default clang-based toolchain instead.

- - - - -
cfb34738 by Ben Gamari at 2024-12-11T12:33:42+00:00
testsuite: Mark T21969 as broken on FreeBSD

Due to #25512.

- - - - -
0b64e37c by Ben Gamari at 2024-12-11T12:33:42+00:00
testsuite: Mark RestartEventLogging as broken on FreeBSD

I am seeing this fail quite reproducibly.

Due to #19724.

- - - - -
3b412019 by Ben Gamari at 2024-12-11T12:33:42+00:00
testsuite: Mark T16180 as "broken" on FreeBSD

Sadly we in fact need to skip it as it merely times out during
compilation.

See #14012.

- - - - -
57e3cab5 by Ben Gamari at 2024-12-11T12:33:42+00:00
testsuite: Skip T16992 unless in slow speed

This test has extraordinary memory requirements and tests a rather
niche aspect of the compact region mechanism. It has been suggested
multiple times that we shouldn't run it in the default testsuite
configuration. Finally implement this.

See #21890.
See #21892.

- - - - -
f08a72eb by Ben Gamari at 2024-12-11T19:30:54-05:00
rts(setNumCapabilities): Assert that n_caps < MAX_N_CAPS

It was noticed in #25560 that this would previously be allowed,
resulting in a segfault.

I will add a proper exception in `base` in a future commit.

- - - - -
e10d31ad by Ben Gamari at 2024-12-11T19:30:55-05:00
ghc-internal: Fix inconsistent FFI import types

The foreign imports of `enabled_capabilities` and
`getNumberOfProcessors` were declared as `CInt` whereas they are defined
as `uint32_t`.

- - - - -
06265655 by Ben Gamari at 2024-12-11T19:30:55-05:00
rts: Mention maximum capability count in users guide

Addresses #25560.

- - - - -
d488470b by Ben Gamari at 2024-12-11T19:30:55-05:00
rts/Capability: Move induction variable declaration into `for`s

Just a stylistic change.

- - - - -
71f050b7 by Ben Gamari at 2024-12-11T19:30:55-05:00
rts: Determine max_n_capabilities at RTS startup

Previously the maximum number of capabilities supported by the RTS was
statically capped at 256. However, this bound is uncomfortably low given
the size of today's machine.

While supporting unbounded, fully-dynamic adjustment would be nice, it
is complex and so instead we do something simpler: Probe the logical
core count at RTS startup and use this as the static bound for the rest
of our execution.

This should avoid users running into the capability limit on large
machines while avoiding wasting memory on a large capabilities array for
most users and keeping complexity at bay.

Addresses #25560.

- - - - -
1e84b411 by Ben Gamari at 2024-12-11T19:30:55-05:00
testsuite: Introduce req_c_rts

As suggested by @hsyl20, this is intended to mark tests that rely on the
behavior of the C RTS.

- - - - -
683115a4 by Ben Gamari at 2024-12-11T19:30:55-05:00
testsuite: Add test for #25560

- - - - -
ef2052a8 by Ben Gamari at 2024-12-12T04:42:32-05:00
testsuite: Only run T14497_compact in normal way

This test targets the compacting GC so it makes little sense to run it
across all ways. Moreover, it outright conflicts with the `nonmoving`
way.

- - - - -
34d3e8e6 by Ben Gamari at 2024-12-12T04:43:08-05:00
rts/CheckUnload: Don't prepare to unload if we can't unload

Previously `prepareUnloadCheck` would move the `objects` list to
`old_objects` even when profiling (where we cannot unload). This caused
us to vacate the `objects` list during major GCs, losing track of loaded
objects. Fix this by ensuring that `prepareUnloadCheck` and
`checkUnload` both use the same short-cutting logic.

- - - - -
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

- - - - -
fb6437b8 by Simon Peyton Jones at 2024-12-12T21:03:30+00:00
Fix signature lookup in instance declarations

This fixes a bug introduced by the fix to #16610

- - - - -

30 changed files:

- .gitlab/ci.sh
- .gitlab/generate-ci/gen_ci.hs
- .gitlab/jobs.yaml
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Iface/Syntax.hs
- compiler/GHC/Iface/Type.hs
- compiler/GHC/Rename/Bind.hs
- compiler/GHC/Rename/Env.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
- docs/users_guide/using-concurrent.rst
- libraries/ghc-compact/tests/all.T
- libraries/ghc-internal/src/GHC/Internal/Conc/Sync.hs
- rts/Capability.c
- rts/Capability.h
- rts/CheckUnload.c
- rts/RtsSymbols.c
- rts/Schedule.c
- rts/include/rts/Config.h
- rts/include/rts/Threads.h
- testsuite/driver/testlib.py
- testsuite/tests/backpack/should_fail/T19244a.stderr
- testsuite/tests/backpack/should_fail/T19244b.stderr
- testsuite/tests/backpack/should_fail/bkpfail46.stderr
- testsuite/tests/concurrent/should_run/all.T
- testsuite/tests/ghci/T18060/T18060.stdout
- testsuite/tests/ghci/scripts/ListTuplePunsPpr.stdout
- testsuite/tests/ghci/scripts/T15941.stdout

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8dd5ea3cdc0915e6aa6d2d0b3a70b2afed09d6c9...fb6437b880a5ca89783cbf4ae8ce944e72bbf917

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/8dd5ea3cdc0915e6aa6d2d0b3a70b2afed09d6c9...fb6437b880a5ca89783cbf4ae8ce944e72bbf917
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/20241212/8c081124/attachment-0001.html>