[Git][ghc/ghc][wip/jsem] 6 commits: Fix BCO creation setting caps when -j > -N

Tue Mar 21 13:08:52 UTC 2023

Matthew Pickering pushed to branch wip/jsem at Glasgow Haskell Compiler / GHC

Commits:
c9c26cd6 by Teo Camarasu at 2023-03-16T12:17:50-04:00
Fix BCO creation setting caps when -j > -N

* Remove calls to 'setNumCapabilities' in 'createBCOs'
These calls exist to ensure that 'createBCOs' can benefit from
parallelism. But this is not the right place to call
`setNumCapabilities`. Furthermore the logic differs from that in the
driver causing the capability count to be raised and lowered at each TH
call if -j > -N.

* Remove 'BCOOpts'
No longer needed as it was only used to thread the job count down to `createBCOs`

Resolves #23049

- - - - -
5ddbf5ed by Teo Camarasu at 2023-03-16T12:17:50-04:00
Add changelog entry for #23049

- - - - -
6e3ce9a4 by Ben Gamari at 2023-03-16T12:18:26-04:00
configure: Fix FIND_CXX_STD_LIB test on Darwin

Annoyingly, Darwin's <cstddef> includes <version> and APFS is
case-insensitive. Consequently, it will end up #including the
`VERSION` file generated by the `configure` script on the second
and subsequent runs of the `configure` script.

See #23116.
- - - - -
19d6d039 by sheaf at 2023-03-16T21:31:22+01:00
ghci: only keep the GlobalRdrEnv in ModInfo

The datatype GHC.UI.Info.ModInfo used to store a ModuleInfo,
which includes a TypeEnv. This can easily cause space leaks as we
have no way of forcing everything in a type environment.

In GHC, we only use the GlobalRdrEnv, which we can force completely.
So we only store that instead of a fully-fledged ModuleInfo.

- - - - -
73d07c6e by Torsten Schmits at 2023-03-17T14:36:49-04:00
Add structured error messages for GHC.Tc.Utils.Backpack

Tracking ticket: #20119

MR: !10127

This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.
One occurrence, when handing a nested error from the interface loading
machinery, was omitted. It will be handled by a subsequent changeset
that addresses interface errors.

- - - - -
643f9a07 by sheaf at 2023-03-21T13:08:41+00:00
Implement -jsem: parallelism controlled by semaphores

See https://github.com/ghc-proposals/ghc-proposals/pull/540/ for a
complete description for the motivation for this feature.

The `-jsem` option allows a build tool to pass a semaphore to GHC which
GHC can use in order to control how much parallelism it requests.

GHC itself acts as a client in the GHC jobserver protocol.

```
GHC Jobserver Protocol
~~~~~~~~~~~~~~~~~~~~~~

This proposal introduces the GHC Jobserver Protocol. This protocol allows
a server to dynamically invoke many instances of a client process,
while restricting all of those instances to use no more than <n> capabilities.
This is achieved by coordination over a system semaphore (either a POSIX
semaphore [6]_  in the case of Linux and Darwin, or a Win32 semaphore [7]_
in the case of Windows platforms).

There are two kinds of participants in the GHC Jobserver protocol:

- The *jobserver* creates a system semaphore with a certain number of
  available tokens.

  Each time the jobserver wants to spawn a new jobclient subprocess, it **must**
  first acquire a single token from the semaphore, before spawning
  the subprocess. This token **must** be released once the subprocess terminates.

  Once work is finished, the jobserver **must** destroy the semaphore it created.

- A *jobclient* is a subprocess spawned by the jobserver or another jobclient.

  Each jobclient starts with one available token (its *implicit token*,
  which was acquired by the parent which spawned it), and can request more
  tokens through the Jobserver Protocol by waiting on the semaphore.

  Each time a jobclient wants to spawn a new jobclient subprocess, it **must**
  pass on a single token to the child jobclient. This token can either be the
  jobclient's implicit token, or another token which the jobclient acquired
  from the semaphore.

  Each jobclient **must** release exactly as many tokens as it has acquired from
  the semaphore (this does not include the implicit tokens).
```

Build tools such as cabal act as jobservers in the protocol and are
responsibile for correctly creating, cleaning up and managing the
semaphore.

Fixes #19349

- - - - -

30 changed files:

- .gitmodules
- cabal.project-reinstall
- compiler/GHC.hs
- compiler/GHC/Driver/Config.hs
- compiler/GHC/Driver/Make.hs
- + compiler/GHC/Driver/MakeSem.hs
- compiler/GHC/Driver/Pipeline/LogQueue.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Linker/Loader.hs
- compiler/GHC/Runtime/Interpreter.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Errors/Types.hs
- compiler/GHC/Tc/Utils/Backpack.hs
- compiler/GHC/Types/Error/Codes.hs
- compiler/GHC/Types/Name/Shape.hs
- compiler/ghc.cabal.in
- docs/users_guide/9.8.1-notes.rst
- docs/users_guide/using.rst
- ghc/GHCi/UI.hs
- ghc/GHCi/UI/Info.hs
- ghc/GHCi/UI/Monad.hs
- hadrian/src/Packages.hs
- hadrian/src/Rules/ToolArgs.hs
- hadrian/src/Settings/Default.hs
- + libraries/semaphore-compat
- m4/fp_find_cxx_std_lib.m4
- packages
- testsuite/tests/backpack/cabal/bkpcabal06/bkpcabal06.stderr
- testsuite/tests/backpack/should_fail/bkpfail01.stderr
- testsuite/tests/backpack/should_fail/bkpfail05.stderr

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b0db02e7c70ca6bfcb012e366e94a484935c775a...643f9a072fae45e74f8dc5ae10b648e868510fdd

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b0db02e7c70ca6bfcb012e366e94a484935c775a...643f9a072fae45e74f8dc5ae10b648e868510fdd
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/20230321/91a2224f/attachment-0001.html>