[Git][ghc/ghc][wip/ghc-9.4.5-backports] 50 commits: hadrian bindist: Install manpages to share/man/man1/ghc.1
Zubin (@wz1000)
gitlab at gitlab.haskell.org
Tue Apr 11 11:15:31 UTC 2023
Zubin pushed to branch wip/ghc-9.4.5-backports at Glasgow Haskell Compiler / GHC
Commits:
5a278522 by Matthew Pickering at 2023-04-11T16:44:41+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)
- - - - -
b43896ea by Matthew Pickering at 2023-04-11T16:44:41+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)
- - - - -
59214122 by Matthew Pickering at 2023-04-11T16:44:41+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)
- - - - -
e6ec408e by Matthew Pickering at 2023-04-11T16:44:41+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)
- - - - -
52be078b by Matthew Pickering at 2023-04-11T16:44:41+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)
- - - - -
54010624 by Matthew Pickering at 2023-04-11T16:44:41+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)
- - - - -
64a60b3d by Matthew Pickering at 2023-04-11T16:44:41+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)
- - - - -
429c8d2d by Matthew Pickering at 2023-04-11T16:44:41+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)
- - - - -
babd33d9 by Matthew Pickering at 2023-04-11T16:44:41+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)
- - - - -
3b0d9f8c by Matthew Pickering at 2023-04-11T16:44:41+05:30
Debug: Print full NodeKey when pretty printing ModuleGraphNode
This is helpful when debugging multiple component issues.
(cherry picked from commit be701cc64f0ff78aa50bcd7293d8692dc1ba6c85)
- - - - -
375fae2f by Simon Peyton Jones at 2023-04-11T16:44:41+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)
- - - - -
f2f46364 by Matthew Pickering at 2023-04-11T16:44:41+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)
- - - - -
b22e4bda by Matthew Pickering at 2023-04-11T16:44:41+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)
- - - - -
d3768c41 by Matthew Pickering at 2023-04-11T16:44:41+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)
- - - - -
b7ebc474 by Matthew Pickering at 2023-04-11T16:44:42+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)
- - - - -
744464c3 by Matthew Pickering at 2023-04-11T16:44:42+05:30
Strict fields in ModNodeKey (otherwise retains HomeModInfo)
Towards #22530
(cherry picked from commit f2a0fea09a88693d876fb891ea7c8c97373c4aa6)
- - - - -
53c4d24f by Krzysztof Gogolewski at 2023-04-11T16:44:42+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)
- - - - -
bbfe16dc by Simon Peyton Jones at 2023-04-11T16:44:42+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)
- - - - -
dd847c14 by sheaf at 2023-04-11T16:44:42+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)
- - - - -
3247e44a by Sylvain Henry at 2023-04-11T16:44:42+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)
- - - - -
35b059d8 by Sylvain Henry at 2023-04-11T16:44:42+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)
- - - - -
9e07003f by Sylvain Henry at 2023-04-11T16:44:42+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)
- - - - -
69ab7f35 by Sylvain Henry at 2023-04-11T16:44:42+05:30
configure: support "windows" as an OS
(cherry picked from commit 2fdf22aebda2307d86872c792633d1856d666c9b)
- - - - -
5e102834 by Ben Gamari at 2023-04-11T16:44:42+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)
- - - - -
ddf602f0 by Ben Gamari at 2023-04-11T16:44:42+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)
- - - - -
60372935 by Ben Gamari at 2023-04-11T16:44:42+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)
- - - - -
5d036a5a by Ben Gamari at 2023-04-11T16:44:42+05:30
Bump gmp-tarballs submodule
This backports the upstream fix for CVE-2021-43618, fixing #22789.
(cherry picked from commit b13c6ea5d4b64841164f8cc58d6c6f3de390f2ed)
- - - - -
98b09661 by Li-yao Xia at 2023-04-11T16:44:42+05:30
base: Move changelog entry to its place
(cherry picked from commit 11de324aae17794c8753a8f7cb50c4140785fe27)
- - - - -
850c5ad3 by Matthew Pickering at 2023-04-11T16:44:42+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)
- - - - -
b9d38595 by Matthew Pickering at 2023-04-11T16:44:42+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)
- - - - -
7d9de292 by Ben Gamari at 2023-04-11T16:44:42+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)
- - - - -
b64260bc by Ben Gamari at 2023-04-11T16:44:42+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)
- - - - -
55392bee by Ben Gamari at 2023-04-11T16:44:42+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)
- - - - -
98f45e6f by Simon Peyton Jones at 2023-04-11T16:44:42+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)
- - - - -
29236f70 by Simon Peyton Jones at 2023-04-11T16:44:42+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)
- - - - -
602bc279 by Simon Peyton Jones at 2023-04-11T16:44:43+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)
- - - - -
9de197b8 by Ben Gamari at 2023-04-11T16:44:43+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)
- - - - -
36611c83 by Ben Gamari at 2023-04-11T16:44:43+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)
- - - - -
874d956b by Ben Gamari at 2023-04-11T16:44:43+05:30
rts: Introduce stgMallocAlignedBytes
(cherry picked from commit 5f7a4a6d8311d2faa9c90b2b0c4431dd4427839d)
- - - - -
00797e00 by Ben Gamari at 2023-04-11T16:44:43+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)
- - - - -
69644eb3 by Ben Gamari at 2023-04-11T16:44:43+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)
- - - - -
ece2324c by Andreas Klebinger at 2023-04-11T16:44:43+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)
- - - - -
c6b63a85 by Ryan Scott at 2023-04-11T16:44:43+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)
- - - - -
eaeaa979 by Tamar Christina at 2023-04-11T16:44:43+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)
- - - - -
0b7e51ce by Ben Gamari at 2023-04-11T16:44:43+05:30
Bump Windows toolchain
Updates to LLVM 14, hopefully fixing #21964.
- - - - -
08bc1d16 by Zubin Duggal at 2023-04-11T16:44:43+05:30
base: Remove HAVE_* CPP guards
- - - - -
ded80fd0 by Zubin Duggal at 2023-04-11T16:44:43+05:30
lint-notes: accept output
- - - - -
81fff329 by Ben Gamari at 2023-04-11T16:44:44+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)
- - - - -
962acddb by Zubin Duggal at 2023-04-11T16:44:44+05:30
ci: debug
- - - - -
02e1f7a1 by Zubin Duggal at 2023-04-11T16:44:44+05:30
ci: lint-ci-config: remove line metioning nix from cabal.config
- - - - -
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/65a9d0230d912dd023642abd778e9edb55368b88...02e1f7a104f7aae90da19bcc3e74f15cdd582d86
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/65a9d0230d912dd023642abd778e9edb55368b88...02e1f7a104f7aae90da19bcc3e74f15cdd582d86
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/774b54e2/attachment-0001.html>
More information about the ghc-commits
mailing list