[Git][ghc/ghc][wip/T23146] 10 commits: Bump Win32 to 2.13.4.0

Ben Gamari (@bgamari) gitlab at gitlab.haskell.org
Wed Mar 22 22:11:30 UTC 2023



Ben Gamari pushed to branch wip/T23146 at Glasgow Haskell Compiler / GHC


Commits:
536d1f90 by Matthew Pickering at 2023-03-13T14:04:49+00:00
Bump Win32 to 2.13.4.0

Updates Win32 submodule

- - - - -
ee17001e by Ben Gamari at 2023-03-13T21:18:24-04:00
ghc-bignum: Drop redundant include-dirs field
- - - - -
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.

- - - - -
d871e8a4 by Ben Gamari at 2023-03-22T18:10:34-04:00
codeGen: Fix some Haddocks

- - - - -
a69cab40 by Ben Gamari at 2023-03-22T18:10:34-04:00
codeGen: Give proper LFInfo to datacon wrappers

As noted in `Note [Conveying CAF-info and LFInfo between modules]`,
when importing a binding from another module we must ensure that it gets
the appropriate `LambdaFormInfo` if it is in WHNF to ensure that
references to it are tagged correctly.

However, the implementation responsible for doing this,
`GHC.StgToCmm.Closure.mkLFImported`, only dealt with datacon workers and
not wrappers. This lead to the crash of this program in #23146:

    module B where

    type NP :: [UnliftedType] -> UnliftedType
    data NP xs where
      UNil :: NP '[]

    module A where
    import B

    fieldsSam :: NP xs -> NP xs -> Bool
    fieldsSam UNil UNil = True

    x = fieldsSam UNil UNil

Due to its GADT nature, `UNil` produces a trivial wrapper

    $WUNil :: NP '[]
    $WUNil = UNil @'[] @~(<co:1>)

which is referenced in the RHS of `A.x`. Due to the above-mentioned bug
in `mkLFImported`, the references to `$WUNil` passed to `fieldsSam` were
not tagged. This is problematic as `fieldsSam` expected its arguments to
be tagged as they are unlifted.

The fix is straightforward: extend the logic in `mkLFImported` to cover
(nullary) datacon wrappers as well as workers. This is safe because we
know that the wrapper of a nullary datacon will be in WHNF, even if it
includes equalities evidence (since such equalities are not runtime
relevant).

Thanks to @MangoIV for the great ticket and @alt-romes for his
minimization and help debugging.

Fixes #23146.

- - - - -
f26b6259 by Ben Gamari at 2023-03-22T18:11:24-04:00
testsuite: Add test for #23146

- - - - -


30 changed files:

- compiler/GHC.hs
- compiler/GHC/Driver/Config.hs
- compiler/GHC/Linker/Loader.hs
- compiler/GHC/Runtime/Interpreter.hs
- compiler/GHC/StgToCmm/Closure.hs
- compiler/GHC/StgToCmm/Env.hs
- compiler/GHC/StgToCmm/Monad.hs
- compiler/GHC/StgToCmm/Types.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
- docs/users_guide/9.8.1-notes.rst
- ghc/GHCi/UI.hs
- ghc/GHCi/UI/Info.hs
- ghc/GHCi/UI/Monad.hs
- libraries/Win32
- libraries/ghc-bignum/ghc-bignum.cabal
- 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
- testsuite/tests/backpack/should_fail/bkpfail38.stderr


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b5e13c0327ee63cc6dc7ecec69cb06b60bb3b3f0...f26b625943f579c5816e4788611f7478ed6863c5

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b5e13c0327ee63cc6dc7ecec69cb06b60bb3b3f0...f26b625943f579c5816e4788611f7478ed6863c5
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/20230322/95b4b63a/attachment.html>


More information about the ghc-commits mailing list