[Git][ghc/ghc][wip/ghc-9.4.5-backports] 48 commits: hadrian bindist: Install manpages to share/man/man1/ghc.1
Zubin (@wz1000)
gitlab at gitlab.haskell.org
Tue Apr 11 08:51:46 UTC 2023
Zubin pushed to branch wip/ghc-9.4.5-backports at Glasgow Haskell Compiler / GHC
Commits:
6f4d4183 by Matthew Pickering at 2023-04-11T14:21:10+05:30
hadrian bindist: Install manpages to share/man/man1/ghc.1
When the installation makefile was copied over the manpages were no
longer installed in the correct place. Now we install it into share/man/man1/ghc.1
as the make build system did.
Fixes #22371
(cherry picked from commit 32b32d7fbc5544ad6c435a1ea26e6353ec567a9b)
- - - - -
0f66e042 by Matthew Pickering at 2023-04-11T14:21:10+05:30
Fix recompilation checking for multiple home units
The key part of this change is to store a UnitId in the
`UsageHomeModule` and `UsageHomeModuleInterface`.
* Fine-grained dependency tracking is used if the dependency comes from
any home unit.
* We actually look up the right module when checking whether we need to
recompile in the `UsageHomeModuleInterface` case.
These scenarios are both checked by the new tests (
multipleHomeUnits_recomp and multipleHomeUnits_recomp_th )
Fixes #22675
(cherry picked from commit 1d1dd3fbfafdb9705076d4c587d5cf47e33b7640)
- - - - -
b22be33e by Matthew Pickering at 2023-04-11T14:21:10+05:30
Augment target filepath by working directory when checking if module satisfies target
This fixes a spurious warning in -Wmissing-home-modules.
This is a simple oversight where when looking for the target in the
first place we augment the search by the -working-directory flag but
then fail to do so when checking this warning.
Fixes #22676
(cherry picked from commit 7bfb30f92f5e21a8aca58068dc970040130433c6)
- - - - -
758e5bf3 by Matthew Pickering at 2023-04-11T14:21:10+05:30
Use NodeKey rather than ModuleName in pruneCache
The `pruneCache` function assumes that the list of `CachedInfo` all have unique `ModuleName`, this is not true:
* In normal compilation, the same module name can appear for a file and it's boot file.
* In multiple home unit compilation the same ModuleName can appear in different units
The fix is to use a `NodeKey` as the actual key for the interfaces which includes `ModuleName`, `IsBoot` and `UnitId`.
Fixes #22677
(cherry picked from commit 69500dd4a6dc81fa6fee6f24f0fe08a07b6112fc)
- - - - -
4509941c by Matthew Pickering at 2023-04-11T14:21:10+05:30
Recompilation checking: Don't try to find artefacts for Interactive & hs-boot combo
In interactive mode we don't produce any linkables for hs-boot files. So
we also need to not going looking for them when we check to see if we
have all the right objects needed for recompilation.
Ticket #22669
(cherry picked from commit 336b2b1c8628b1317de46078e049b529205f2129)
- - - - -
6198f5c8 by Matthew Pickering at 2023-04-11T14:21:10+05:30
Don't write o-boot files in Interactive mode
We should not be producing object files when in interactive mode but we
still produced the dummy o-boot files. These never made it into a
`Linkable` but then confused the recompilation checker.
Fixes #22669
(cherry picked from commit 6469fea7c78408db679898168a8e9c50c8c7c5ce)
- - - - -
4a2ed4f0 by Matthew Pickering at 2023-04-11T14:21:10+05:30
Improve driver diagnostic messages by including UnitId in message
Currently the driver diagnostics don't give any indication about which unit they correspond to.
For example `-Wmissing-home-modules` can fire multiple times for each different home unit and gives no indication about which unit it's actually reporting about.
Perhaps a longer term fix is to generalise the providence information away from a SrcSpan so that these kind of whole project errors can be reported with an accurate provenance. For now we can just include the `UnitId` in the error message.
Fixes #22678
(cherry picked from commit 06cc0a9529f2fe0dfa40d9966a52a982653bfcb9)
- - - - -
25abf0e4 by Matthew Pickering at 2023-04-11T14:21:11+05:30
Key ModSummary cache by UnitId as well as FilePath
Multiple units can refer to the same files without any problem. Just
another assumption which needs to be updated when we may have multiple
home units.
However, there is the invariant that within each unit each file only
maps to one module, so as long as we also key the cache by UnitId then
we are all good.
This led to some confusing behaviour in GHCi when reloading,
multipleHomeUnits_shared distils the essence of what can go wrong.
Fixes #22679
(cherry picked from commit 4fe9eaff11ccf1fe185de2918aef4f96fd200c72)
- - - - -
2b1cb6ae by Matthew Pickering at 2023-04-11T14:21:11+05:30
Finder: Look in current unit before looking in any home package dependencies
In order to preserve existing behaviour it's important to look within the current component before consideirng a module might come from an external component.
This already happened by accident in `downsweep`, (because roots are used to repopulated the cache) but in the `Finder` the logic was the wrong way around.
Fixes #22680
-------------------------
Metric Decrease:
MultiComponentModules
MultiComponentModulesRecomp
-------------------------p
(cherry picked from commit ada29f5ca5a567b69713f08feac9ee4f247de117)
- - - - -
647b8685 by Matthew Pickering at 2023-04-11T14:21:11+05:30
Debug: Print full NodeKey when pretty printing ModuleGraphNode
This is helpful when debugging multiple component issues.
(cherry picked from commit be701cc64f0ff78aa50bcd7293d8692dc1ba6c85)
- - - - -
ec025db7 by Simon Peyton Jones at 2023-04-11T14:21:11+05:30
Add a missing checkEscapingKind
Ticket #22743 pointed out that there is a missing check,
for type-inferred bindings, that the inferred type doesn't
have an escaping kind.
The fix is easy.
(cherry picked from commit 496607fdb77baf12e2fe263104ba5d0d700eee3b)
- - - - -
da548fd0 by Matthew Pickering at 2023-04-11T14:21:11+05:30
Only store Name in FunRhs rather than Id with knot-tied fields
All the issues here have been caused by #18758.
The goal of the ticket is to be able to talk about things like
`LTyClDecl GhcTc`. In the case of HsMatchContext,
the correct "context" is whatever we want, and in fact storing just a
`Name` is sufficient and correct context, even if the rest of the AST is
storing typechecker Ids.
So this reverts (#20415, !5579) which intended to get closed to #18758 but
didn't really and introduced a few subtle bugs.
Printing of an error message in #22695 would just hang, because we would
attempt to print the `Id` in debug mode to assertain whether it was
empty or not. Printing the Name is fine for the error message.
Another consequence is that when `-dppr-debug` was enabled the compiler would
hang because the debug printing of the Id would try and print fields
which were not populated yet.
This also led to 32070e6c2e1b4b7c32530a9566fe14543791f9a6 having to add
a workaround for the `checkArgs` function which was probably a very
similar bug to #22695.
Fixes #22695
(cherry picked from commit ac39e8e97fbb69e4a786c1c29d6e477e7944f998)
- - - - -
ad34d110 by Matthew Pickering at 2023-04-11T14:21:11+05:30
Store dehydrated data structures in CgModBreaks
This fixes a tricky leak in GHCi where we were retaining old copies of
HscEnvs when reloading. If not all modules were recompiled then these
hydrated fields in break points would retain a reference to the old
HscEnv which could double memory usage.
Fixes #22530
(cherry picked from commit 1262d3f8c03799a04d3c5fcf33d4d4db715ca9a1)
- - - - -
91fa7f73 by Matthew Pickering at 2023-04-11T14:21:11+05:30
Force more in NFData Name instance
Doesn't force the lazy `OccName` field (#19619) which is already known
as a really bad source of leaks.
When we slam the hammer storing Names on disk (in interface files or the
like), all this should be forced as otherwise a `Name` can easily retain
an `Id` and hence the entire world.
Fixes #22833
(cherry picked from commit e27eb80cc7e0c82e07fbd8d9ae8112d9070c4355)
- - - - -
4022a117 by Matthew Pickering at 2023-04-11T14:21:11+05:30
Force OccName in tidyTopName
This occname has just been derived from an `Id`, so need to force it
promptly so we can release the Id back to the world.
Another symptom of the bug caused by #19619
(cherry picked from commit 3d004d5a961fbbbe11da1050b725468a970bee4b)
- - - - -
f4b4d8f2 by Matthew Pickering at 2023-04-11T14:21:11+05:30
Strict fields in ModNodeKey (otherwise retains HomeModInfo)
Towards #22530
(cherry picked from commit f2a0fea09a88693d876fb891ea7c8c97373c4aa6)
- - - - -
d66ec1da by Krzysztof Gogolewski at 2023-04-11T14:21:11+05:30
Fix unification with oversaturated type families
unify_ty was incorrectly saying that F x y ~ T x are surely apart,
where F x y is an oversaturated type family and T x is a tyconapp.
As a result, the simplifier dropped a live case alternative (#23134).
(cherry picked from commit 7c16f3be6e1ac92f87d752f12ad6c6e7b7fd6207)
- - - - -
df640029 by Simon Peyton Jones at 2023-04-11T14:21:11+05:30
Be more careful in GHC.Tc.Solver.Interact.solveOneFromTheOther
We were failing to account for the cc_pend_sc flag in this
important function, with the result that we expanded superclasses
forever.
Fixes #22516.
(cherry picked from commit a3a8e9e968ff9b10c6785d53a5f1c8fcef6db72b)
- - - - -
dcbfb699 by sheaf at 2023-04-11T14:21:11+05:30
Hadrian: merge archives even in stage 0
We now always merge .a archives when ar supports -L.
This change is necessary in order to bootstrap GHC using GHC 9.4
on Windows, as nested archives aren't supported.
Not doing so triggered bug #21990 when trying to use the Win32
package, with errors such as:
Not a x86_64 PE+ file.
Unknown COFF 4 type in getHeaderInfo.
ld.lld: error: undefined symbol: Win32zm2zi12zi0zi0_SystemziWin32ziConsoleziCtrlHandler_withConsoleCtrlHandler1_info
We have to be careful about which ar is meant: in stage 0, the check
should be done on the system ar (system-ar in system.config).
(cherry picked from commit 545ff490144ed3ddd596d2a0c01b0a16b5528f63)
- - - - -
612f6029 by Sylvain Henry at 2023-04-11T14:21:11+05:30
Hadrian: correctly detect AR at-file support
Stage0's ar may not support at-files. Take it into account.
Found while cross-compiling from Darwin to Windows.
(cherry picked from commit e987e345c807035e4637ca3eae227ae501e16c42)
- - - - -
92c0acf2 by Sylvain Henry at 2023-04-11T14:21:11+05:30
Hadrian: fix Windows cross-compilation
Decision to build either unix or Win32 package must be stage specific
for cross-compilation to be supported.
(cherry picked from commit 48131ee2d8ba7074a4c2763a32c12df105305a75)
- - - - -
2eec25f1 by Sylvain Henry at 2023-04-11T14:21:11+05:30
Fix RTS build on Windows
This change fixes a cross-compilation issue from ArchLinux to Windows
because these symbols weren't found.
(cherry picked from commit 288fa0179a2f54e4594afe184eac71cc85c46643)
- - - - -
d3afd617 by Sylvain Henry at 2023-04-11T14:21:11+05:30
configure: support "windows" as an OS
(cherry picked from commit 2fdf22aebda2307d86872c792633d1856d666c9b)
- - - - -
939b17c4 by Ben Gamari at 2023-04-11T14:21:11+05:30
rts: Drop racy assertion
0e274c39bf836d5bb846f5fa08649c75f85326ac added an assertion in
`dirty_MUT_VAR` checking that the MUT_VAR being dirtied was clean.
However, this isn't necessarily the case since another thread may have
raced us to dirty the object.
(cherry picked from commit b3eacd64fb36724ed6c5d2d24a81211a161abef1)
- - - - -
318af91c by Ben Gamari at 2023-04-11T14:21:11+05:30
configure: Fix escaping of `$tooldir`
In !9547 I introduced `$tooldir` directories into GHC's default link and
compilation flags to ensure that our C toolchain finds its own headers
and libraries before others on the system. However, the patch was subtly
wrong in the escaping of `$tooldir`. Fix this.
Fixes #22561.
(cherry picked from commit 9ffd5d57a7cc19bcd6ea0139b00c77639566ba82)
- - - - -
9d3d8b99 by Ben Gamari at 2023-04-11T14:21:11+05:30
Bump ghc-tarballs to fix #22497
It turns out that gmp 6.2.1 uses the platform-reserved `x18` register on
AArch64/Darwin. This was fixed in upstream changeset 18164:5f32dbc41afc,
which was merged in 2020. Here I backport this patch although I do hope
that a new release is forthcoming soon.
Bumps gmp-tarballs submodule.
Fixes #22497.
(cherry picked from commit f891a442046d8a5ebf4d4777847880ce06752b18)
- - - - -
b5ce8f77 by Ben Gamari at 2023-04-11T14:21:11+05:30
Bump gmp-tarballs submodule
This backports the upstream fix for CVE-2021-43618, fixing #22789.
(cherry picked from commit b13c6ea5d4b64841164f8cc58d6c6f3de390f2ed)
- - - - -
91298f87 by Li-yao Xia at 2023-04-11T14:21:12+05:30
base: Move changelog entry to its place
(cherry picked from commit 11de324aae17794c8753a8f7cb50c4140785fe27)
- - - - -
f64d0c8f by Matthew Pickering at 2023-04-11T14:21:12+05:30
Add test for T23184
There was an outright bug, which Simon fixed in July 2021, as a little side-fix on a complicated patch:
```
commit 6656f0165a30fc2a22208532ba384fc8e2f11b46
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date: Fri Jul 23 23:57:01 2021 +0100
A bunch of changes related to eta reduction
This is a large collection of changes all relating to eta
reduction, originally triggered by #18993, but there followed
a long saga.
Specifics:
...lots of lines omitted...
Other incidental changes
* Fix a fairly long-standing outright bug in the ApplyToVal case of
GHC.Core.Opt.Simplify.mkDupableContWithDmds. I was failing to take the
tail of 'dmds' in the recursive call, which meant the demands were All
Wrong. I have no idea why this has not caused problems before now.
```
Note this "Fix a fairly longstanding outright bug". This is the specific fix
```
@@ -3552,8 +3556,8 @@ mkDupableContWithDmds env dmds
-- let a = ...arg...
-- in [...hole...] a
-- NB: sc_dup /= OkToDup; that is caught earlier by contIsDupable
- do { let (dmd:_) = dmds -- Never fails
- ; (floats1, cont') <- mkDupableContWithDmds env dmds cont
+ do { let (dmd:cont_dmds) = dmds -- Never fails
+ ; (floats1, cont') <- mkDupableContWithDmds env cont_dmds cont
; let env' = env `setInScopeFromF` floats1
; (_, se', arg') <- simplArg env' dup se arg
; (let_floats2, arg'') <- makeTrivial env NotTopLevel dmd (fsLit "karg") arg'
```
Ticket #23184 is a report of the bug that this diff fixes.
(cherry picked from commit d97354a82b6f79c4d9a4d389fafdd94375454f59)
- - - - -
4f202c11 by Matthew Pickering at 2023-04-11T14:21:12+05:30
Backport fix to #23184 to 9.4
This backports the fix suggested in #23184 to GHC-9.4
It is from the larger patch (!7861):
```
commit 6656f0165a30fc2a22208532ba384fc8e2f11b46
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date: Fri Jul 23 23:57:01 2021 +0100
A bunch of changes related to eta reduction
This is a large collection of changes all relating to eta
reduction, originally triggered by #18993, but there followed
a long saga.
Specifics:
...lots of lines omitted...
Other incidental changes
* Fix a fairly long-standing outright bug in the ApplyToVal case of
GHC.Core.Opt.Simplify.mkDupableContWithDmds. I was failing to take the
tail of 'dmds' in the recursive call, which meant the demands were All
Wrong. I have no idea why this has not caused problems before now.
```
(cherry picked from commit d2dee3f82dcfdfc49cfb708222bb78aea0713cd6)
- - - - -
65ec3508 by Ben Gamari at 2023-04-11T14:21:12+05:30
rts: Don't rely on EXTERN_INLINE for slop-zeroing logic
Previously we relied on calling EXTERN_INLINE functions defined in
ClosureMacros.h from Cmm to zero slop. However, as far as I can tell,
this is no longer safe to do in C99 as EXTERN_INLINE definitions may be emitted
in each compilation unit.
Fix this by explicitly declaring a new set of non-inline functions in
ZeroSlop.c which can be called from Cmm and marking the ClosureMacros.h
definitions as INLINE_HEADER.
In the future we should try to eliminate EXTERN_INLINE.
(cherry picked from commit c6ec4cd1a94a1b76b7b094d5c92ee605031ecf60)
- - - - -
d5427586 by Ben Gamari at 2023-04-11T14:21:12+05:30
rts: Fix capability-count check in zeroSlop
Previously `zeroSlop` examined `RtsFlags` to determine whether the
program was single-threaded. This is wrong; a program may be started
with `+RTS -N1` yet the process may later increase the capability count
with `setNumCapabilities`. This lead to quite subtle and rare crashes.
Fixes #23088.
(cherry picked from commit c32abd4b936b3dfc61974ed5915c330fe7ed10d5)
- - - - -
776b960e by Ben Gamari at 2023-04-11T14:21:12+05:30
nonmoving: Disable slop-zeroing
As noted in #23170, the nonmoving GC can race with a mutator zeroing the
slop of an updated thunk (in much the same way that two mutators would
race). Consequently, we must disable slop-zeroing when the nonmoving GC
is in use.
Closes #23170
(cherry picked from commit d1bb16ed3e18a4f41fcfe31f0bf57dbaf589d6c5)
- - - - -
ba35912a by Simon Peyton Jones at 2023-04-11T14:21:12+05:30
Take more care with unlifted bindings in the specialiser
As #22998 showed, we were floating an unlifted binding to top
level, which breaks a Core invariant.
The fix is easy, albeit a little bit conservative. See
Note [Care with unlifted bindings] in GHC.Core.Opt.Specialise
(cherry picked from commit 7192ef91c855e1fae6997f75cfde76aafd0b4bcf)
- - - - -
68b24571 by Simon Peyton Jones at 2023-04-11T14:21:12+05:30
Make FloatIn robust to shadowing
This MR fixes #22622. See the new
Note [Shadowing and name capture]
I did a bit of refactoring in sepBindsByDropPoint too.
The bug doesn't manifest in HEAD, but it did show up in 9.4,
so we should backport this patch to 9.4
(cherry picked from commit 6206cb9287f3f6e70c669660a646a65274870d2b)
- - - - -
de176808 by Simon Peyton Jones at 2023-04-11T14:21:12+05:30
Fix void-arg-adding mechanism for worker/wrapper
As #22725 shows, in worker/wrapper we must add the void argument
/last/, not first. See GHC.Core.Opt.WorkWrap.Utils
Note [Worker/wrapper needs to add void arg last].
That led me to to study GHC.Core.Opt.SpecConstr
Note [SpecConstr needs to add void args first] which suggests the
opposite! And indeed I think it's the other way round for SpecConstr
-- or more precisely the void arg must precede the "extra_bndrs".
That led me to some refactoring of GHC.Core.Opt.SpecConstr.calcSpecInfo.
(cherry picked from commit 964284fcab6e27fe2fa5c279ea008551cbc15dbb)
- - - - -
60fe05c6 by Ben Gamari at 2023-04-11T14:21:12+05:30
rts: Statically assert alignment of Capability
In #22965 we noticed that changes in the size of `Capability` can result
in unsound behavior due to the `align` pragma claiming an alignment
which we don't in practice observe. Avoid this by statically asserting
that the size is a multiple of the alignment.
(cherry picked from commit db83f8bbf2e0ac68df675dea6b716fb7c19c649a)
- - - - -
a727929a by Ben Gamari at 2023-04-11T14:21:12+05:30
rts: Introduce getNumCapabilities
And ensure accesses to n_capabilities are atomic (although with relaxed
ordering). This is necessary as RTS API callers may concurrently call
into the RTS without holding a capability.
(cherry picked from commit 70999283156f527c5aea6dee57a3d14989a9903a)
- - - - -
7afce0a4 by Ben Gamari at 2023-04-11T14:21:12+05:30
rts: Introduce stgMallocAlignedBytes
(cherry picked from commit 5f7a4a6d8311d2faa9c90b2b0c4431dd4427839d)
- - - - -
1de84de2 by Ben Gamari at 2023-04-11T14:21:12+05:30
rts: Correctly align Capability allocations
Previously we failed to tell the C allocator that `Capability`s needed
to be aligned, resulting in #22965.
Fixes #22965.
Fixes #22975.
(cherry picked from commit 8a6f745d963fc9b79c7b1e4b477f4fc724233655)
- - - - -
98d49908 by Ben Gamari at 2023-04-11T14:21:12+05:30
rts: Drop no-alignment special case for Windows
For reasons that aren't clear, we were previously not giving Capability
the same favorable alignment on Windows that we provided on other
platforms. Fix this.
(cherry picked from commit 5464c73f192f76e75160e8992fe9720d943ae611)
- - - - -
f8e88ac9 by Andreas Klebinger at 2023-04-11T14:21:12+05:30
Only gc sparks locally when we can ensure marking is done.
When performing GC without work stealing there was no guarantee that
spark pruning was happening after marking of the sparks. This could
cause us to GC live sparks under certain circumstances.
Fixes #22528.
(cherry picked from commit a1491c8791c57a64d94bc08d639d585815c8d4e2)
- - - - -
6a8c8153 by Ryan Scott at 2023-04-11T14:21:12+05:30
Windows: Remove mingwex dependency
The clang based toolchain uses ucrt as its math library
and so mingwex is no longer needed. In fact using mingwex
will cause incompatibilities as the default routines in both
have differing ULPs and string formatting modifiers.
```
$ LIBRARY_PATH=/mingw64/lib ghc/_build/stage1/bin/ghc Bug.hs -fforce-recomp && ./Bug.exe
[1 of 2] Compiling Main ( Bug.hs, Bug.o )
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `__imp___p__environ'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `__hscore_get_errno'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_ForeignziCziError_errnoToIOError_info'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziWindows_failIf2_closure'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziEncodingziCodePageziAPI_mkCodePageEncoding_info'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziEncodingziCodePage_currentCodePage_closure'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziEncoding_getForeignEncoding_closure'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_ForeignziCziString_withCStringLen1_info'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziHandleziInternals_zdwflushCharReadBuffer_info'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziHandleziText_hGetBuf1_info'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziFingerprint_fingerprintString_closure'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_DataziTypeableziInternal_mkTrCon_closure'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziException_errorCallWithCallStackException_closure'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziErr_error_info'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\template-haskell-2.19.0.0\libHStemplate-haskell-2.19.0.0.a: unknown symbol `base_DataziMaybe_fromJust1_info'
ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\template-haskell-2.19.0.0\libHStemplate-haskell-2.19.0.0.a: unknown symbol `templatezmhaskell_LanguageziHaskellziTHziSyntax_IntPrimL_con_info'
ghc.exe: ^^ Could not load 'templatezmhaskell_LanguageziHaskellziTHziLibziInternal_stringL_closure', dependency unresolved. See top entry above.
<no location info>: error:
GHC.ByteCode.Linker.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
templatezmhaskell_LanguageziHaskellziTHziLibziInternal_stringL_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please report this as a GHC bug:
https://www.haskell.org/ghc/reportabug
```
(cherry picked from commit de1d15127ac3f41ac3044215b0ea3398a36edc89)
- - - - -
3e737ee4 by Tamar Christina at 2023-04-11T14:21:12+05:30
linker: Fix BFD import libraries
This commit fixes the BFD style import library support in the runtime
linker. This was accidentally broken during the refactoring to clang
and went unnoticed because clang itself is unable to generate the BFD
style import libraries.
With this change we can not link against both GCC or Clang produced
libraries again and intermix code produced by both compilers.
(cherry picked from commit 48e391952c17ff7eab10b0b1456e3f2a2af28a9b)
- - - - -
93dce14f by Ben Gamari at 2023-04-11T14:21:12+05:30
Bump Windows toolchain
Updates to LLVM 14, hopefully fixing #21964.
- - - - -
6b286fe2 by Zubin Duggal at 2023-04-11T14:21:13+05:30
base: Remove HAVE_* CPP guards
- - - - -
697e9f16 by Zubin Duggal at 2023-04-11T14:21:13+05:30
lint-notes: accept output
- - - - -
9e24ef67 by Ben Gamari at 2023-04-11T14:21:13+05:30
hadrian: Extend xattr Darwin hack to cover /lib
As noted in #21506, it is now necessary to remove extended attributes
from `/lib` as well as `/bin` to avoid SIP issues on Darwin.
Fixes #21506.
(cherry picked from commit 78d04cfadfd728bb088b08b1e88905b43cc0360c)
- - - - -
30 changed files:
- .gitlab-ci.yml
- compiler/GHC/ByteCode/Types.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Opt/FloatIn.hs
- compiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Opt/Specialise.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Unify.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/Driver/Errors/Ppr.hs
- compiler/GHC/Driver/Errors/Types.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Usage.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Iface/Load.hs
- compiler/GHC/Iface/Recomp.hs
- compiler/GHC/Iface/Tidy.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Runtime/Eval.hs
- compiler/GHC/StgToByteCode.hs
- compiler/GHC/Tc/Gen/Arrow.hs
- compiler/GHC/Tc/Gen/Bind.hs
- compiler/GHC/Tc/Gen/Match.hs
- compiler/GHC/Tc/Gen/Match.hs-boot
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/cf44469945d4059d70127c22372b9c2170dc9a34...9e24ef678d655f826d1567b95801b2305eff566d
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/cf44469945d4059d70127c22372b9c2170dc9a34...9e24ef678d655f826d1567b95801b2305eff566d
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/20230411/dd51f9eb/attachment-0001.html>
More information about the ghc-commits
mailing list