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

Tue Mar 21 11:52:18 UTC 2023

Simon Peyton Jones pushed to branch wip/T23051 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.

- - - - -
b1d17df2 by Simon Peyton Jones at 2023-03-21T11:53:52+00:00
Be more careful about quantification

This MR is driven by #23051. It does several things:

* It is guided by the generalisation plan described in #20686.
  But it is still far from a complete implementation of that plan.

* Add Note [Inferred type with escaping kind] to GHC.Tc.Gen.Bind.
  This explains that we don't (yet, pending #20686) directly
  prevent generalising over escaping kinds.

* In `GHC.Tc.Utils.TcMType.defaultTyVar` we default RuntimeRep
  and Multiplicity variables, beause we don't want to quantify over
  them.  We want to do the same for a Concrete tyvar, but there is
  nothing sensible to default it to (unless it has kind RuntimeRep,
  in which case it'll be caught by an earlier case). So we promote
  instead.

* Pure refactoring in GHC.Tc.Solver:
  * Rename decideMonoTyVars to decidePromotedTyVars, since that's
    what it does.

  * Move the actual promotion of the tyvars-to-promote from
    `defaultTyVarsAndSimplify` to `decidePromotedTyVars`.  This is a
    no-op; just tidies up the code.  E.g then we don't need to
    return the promoted tyvars from `decidePromotedTyVars`.

  * A little refactoring in `defaultTyVarsAndSimplify`, but no
    change in behaviour.

* When making a TauTv unification variable into a ConcreteTv
  (in GHC.Tc.Utils.Concrete.makeTypeConcrete), preserve the occ-name
  of the type variable.  This just improves error messages.

* Kill off dead code: GHC.Tc.Utils.TcMType.newConcreteHole

- - - - -

30 changed files:

- compiler/GHC.hs
- compiler/GHC/Driver/Config.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/Gen/Bind.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Tc/Solver.hs
- compiler/GHC/Tc/Types/Constraint.hs
- compiler/GHC/Tc/Utils/Backpack.hs
- compiler/GHC/Tc/Utils/Concrete.hs
- compiler/GHC/Tc/Utils/TcMType.hs
- compiler/GHC/Tc/Validity.hs
- compiler/GHC/Types/Error/Codes.hs
- compiler/GHC/Types/Name/Shape.hs
- docs/users_guide/9.8.1-notes.rst
- ghc/GHCi/UI.hs
- ghc/GHCi/UI/Info.hs
- ghc/GHCi/UI/Monad.hs
- m4/fp_find_cxx_std_lib.m4
- testsuite/tests/backpack/cabal/bkpcabal06/bkpcabal06.stderr
- testsuite/tests/backpack/should_fail/bkpfail01.stderr
- testsuite/tests/backpack/should_fail/bkpfail05.stderr
- testsuite/tests/backpack/should_fail/bkpfail09.stderr
- testsuite/tests/backpack/should_fail/bkpfail16.stderr
- testsuite/tests/backpack/should_fail/bkpfail20.stderr
- testsuite/tests/backpack/should_fail/bkpfail21.stderr
- testsuite/tests/backpack/should_fail/bkpfail35.stderr
- testsuite/tests/backpack/should_fail/bkpfail37.stderr

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4e06ba8b1168d7346090848433aff9311fb1a2f9...b1d17df2da3483b8fee683b2994e7291156b0cc2

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4e06ba8b1168d7346090848433aff9311fb1a2f9...b1d17df2da3483b8fee683b2994e7291156b0cc2
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/3f979132/attachment.html>