[Git][ghc/ghc][wip/T22431] 50 commits: Implement DeepSubsumption
Ben Gamari (@bgamari)
gitlab at gitlab.haskell.org
Tue Dec 20 00:11:43 UTC 2022
Ben Gamari pushed to branch wip/T22431 at Glasgow Haskell Compiler / GHC
Commits:
118cf5a1 by Simon Peyton Jones at 2022-07-26T16:27:36+05:30
Implement DeepSubsumption
This MR adds the language extension -XDeepSubsumption, implementing
GHC proposal #511. This change mitigates the impact of GHC proposal
The changes are highly localised, by design. See Note [Deep subsumption]
in GHC.Tc.Utils.Unify.
The main changes are:
* Add -XDeepSubsumption, which is on by default in Haskell98 and Haskell2010,
but off in Haskell2021.
-XDeepSubsumption largely restores the behaviour before the "simple subsumption" change.
-XDeepSubsumpition has a similar flavour as -XNoMonoLocalBinds:
it makes type inference more complicated and less predictable, but it
may be convenient in practice.
* The main changes are in:
* GHC.Tc.Utils.Unify.tcSubType, which does deep susumption and eta-expanansion
* GHC.Tc.Utils.Unify.tcSkolemiseET, which does deep skolemisation
* In GHC.Tc.Gen.App.tcApp we call tcSubTypeNC to match the result
type. Without deep subsumption, unifyExpectedType would be sufficent.
See Note [Deep subsumption] in GHC.Tc.Utils.Unify.
* There are no changes to Quick Look at all.
* The type of `withDict` becomes ambiguous; so add -XAllowAmbiguousTypes to
GHC.Magic.Dict
* I fixed a small but egregious bug in GHC.Core.FVs.varTypeTyCoFVs, where
we'd forgotten to take the free vars of the multiplicity of an Id.
(cherry picked from commit 7b9be6c8b94b3c2eb3441febb4a8005a03fa34a5)
(cherry picked from commit 71f740097af92b0ba441154736a21484fce5d0bb)
(cherry picked from commit dc27e15a76486b1ebd27a77f8515044c2671e22d)
- - - - -
5eae0982 by Matthew Pickering at 2022-07-26T16:28:08+05:30
Fix tcSplitNestedSigmaTys
When I did the shallow-subusmptuion patch
commit 2b792facab46f7cdd09d12e79499f4e0dcd4293f
Date: Sun Feb 2 18:23:11 2020 +0000
Simple subsumption
I changed tcSplitNestedSigmaTys to not look through function arrows
any more. But that was actually an un-forced change. This function
is used only in
* Improving error messages in GHC.Tc.Gen.Head.addFunResCtxt
* Validity checking for default methods: GHC.Tc.TyCl.checkValidClass
* A couple of calls in the GHCi debugger: GHC.Runtime.Heap.Inspect
all to do with validity checking and error messages. Acutally its
fine to look under function arrows here, and quite useful a test
DeepSubsumption05 (a test motivated by a build failure in the
`lens` package) shows.
The fix is easy. I added Note [tcSplitNestedSigmaTys].
(cherry picked from commit 936fe7435d9da63f78c032b027179e1f1f22a482)
(cherry picked from commit 58ad696d42316b1a89a3ce8324218a0ad7257b8e)
(cherry picked from commit dc27e15a76486b1ebd27a77f8515044c2671e22d)
- - - - -
af84a211 by Zubin Duggal at 2022-07-26T16:28:48+05:30
Accept testsuite output for DeepSubsumption
- - - - -
f1b85d40 by Matthew Pickering at 2022-07-26T16:28:48+05:30
Add tests that -XHaskell98 and -XHaskell2010 enable DeepSubsumption
(cherry picked from commit 5c4fbaf53f258d64aeb66a8172e13dc559eb8d8b)
- - - - -
a989d1a2 by Matthew Pickering at 2022-07-26T16:28:48+05:30
Add DeepSubsumption08
(cherry picked from commit 671899858585376dcbbbdc3740dad4b8ec7b6a70)
- - - - -
c1e9dc7c by Simon Peyton Jones at 2022-07-26T16:28:48+05:30
Fix the interaction of operator sections and deep subsumption
Fixes DeepSubsumption08
(cherry picked from commit 5e93a9521fc2220ee6f4f150c6681f84f33a2134)
- - - - -
b51d0ead by Zubin Duggal at 2022-07-26T16:28:48+05:30
Add DeepSubsumption09
(cherry picked from commit 918620d9e2f9e4a0122c57d7fdddbe34626f34b0)
- - - - -
42841ac3 by Matthew Pickering at 2022-07-26T16:28:48+05:30
Allow CApi FFI calls in GHCi
At some point in the past this started working. I noticed this when
working on multiple home units and couldn't load GHC's dependencies into
the interpreter.
Fixes #7388
(cherry picked from commit be3750a5a3cbc59a7b84f1f7603f308aee1cc80b)
- - - - -
7268f1b3 by Zubin Duggal at 2022-07-26T16:28:48+05:30
Fix potential space leak that arise from ModuleGraphs retaining references
to previous ModuleGraphs. This manifests in particular in `extendMG`.
This patch is a backport of !8579
(cherry picked from commit 68e1e1842140c783542bcfdcd49cef538c6ab13d)
- - - - -
e6e0c49d by Tamar Christina at 2022-07-26T16:28:48+05:30
winio: make consoleReadNonBlocking not wait for any events at all.
(cherry picked from commit fa59223b05e24d6e477e3ab0ab296e32b2b65a8b)
- - - - -
959641a4 by Ben Gamari at 2022-07-26T16:28:48+05:30
configure: Don't attempt to override linker on Darwin
Configure's --enable-ld-override functionality is intended to ensure
that we don't rely on ld.bfd, which tends to be slow and buggy, on
Linux and Windows. However, on Darwin the lack of sensible package
management makes it extremely easy for users to have awkward mixtures of
toolchain components from, e.g., XCode, the Apple Command-Line Tools
package, and homebrew. This leads to extremely confusing problems
like #21712.
Here we avoid this by simply giving up on linker selection on Darwin
altogether. This isn't so bad since the Apple ld64 linker has decent
performance and AFAICT fairly reliable.
Closes #21712.
(cherry picked from commit bde65ea90ed61696eefc93c83efddf7af68d413e)
- - - - -
d1c82a8d by Zubin Duggal at 2022-07-26T16:28:49+05:30
Bump version to GHC 9.2.4
- - - - -
ab1b9d8f by Zubin Duggal at 2022-07-26T16:28:49+05:30
Bump base to 4.16.3.0 and add changelog
- - - - -
bb2153b1 by Colten Webb at 2022-07-26T16:28:49+05:30
Compute record-dot-syntax types
Ensures type information for record-dot-syntax
is included in HieASTs. See #21797
(cherry picked from commit 5434d1a355e127d44c6f116b4b7f8a1d254815d4)
- - - - -
be800541 by Colten Webb at 2022-07-26T16:28:49+05:30
Add record-dot-syntax test
(cherry picked from commit 89d169ec0c4e9c1e6cf4a6373a1992dad7474d55)
- - - - -
5e8950f7 by Zubin Duggal at 2022-07-26T16:28:49+05:30
Bump haddock submodule
- - - - -
e3a33326 by Ben Gamari at 2022-07-26T16:28:49+05:30
testsuite: introduce nonmoving_thread_sanity way
(cherry picked from commit 19f8fce3659de3d72046bea9c61d1a82904bc4ae)
- - - - -
c7dfabd9 by Ben Gamari at 2022-07-26T16:28:49+05:30
rts/nonmoving: Track segment state
It can often be useful during debugging to be able to determine the
state of a nonmoving segment. Introduce some state, enabled by DEBUG, to
track this.
(cherry picked from commit 40e797ef591ae3122ccc98ab0cc3cfcf9d17bd7f)
- - - - -
357d2d5a by Ben Gamari at 2022-07-26T16:28:49+05:30
rts/nonmoving: Don't scavenge objects which weren't evacuated
This fixes a rather subtle bug in the logic responsible for scavenging
objects evacuated to the non-moving generation. In particular, objects
can be allocated into the non-moving generation by two ways:
a. evacuation out of from-space by the garbage collector
b. direct allocation by the mutator
Like all evacuation, objects moved by (a) must be scavenged, since they
may contain references to other objects located in from-space. To
accomplish this we have the following scheme:
* each nonmoving segment's block descriptor has a scan pointer which
points to the first object which has yet to be scavenged
* the GC tracks a set of "todo" segments which have pending scavenging
work
* to scavenge a segment, we scavenge each of the unmarked blocks
between the scan pointer and segment's `next_free` pointer.
We skip marked blocks since we know the allocator wouldn't have
allocated into marked blocks (since they contain presumably live
data).
We can stop at `next_free` since, by
definition, the GC could not have evacuated any objects to blocks
above `next_free` (otherwise `next_free wouldn't be the first free
block).
However, this neglected to consider objects allocated by path (b).
In short, the problem is that objects directly allocated by the mutator
may become unreachable (but not swept, since the containing segment is
not yet full), at which point they may contain references to swept objects.
Specifically, we observed this in #21885 in the following way:
1. the mutator (specifically in #21885, a `lockCAF`) allocates an object
(specifically a blackhole, which here we will call `blkh`; see Note
[Static objects under the nonmoving collector] for the reason why) on
the non-moving heap. The bitmap of the allocated block remains 0
(since allocation doesn't affect the bitmap) and the containing
segment's (which we will call `blkh_seg`) `next_free` is advanced.
2. We enter the blackhole, evaluating the blackhole to produce a result
(specificaly a cons cell) in the nursery
3. The blackhole gets updated into an indirection pointing to the cons
cell; it is pushed to the generational remembered set
4. we perform a GC, the cons cell is evacuated into the nonmoving heap
(into segment `cons_seg`)
5. the cons cell is marked
6. the GC concludes
7. the CAF and blackhole become unreachable
8. `cons_seg` is filled
9. we start another GC; the cons cell is swept
10. we start a new GC
11. something is evacuated into `blkh_seg`, adding it to the "todo" list
12. we attempt to scavenge `blkh_seg` (namely, all unmarked blocks
between `scan` and `next_free`, which includes `blkh`). We attempt to
evacuate `blkh`'s indirectee, which is the previously-swept cons cell.
This is unsafe, since the indirectee is no longer a valid heap
object.
The problem here was that the scavenging logic *assumed* that (a) was
the only source of allocations into the non-moving heap and therefore
*all* unmarked blocks between `scan` and `next_free` were evacuated.
However, due to (b) this is not true.
The solution is to ensure that that the scanned region only encompasses
the region of objects allocated during evacuation. We do this by
updating `scan` as we push the segment to the todo-segment list to
point to the block which was evacuated into.
Doing this required changing the nonmoving scavenging implementation's
update of the `scan` pointer to bump it *once*, instead of after
scavenging each block as was done previously. This is because we may end
up evacuating into the segment being scavenged as we scavenge it. This
was quite tricky to discover but the result is quite simple,
demonstrating yet again that global mutable state should be used
exceedingly sparingly.
Fixes #21885
(cherry picked from commit 0b27ea23efcb08639309293faf13fdfef03f1060)
- - - - -
32ce337d by Ben Gamari at 2022-07-26T16:28:49+05:30
testsuite: Skip a few tests as in the nonmoving collector
Residency monitoring under the non-moving collector is quite
conservative (e.g. the reported value is larger than reality) since
otherwise we would need to block on concurrent collection. Skip a few
tests that are sensitive to residency.
(cherry picked from commit 6880e4fbf728c04e8ce83e725bfc028fcb18cd70)
- - - - -
260f557f by Ben Gamari at 2022-07-26T16:28:49+05:30
Make keepAlive# out-of-line
This is a naive approach to fixing the unsoundness noticed in #21708.
Specifically, we remove the lowering of `keepAlive#` via CorePrep and
instead turn it into an out-of-line primop.
This is simple, inefficient (since the continuation must now be heap
allocated), but good enough for 9.4.1. We will revisit this
(particiularly via #16098) in a future release.
Metric Increase:
T4978
T7257
T9203
(cherry picked from commit d75c540d439510491b45f64c1113762dcb251ae1)
(cherry picked from commit 45a5ce96ccb1f4931205d5aba0733a2ef7efbaf5)
- - - - -
d9665a3b by Zubin Duggal at 2022-07-26T16:34:00+05:30
Fix #21865 by adding -Wunicode-bidirectional-format-characters to default warnings.
The previous backport in 0255ef38b1bb0d4f3608bf92ebc8a93955ccb30a was flawed because
it left this out.
- - - - -
786ba795 by Zubin Duggal at 2022-07-26T21:17:57+05:30
Add test for #21865 to ensure that -Wunicode-bidirectional-format-characters is on by default
- - - - -
65d61702 by Ben Gamari at 2022-07-27T01:58:03+05:30
rts/ProfHeap: Ensure new Censuses are zeroed
When growing the Census array ProfHeap previously neglected to
zero the new part of the array. Consequently `freeEra` would attempt to
free random words that often looked suspiciously like pointers.
Fixes #21880.
(cherry picked from commit e2f0094c315746ff15b8d9650cf318f81d8416d7)
- - - - -
0841f14d by Zubin Duggal at 2022-07-27T01:58:03+05:30
Fix #21889, GHCi misbehaves with Ctrl-C on Windows
On Windows, we create multiple levels of wrappers for GHCi which ultimately
execute ghc --interactive. In order to handle console events properly, each of
these wrappers must call FreeConsole() in order to hand off event processing to
the child process. See #14150.
In addition to this, FreeConsole must only be called from interactive processes (#13411).
This commit makes two changes to fix this situation:
1. The hadrian wrappers generated using `hadrian/bindist/cwrappers/version-wrapper.c` call `FreeConsole`
if the CPP flag INTERACTIVE_PROCESS is set, which is set when we are generating a wrapper for GHCi.
2. The GHCi wrapper in `driver/ghci/` calls the `ghc-$VER.exe` executable which is not wrapped rather
than calling `ghc.exe` is is wrapped on windows (and usually non-interactive, so can't call `FreeConsole`:
Before:
ghci-$VER.exe calls ghci.exe which calls ghc.exe which calls ghc-$VER.exe
After:
ghci-$VER.exe calls ghci.exe which calls ghc-$VER.exe
(cherry picked from commit 3bbde95769aa2986adb8bef7d718aa0e8731f9fd)
- - - - -
92d385b7 by Andreas Klebinger at 2022-07-27T01:58:03+05:30
exprIsDeadEnd: Use isDeadEndAppSig to check if a function appliction is bottoming.
We used to check the divergence and that the number of arguments > arity.
But arity zero represents unknown arity so this was subtly broken for a long time!
We would check if the saturated function diverges, and if we applied >=arity arguments.
But for unknown arity functions any number of arguments is >=idArity.
This fixes #21440.
(cherry picked from commit edb81f4ed82e6317b03a0c540e1adca194da38d7)
- - - - -
f2069c48 by Zubin Duggal at 2022-07-27T01:58:17+05:30
Add release notes for 9.2.4
- - - - -
a54827e0 by Zubin Duggal at 2022-07-27T12:22:47+05:30
Allow stat increases for GHC 9.2
Metric Increase:
T13701
T14697
- - - - -
8b839c33 by Zubin Duggal at 2022-10-11T11:12:07+01:00
Revert "Fix combination of ArityType in andArityType"
This reverts commit 74ef2853464255a86d88fda619eb68b08b52e689.
- - - - -
c45387ce by Simon Peyton Jones at 2022-10-26T15:39:08+05:30
Fix arityType: -fpedantic-bottoms, join points, etc
This MR fixes #21694 and #21755
* For #21694 the underlying problem was that we were calling arityType
on an expression that had free join points. This is a Bad Bad Idea.
See Note [No free join points in arityType].
* I also made andArityType work correctly with -fpedantic-bottoms;
see Note [Combining case branches: andWithTail].
* I realised that, now we have ae_sigs giving the ArityType for
let-bound Ids, we don't need the (pre-dating) special code in
arityType for join points. But instead we need to extend the env for
Rec bindings, which weren't doing before. More uniform now. See
Note [arityType for let-bindings].
This meant we could get rid of ae_joins, and in fact get rid of
EtaExpandArity altogether. Simpler.
And finally, it was the strange treatment of join-point Ids (involving
a fake ABot type) that led to a serious bug: #21755. Fixed by this
refactoring
* Rewrote Note [Combining case branches: optimistic one-shot-ness]
Compile time improves slightly on average:
Metrics: compile_time/bytes allocated
---------------------------------------------------------------------------------------
CoOpt_Read(normal) ghc/alloc 803,788,056 747,832,680 -7.1% GOOD
T18223(normal) ghc/alloc 928,207,320 959,424,016 +3.1% BAD
geo. mean -0.3%
minimum -7.1%
maximum +3.1%
On Windows it's a bit better: geo mean is -0.6%, and three more
benchmarks trip their compile-time bytes-allocated threshold (they
were all close on the other build):
T18698b(normal) ghc/alloc 235,619,776 233,219,008 -1.0% GOOD
T6048(optasm) ghc/alloc 112,208,192 109,704,936 -2.2% GOOD
T18140(normal) ghc/alloc 85,064,192 83,168,360 -2.2% GOOD
I had a quick look at T18223 but it is knee deep in coercions and
the size of everything looks similar before and after. I decided
to accept that 3.4% increase in exchange for goodness elsewhere.
Metric Decrease:
CoOpt_Read
T18140
T18698b
T6048
Metric Increase:
T18223
- - - - -
8a38c548 by Ben Gamari at 2022-10-26T15:39:08+05:30
rts: Don't clear cards of zero-length arrays
Fix #21962, where attempting to clear the card table of a zero-length
array resulted in an integer underflow.
- - - - -
17552468 by Cheng Shao at 2022-10-26T15:39:08+05:30
rts: fix missing dirty_MVAR argument in stg_writeIOPortzh
(cherry picked from commit ee471dfb8a4a4bb5131a5baa61d1d0d22c933d5f)
- - - - -
4d047b3c by Matthew Pickering at 2022-10-26T15:39:08+05:30
Don't include BufPos in interface files
Ticket #22162 pointed out that the build directory was leaking into the
ABI hash of a module because the BufPos depended on the location of the
build tree.
BufPos is only used in GHC.Parser.PostProcess.Haddock, and the
information doesn't need to be propagated outside the context of a
module.
Fixes #22162
(cherry picked from commit 7f0decd5063a853fc8f38a8944b2c91995cd5e48)
- - - - -
9e254001 by Ben Gamari at 2022-10-26T15:39:08+05:30
ncg/aarch64: Fix sub-word sign extension yet again
In adc7f108141a973b6dcb02a7836eed65d61230e8 we fixed a number of issues
to do with sign extension in the AArch64 NCG found by ghc/test-primops>.
However, this patch made a critical error, assuming that getSomeReg
would allocate a fresh register for the result of its evaluation.
However, this is not the case as `getSomeReg (CmmReg r) == r`.
Consequently, any mutation of the register returned by `getSomeReg` may
have unwanted side-effects on other expressions also mentioning `r`. In
the fix listed above, this manifested as the registers containing the
operands of binary arithmetic operations being incorrectly
sign-extended. This resulted in #22282.
Sadly, the rather simple structure of the tests generated
by `test-primops` meant that this particular case was not exercised.
Even more surprisingly, none of our testsuite caught this case.
Here we fix this by ensuring that intermediate sign extension is
performed in a fresh register.
Fixes #22282.
(cherry picked from commit 62a550010ed94e1969c96150f2781854a0802766)
- - - - -
74e329d2 by Ben Gamari at 2022-10-26T15:39:08+05:30
testsuite: Add test for #22282
This will complement mpickering's more general port of foundation's
numerical testsuite, providing a test for the specific case found
in #22282.
(cherry picked from commit 8eff62a43cebbb21f00aeea138bcc343d8ac8f34)
- - - - -
064371d3 by Douglas Wilson at 2022-10-26T15:39:09+05:30
testsuite: 21651 add test for closeFdWith + setNumCapabilities
This bug does not affect windows, which does not use the
base module GHC.Event.Thread.
(cherry picked from commit 76b52cf0c52ee05c20f7d1b80f5600eecab3c42a)
- - - - -
2821391a by Douglas Wilson at 2022-10-26T15:39:09+05:30
base: Fix races in IOManager (setNumCapabilities,closeFdWith)
Fix for #21651
Fixes three bugs:
- writes to eventManager should be atomic. It is accessed concurrently by ioManagerCapabilitiesChanged and closeFdWith.
- The race in closeFdWith described in the ticket.
- A race in getSystemEventManager where it accesses the 'IOArray' in
'eventManager' before 'ioManagerCapabilitiesChanged' has written to
'eventManager', causing an Array Index exception. The fix here is to
'yield' and retry.
(cherry picked from commit 7589ee7241d46b393979d98d4ded17a15ee974fb)
- - - - -
7ad76d79 by Tamar Christina at 2022-10-26T15:39:09+05:30
winio: do not re-translate input when handle is uncooked
(cherry picked from commit 626652f7c172f307bd87afaee59c7f0e2825c55d)
- - - - -
63fe2ee2 by Sebastian Graf at 2022-11-03T14:21:10+05:30
Rubbish literals for all representations (#18983)
This patch cleans up the complexity around WW's `mk_absent_let` by
broadening the scope of `LitRubbish`. Rubbish literals now store the
`PrimRep` they represent and are ultimately lowered in Cmm.
This in turn allows absent literals of `VecRep` or `VoidRep`. The latter
allows absent literals for unlifted coercions, as requested in #18983.
I took the liberty to rewrite and clean up `Note [Absent fillers]` and
`Note [Rubbish values]` to account for the new implementation and to
make them more orthogonal in their description.
I didn't add a new regression test, as `T18982` already contains the
test in the ticket and its test output changes as expected.
Fixes #18983.
- - - - -
1fabaae4 by Dai at 2022-11-03T15:12:38+05:30
Add VecSlot for unboxed sums of SIMD vectors
This patch adds the missing `VecRep` case to `primRepSlot` function and
all the necessary machinery to carry this new `VecSlot` through code
generation. This allows programs involving unboxed sums of SIMD vectors
to be written and compiled.
Fixes #22187
(cherry picked from commit 5b3a992f5d166007c3c5a22f120ed08e0a27f01a)
- - - - -
9d469bff by sheaf at 2022-11-03T15:12:38+05:30
Cmm Lint: relax SIMD register assignment check
As noted in #22297, SIMD vector registers can be used
to store different kinds of values, e.g. xmm1 can be used
both to store integer and floating point values.
The Cmm type system doesn't properly account for this, so
we weaken the Cmm register assignment lint check to only
compare widths when comparing a vector type with its
allocated vector register.
(cherry picked from commit 3be48877e204fca8e5d5ab984186e0d20d81f262)
- - - - -
14e0442e by sheaf at 2022-11-03T15:12:38+05:30
Disable some SIMD tests on non-X86 architectures
(cherry picked from commit f7b7a3122185222d5059e37315991afcf319e43c)
- - - - -
45459cce by Zubin Duggal at 2022-11-03T15:12:38+05:30
Bump process to 1.6.16.0
- - - - -
5674eb8b by Zubin Duggal at 2022-11-03T15:12:38+05:30
Attemp fix for core lint failures
For an expression:
joinrec foo = ... in expr
we compute the arityType as `foldr andArityType (arityType expr) [arityType foo]`
which is the same as `andArityType (arityType expr) (arityType foo)`. However,
this is incorrect:
joinrec go x = ... in go 0
then the arity of go is 1 (\?. T), but the arity of the overall expression is
0 (_|_). `andArityType` however returns (\?. T) for these, which is wrong.
(cherry picked from commit 53235edd478bd4c5e29e4f254ce02559af259dd5)
- - - - -
36cfeb7c by Zubin Duggal at 2022-11-03T15:12:38+05:30
Bump base to 4.16.4.0 and add release notes
- - - - -
3588c3a9 by Zubin Duggal at 2022-11-03T15:12:38+05:30
Fix bkpcabal02
- - - - -
c35d3f80 by Zubin Duggal at 2022-11-03T17:15:22+05:30
Fix core lint errors to do with SIMD vector indexing in T22187_run.
This patch was originally from 6d7d91817795d7ee7f45557411368a1738daa488,
but all the changes in that commit can't make it because we don't want to
change the interface of primops in a backport.
- - - - -
784324bc by Zubin Duggal at 2022-11-04T15:39:38+05:30
Add notes for 9.2.5
- - - - -
74ca6191 by normalcoder at 2022-11-07T00:06:37+05:30
ncg/aarch64: Don't use x18 register on AArch64/Darwin
Apple's ABI documentation [1] says: "The platforms reserve register x18.
Don’t use this register." While this wasn't problematic in previous
Darwin releases, macOS 13 appears to start zeroing this register
periodically. See #21964.
[1] https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms
(cherry picked from commit 67575f2004340564d6e52af055ed6fb43d3f9711)
- - - - -
f95de6f5 by Matthew Pickering at 2022-12-19T19:11:36-05:00
Fix gen_contents_index logic for hadrian bindist
(cherry picked from commit 5b35ca58d94d07751ef2f810686f588ce9c0878a)
- - - - -
30 changed files:
- compiler/GHC/Builtin/Types/Prim.hs
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/Cmm/LayoutStack.hs
- compiler/GHC/Cmm/Lint.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/Utils.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/FVs.hs
- compiler/GHC/Core/Make.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToStg.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Data/IOEnv.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Iface/Ext/Types.hs
- compiler/GHC/Iface/Tidy.hs
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/Stg/Unarise.hs
- compiler/GHC/StgToByteCode.hs
- compiler/GHC/StgToCmm/ArgRep.hs
- compiler/GHC/StgToCmm/Env.hs
- compiler/GHC/StgToCmm/Expr.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/aeb0f524b89b5739637192ec8b1a4b7d1a507bcc...f95de6f57f7962d295ffeb1d8b11fea970d35b6c
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/aeb0f524b89b5739637192ec8b1a4b7d1a507bcc...f95de6f57f7962d295ffeb1d8b11fea970d35b6c
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/20221219/1d4edbda/attachment-0001.html>
More information about the ghc-commits
mailing list