<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html lang="en" style='--code-editor-font: var(--default-mono-font, "GitLab Mono"), JetBrains Mono, Menlo, DejaVu Sans Mono, Liberation Mono, Consolas, Ubuntu Mono, Courier New, andale mono, lucida console, monospace;'>
<head>
<meta content="text/html; charset=US-ASCII" http-equiv="Content-Type">
<title>
GitLab
</title>

<style data-premailer="ignore" type="text/css">
a { color: #1068bf; }
</style>


<style>img {
max-width: 100%; height: auto;
}
body {
font-size: .875rem;
}
body {
-webkit-text-shadow: rgba(255,255,255,.01) 0 0 1px;
}
body {
font-family: "GitLab Sans",-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,"Noto Sans",Ubuntu,Cantarell,"Helvetica Neue",sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji"; font-size: inherit;
}
</style>
</head>
<body style='font-size: inherit; -webkit-text-shadow: rgba(255,255,255,.01) 0 0 1px; font-family: "GitLab Sans",-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,"Noto Sans",Ubuntu,Cantarell,"Helvetica Neue",sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji";'>
<div class="content">

<h3 style="margin-top: 20px; margin-bottom: 10px;">
Vladislav Zavialov pushed to branch wip/int-index/wildcard-binders at <a href="https://gitlab.haskell.org/ghc/ghc">Glasgow Haskell Compiler / GHC</a>
</h3>
<h4 style="margin-top: 10px; margin-bottom: 10px;">
Commits:
</h4>
<ul>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/2a551cd5f6d9b23afd1f23ee64e8ef53874ec223">2a551cd5</a></strong>
<div>
<span> by Matthew Pickering </span> <i> at 2024-09-24T16:33:50+05:30 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>ci: Run abi-test on test-abi label
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/ab4039ace849e4e77a6be2993f599171d252f78c">ab4039ac</a></strong>
<div>
<span> by Rodrigo Mesquita </span> <i> at 2024-09-24T16:33:50+05:30 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>testsuite: Add a test for object determinism

Extends the abi_test with an object determinism check
Also includes a standalone test to be run by developers manually when
debugging issues with determinism.
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/d62c18d84c23728d258333b049994094c6858bbe">d62c18d8</a></strong>
<div>
<span> by Rodrigo Mesquita </span> <i> at 2024-09-24T16:33:50+05:30 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>determinism: Sampling uniques in the CG

To achieve object determinism, the passes processing Cmm and the rest of
the code generation pipeline musn't create new uniques which are
non-deterministic.

This commit changes occurrences of non-deterministic unique sampling
within these code generation passes by a deterministic unique sampling
strategy by propagating and threading through a deterministic
incrementing counter in them. The threading is done implicitly with
`UniqDSM` and `UniqDSMT`.

Secondly, the `DUniqSupply` used to run a `UniqDSM` must be threaded
through all passes to guarantee uniques in different passes are unique
amongst them altogether. Specifically, the same `DUniqSupply` must be
threaded through the CG Streaming pipeline, starting with Driver.Main
calling `StgToCmm.codeGen`, `cmmPipeline`, `cmmToRawCmm`, and
`codeOutput` in sequence.

To thread resources through the `Stream` abstraction, we use the `UniqDSMT`
transformer on top of `IO` as the Monad underlying the Stream. `UniqDSMT` will
thread the `DUniqSupply` through every pass applied to the `Stream`, for every
element. We use @type CgStream = Stream (UniqDSMT IO)@ for the Stream used in
code generation which that carries through the deterministic unique supply.

See Note [Deterministic Uniques in the CG]
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/3bbe4af48cdc15f43f4cb10ba131157b0cb7e228">3bbe4af4</a></strong>
<div>
<span> by Rodrigo Mesquita </span> <i> at 2024-09-24T16:33:50+05:30 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>determinism: Cmm unique renaming pass

To achieve object determinism, we need to prevent the non-deterministic
uniques from leaking into the object code. We can do this by
deterministically renaming the non-external uniques in the Cmm groups
that are yielded right after StgToCmm.

The key to deterministic renaming is observing that the order of
declarations, instructions, and data in the Cmm groups are already
deterministic (modulo other determinism bugs), regardless of the
uniques. We traverse the Cmm AST in this deterministic order and
rename the uniques, incrementally, in the order they are found, thus
making them deterministic. This renaming is guarded by
-fobject-determinism which is disabled by default for now.

This is one of the key passes for object determinism. Read about the
overview of object determinism and a more detailed explanation of this
pass in:
* Note [Object determinism]
* Note [Renaming uniques deterministically]

Significantly closes the gap to #12935
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/8357ed502d096e998eb2beeefd88b04f6810a170">8357ed50</a></strong>
<div>
<span> by Rodrigo Mesquita </span> <i> at 2024-09-24T16:33:50+05:30 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>determinism: DCmmGroup vs CmmGroup

Part of our strategy in producing deterministic objects, namely,
renaming all Cmm uniques in order, depend on the object code produced
having a deterministic order (say, A_closure always comes before
B_closure).

However, the use of LabelMaps in the Cmm representation invalidated this
requirement because the LabelMaps elements would already be in a
non-deterministic order (due to the original uniques), and the renaming
in sequence wouldn't work because of that non-deterministic order.

Therefore, we now start off with lists in CmmGroup (which preserve the
original order), and convert them into LabelMaps (for performance in the
code generator) after the uniques of the list elements have been
renamed.

See Note [DCmmGroup vs CmmGroup or: Deterministic Info Tables] and #12935.

Co-authored-by: Matthew Pickering <matthewtpickering@gmail.com>
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/0e675fb8ab682b64dfac2d44cb23b20bb3314809">0e675fb8</a></strong>
<div>
<span> by Rodrigo Mesquita </span> <i> at 2024-09-24T16:33:50+05:30 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>determinism: Don't print unique in pprFullName

This unique was leaking as part of the profiling description in info
tables when profiling was enabled, despite not providing information
relevant to the profile.
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/340f58b0b01da0052d938b658c5728be0534f433">340f58b0</a></strong>
<div>
<span> by Rodrigo Mesquita </span> <i> at 2024-09-24T16:33:50+05:30 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>determinism: UDFM for distinct-constructor-tables

In order to produce deterministic objects when compiling with
-distinct-constructor-tables, we also have to update the data
constructor map to be backed by a deterministic unique map (UDFM) rather
than a non-deterministic one (UniqMap).
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/282f37a0a328adcb03e7d911b71938524b261dd8">282f37a0</a></strong>
<div>
<span> by Rodrigo Mesquita </span> <i> at 2024-09-24T16:33:50+05:30 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>determinism: InfoTableMap uniques in generateCgIPEStub

Fixes object determinism when using -finfo-table-map

Make sure to also deterministically rename the IPE map (as per Note
[Renaming uniques deterministically]), and to use a deterministic unique
supply when creating new labels for the IPE information to guarantee
deterministic objects when IPE information is requested.

Note that the Cmm group produced in generateCgIPEStub must /not/ be
renamed because renaming uniques is not idempotent, and the references
to the previously renamed code in the IPE Cmm group would be renamed
twice and become invalid references to non-existent symbols.

We do need to det-rename the InfoTableMap that is created in the
conversion from Core to Stg. This is not a problem since that map won't
refer any already renamed names (since it was created before the
renaming).
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/7b37afc9f3e79559055488998ee73187886a0e00">7b37afc9</a></strong>
<div>
<span> by Zubin Duggal </span> <i> at 2024-09-24T16:33:50+05:30 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>ci: Allow abi-test to fail.

We are not fully deterministic yet, see #12935 for work that remains to be done.
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/a63ee33a116599c88e703d9793e025e17c59f7f9">a63ee33a</a></strong>
<div>
<span> by Simon Peyton Jones </span> <i> at 2024-09-25T17:08:24-04:00 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>Add Given injectivity for built-in type families

Ticket #24845 asks (reasonably enough) that if we have
   [G] a+b ~ 0
then we also know
   [G] a ~ 0, b ~ 0
and similar injectivity-like facts for other built-in type
families.  The status quo was that we never generate evidence for
injectivity among Givens -- but it is quite reasonnable to do so.
All we need is to have /evidence/ for the new constraints

This MR implements that goal.  I also took the opportunity to
* Address #24978: refactoring UnivCo
* Fix #25248, which was a consequences of the previous formulation of UnivCo

As a result this MR touches a lot of code.  The big things are:

* Coercion constructor UnivCo now takes a [Coercion] as argument to
  express the coercions on which the UnivCo depends. A nice consequence
  is that UnivCoProvenance now has no free variables, simpler in a number
  of places.

* Coercion constructors AxiomInstCo and AxiomRuleCo are combined into
  AxiomCo.  The new AxiomCo, carries a (slightly oddly named)
  CoAxiomRule, which itself is a sum type of the various forms of
  built-in axiom.  See Note [CoAxiomRule] in GHC.Core.Coercion.Axiom

  A merit of this is that we can separate the case of open and closed
  type families, and eliminate the redundant `BranchIndex` in the former
  case.

* Much better representation for data BuiltInSynFamily, which means we
  no longer need to enumerate built-in axioms as well as built-in tycons.

* There is a massive refactor in GHC.Builtin.Types.Literals, which contains all
  the built-in axioms for type-level operations (arithmetic, append, cons etc).

  A big change is that instead of redundantly having (a) a hand-written
  matcher, and (b) a template-based "proves" function, which were hard to
  keep in sync, the two are derive from one set of human-supplied info.
  See GHC.Builtin.Types.Literals.mkRewriteAxiom, and friends.

* Significant changes in GHC.Tc.Solver.Equality to account for the new
  opportunity for Given/Given equalities.

Smaller things

* Improve pretty-printing to avoid parens around atomic coercions.

* Do proper eqType in findMatchingIrreds, not `eqTypeNoKindCheck`.
  Looks like a bug, Richard agrees.

* coercionLKind and coercionRKind are hot functions.  I refactored the
  implementation (which I had to change anyway) to increase sharing.
  See Note [coercionKind performance] in GHC.Core.Coercion

* I wrote a new Note [Finding orphan names] in GHC.Core.FVs about orphan
  names

* I improved the `is_concrete` flag in GHC.Core.Type.buildSynTyCon, to avoid
  calling tyConsOfType.  I forget exactly why I did this, but it's definitely
  better now.

* I moved some code from GHC.Tc.Types.Constraint into GHC.Tc.Types.CtLocEnv
  and I renamed the module GHC.Tc.Types.CtLocEnv to GHC.Tc.Types.CtLoc
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/dd8ef342bb5f050309545e89cf735d6f31c17398">dd8ef342</a></strong>
<div>
<span> by Ryan Scott </span> <i> at 2024-09-25T17:09:01-04:00 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>Resolve ambiguous method-bound type variables in vanilla defaults and GND

When defining an instance of a class with a "vanilla" default, such as in the
following example (from #14266):

```hs
class A t where
  f :: forall x m. Monoid x => t m -> m
  f = <blah>

instance A []
```

We have to reckon with the fact that the type of `x` (bound by the type
signature for the `f` method) is ambiguous. If we don't deal with the ambiguity
somehow, then when we generate the following code:

```hs
instance A [] where
  f = $dmf @[] -- NB: the type of `x` is still ambiguous
```

Then the generated code will not typecheck. (Issue #25148 is a more recent
example of the same problem.)

To fix this, we bind the type variables from the method's original type
signature using `TypeAbstractions` and instantiate `$dmf` with them using
`TypeApplications`:

```hs
instance A [] where
  f @x @m = $dmf @[] @x @m -- `x` is no longer ambiguous
```

Note that we only do this for vanilla defaults and not for generic defaults
(i.e., defaults using `DefaultSignatures`). For the full details, see `Note
[Default methods in instances] (Wrinkle: Ambiguous types from vanilla method
type signatures)`.

The same problem arose in the code generated by `GeneralizedNewtypeDeriving`,
as we also fix it here using the same technique. This time, we can take
advantage of the fact that `GeneralizedNewtypeDeriving`-generated code
_already_ brings method-bound type variables into scope via `TypeAbstractions`
(after !13190), so it is very straightforward to visibly apply the type
variables on the right-hand sides of equations. See `Note [GND and ambiguity]`.

Fixes #14266. Fixes #25148.
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/0a4da5d2194be981a582a805b0b01ad42ba1c76c">0a4da5d2</a></strong>
<div>
<span> by ARATA Mizuki </span> <i> at 2024-09-25T17:09:41-04:00 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>Document primitive string literals and desugaring of string literals

Fixes #17474 and #17974

Co-authored-by: Matthew Craven <5086-clyring@users.noreply.gitlab.haskell.org>
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/ad0731ada00982ae66e0b5bb88ca7b97ece1313f">ad0731ad</a></strong>
<div>
<span> by Zubin Duggal </span> <i> at 2024-09-25T17:10:18-04:00 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>rts: Fix segfault when using non-moving GC with profiling

`nonMovingCollect()` swaps out the `static_flag` value used as a
sentinel for `gct->scavenged_static_objects`, but the subsequent call
`resetStaticObjectForProfiling()` sees the old value of `static_flag` used as
the sentinel and segfaults. So we must call `resetStaticObjectForProfiling()`
before calling `nonMovingCollect()` as otherwise it looks for the incorrect
sentinel value

Fixes #25232 and #23958

Also teach the testsuite driver about nonmoving profiling ways
and stop disabling metric collection when nonmoving GC is enabled.
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/e7a26d7a6faf1ea534e036c5085a0a027dbb6f5f">e7a26d7a</a></strong>
<div>
<span> by Sylvain Henry </span> <i> at 2024-09-25T17:11:00-04:00 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>Fix interaction between fork and kqueue (#24672)

A kqueue file descriptor isn't inherited by a child created with fork.
As such we mustn't try to close this file descriptor as we would close a
random one, e.g. the one used by timerfd.

Fix #24672
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/6863503cf3240f78549436819f20f9e1adc578d3">6863503c</a></strong>
<div>
<span> by Simon Peyton Jones </span> <i> at 2024-09-25T17:11:37-04:00 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>Improve GHC.Tc.Solver.defaultEquality

This MR improves GHC.Tc.Solver.defaultEquality to solve #25251.

The main change is to use checkTyEqRhs to check the equality, so
that we do promotion properly.

But within that we needed a small enhancement to LC_Promote.  See
Note [Defaulting equalites] (DE4) and (DE5)

The tricky case is (alas) hard to trigger, so I have not added a
regression test.
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/97a6c6c3ded91af838f4376e4ad0781f0e971daf">97a6c6c3</a></strong>
<div>
<span> by Sylvain Henry </span> <i> at 2024-09-25T17:12:18-04:00 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>JS: fix h$withCStringOnHeap helper (#25288)

strlen returns the length of the string without the \0 terminating byte,
hence CString weren't properly allocated on the heap (ending \0 byte was
missing).
</pre>
</li>
<li>
<strong style="font-weight: 600;"><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/4dceb0ff71afe56484c46d6e52456650a6d643dc">4dceb0ff</a></strong>
<div>
<span> by Vladislav Zavialov </span> <i> at 2024-09-26T01:35:22+03:00 </i>
</div>
<pre class="commit-message" style='white-space: pre-wrap; display: block; font-size: 14px; color: #28272d; position: relative; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; word-break: break-all; word-wrap: break-word; background-color: #fbfafd; border-radius: 2px; margin: 0; padding: 8px 12px; border: 1px solid #dcdcde;'>Wildcard binders in type declarations (#23501)

Add support for wildcard binders in type declarations:

        type Const a b = a   -- BEFORE: the `b` had to be named
                             --         even if unused on the RHS

        type Const a _ = a   -- AFTER: the compiler accepts
                             --        a wildcard binder `_`

The new feature is part of GHC Proposal #425 "Invisible binders
in type declarations", and more specifically its amendment #641.

Just like a named binder, a wildcard binder `_` may be:

        * plain:      _
        * kinded:    (_ :: k -> Type)
        * invisible, plain:  @_
        * invisible, kinded: @(_ :: k -> Type)

Those new forms of binders are allowed to occur on the LHSs of
data, newtype, type, class, and type/data family declarations:

        data D _ = ...
        newtype N _ = ...
        type T _ = ...
        class C _ where ...
        type family F _
        data family DF _

(Test case: testsuite/tests/typecheck/should_compile/T23501a.hs)

However, we choose to reject them in forall telescopes and
type family result variable binders (the latter being part
of the TypeFamilyDependencies extension):

        type family Fd a = _    -- disallowed  (WildcardBndrInTyFamResultVar)
        fn :: forall _. Int     -- disallowed  (WildcardBndrInForallTelescope)

(Test case: testsuite/tests/rename/should_fail/T23501_fail.hs)

See the new Notes:
        * Note [Type variable binders]
        * Note [Wildcard binders in disallowed contexts]

To accommodate the new forms of binders, HsTyVarBndr was changed
as follows (demonstrated without x-fields for clarity)

        -- BEFORE (ignoring x-fields and locations)
        data HsTyVarBndr flag
          = UserTyVar   flag Name
          | KindedTyVar flag Name HsKind

        -- AFTER (ignoring x-fields and locations)
        data HsTyVarBndr flag = HsTvb flag HsBndrVar HsBndrKind
        data HsBndrVar  = HsBndrVar Name | HsBndrWildCard
        data HsBndrKind = HsBndrNoKind | HsBndrKind LHsKind

The rest of the patch is downstream from this change.

To avoid a breaking change to the TH AST, we generate fresh
names to replace wildcard binders instead of adding a dedicated
representation for them (as discussed in #641).

And to put a cherry on top of the cake, we now allow wildcards in
kind-polymorphic type variable binders in constructor patterns,
see Note [Type patterns: binders and unifiers] and the tyPatToBndr
function in GHC.Tc.Gen.HsType; example:

        fn (MkT @(_ :: forall k. k -> Type) _ _) = ...

(Test case: testsuite/tests/typecheck/should_compile/T23501b.hs)
</pre>
</li>
</ul>
<h4 style="margin-top: 10px; margin-bottom: 10px;">
27 changed files:
</h4>
<ul>
<li class="file-stats">
<a href="#587d266bb27a4dc3022bbed44dfa19849df3044c">
.gitlab-ci.yml
</a>
</li>
<li class="file-stats">
<a href="#157f7634c25bc6366cb7c9c9edb48e819dce38db">
.gitlab/ci.sh
</a>
</li>
<li class="file-stats">
<a href="#02362b473a022fb921814e97a6beba08107d38b1">
compiler/GHC/Builtin/Types/Literals.hs
</a>
</li>
<li class="file-stats">
<a href="#f73a4fa90a8eb153bccdcfcc9f63c15edcd66785">
compiler/GHC/Cmm.hs
</a>
</li>
<li class="file-stats">
<a href="#2635960270885615c76f7437d2eb6c5bd6082895">
compiler/GHC/Cmm/BlockId.hs
</a>
</li>
<li class="file-stats">
<a href="#db697f6aea9f93f1583f1d5c62d25570a1e07f73">
compiler/GHC/Cmm/CLabel.hs
</a>
</li>
<li class="file-stats">
<a href="#ae3febe6c6eb7c487d9f1021b113402ae6148bae">
compiler/GHC/Cmm/Dataflow.hs
</a>
</li>
<li class="file-stats">
<a href="#f0eb87ebfd1fa86064e22c34e559db8c8195ffcb">
compiler/GHC/Cmm/Dataflow/Graph.hs
</a>
</li>
<li class="file-stats">
<a href="#29368208fbfcaee57ce84000cdccaba639e85a75">
compiler/GHC/Cmm/Graph.hs
</a>
</li>
<li class="file-stats">
<a href="#47cba74ae8965f1665cd11bf2b023760ea27594e">
compiler/GHC/Cmm/Info.hs
</a>
</li>
<li class="file-stats">
<a href="#2d3721ad8de95e1144493ca545db846672cb109f">
compiler/GHC/Cmm/Info/Build.hs
</a>
</li>
<li class="file-stats">
<a href="#066085df29cc928ac539d8feae6e5215cbbf1e14">
compiler/GHC/Cmm/LayoutStack.hs
</a>
</li>
<li class="file-stats">
<a href="#00c27365316e033b00cc3ed3854ac8714d25a2b5">
compiler/GHC/Cmm/Opt.hs
</a>
</li>
<li class="file-stats">
<a href="#71e696f452eb493722d70306c6f304fc9b2f6a95">
compiler/GHC/Cmm/Parser.y
</a>
</li>
<li class="file-stats">
<a href="#d40f34584a7f4c0fa7587fb41f94a34bca0d1064">
compiler/GHC/Cmm/Pipeline.hs
</a>
</li>
<li class="file-stats">
<a href="#29a1593e7281c8a9103a19e3a7562e2365e23b47">
compiler/GHC/Cmm/ProcPoint.hs
</a>
</li>
<li class="file-stats">
<a href="#6269ecd0e04f688b9a50e8cf9709fb4d9d5616d5">
compiler/GHC/Cmm/Reducibility.hs
</a>
</li>
<li class="file-stats">
<a href="#b1390f6749e1a2dddcae35f88d55623ea6269f56">
compiler/GHC/Cmm/Sink.hs
</a>
</li>
<li class="file-stats">
<a href="#072618a3250e1148569c2d2e0c05e313c2f529e3">
compiler/GHC/Cmm/Switch.hs
</a>
</li>
<li class="file-stats">
<a href="#f8bd883e3d3136150937961aaca9b45779a06100">
compiler/GHC/Cmm/Switch/Implement.hs
</a>
</li>
<li class="file-stats">
<a href="#194e2602b82bb08fd31c3028aace1da113aae36f">
compiler/GHC/Cmm/ThreadSanitizer.hs
</a>
</li>
<li class="file-stats">
<a href="#abeee02d953ad375632ff4797c0b431d42757b6a">
<span class="new-file">
+
compiler/GHC/Cmm/UniqueRenamer.hs
</span>
</a>
</li>
<li class="file-stats">
<a href="#10b61652f9817945bb54ccf8fc40f8a664ca3c30">
compiler/GHC/CmmToAsm.hs
</a>
</li>
<li class="file-stats">
<a href="#6997a0cd37829d3d08db1c48185aaa3d7dfc3e6b">
compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
</a>
</li>
<li class="file-stats">
<a href="#807babf5b215890881c92043bcd08486141a405c">
compiler/GHC/CmmToAsm/AArch64/Instr.hs
</a>
</li>
<li class="file-stats">
<a href="#5986ebaacfa99d264abfd2f7ef19d99a64db720f">
compiler/GHC/CmmToAsm/BlockLayout.hs
</a>
</li>
<li class="file-stats">
<a href="#b131e0d591301ee7a1c76bbd812f3d14783e934f">
compiler/GHC/CmmToAsm/Dwarf.hs
</a>
</li>
</ul>
<h5 style="margin-top: 10px; margin-bottom: 10px; font-size: .875rem;">
The diff was not included because it is too large.
</h5>

</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #737278;">

<br>
<a href="https://gitlab.haskell.org/ghc/ghc/-/compare/8011bc880b194219b6203b9f6939b17798678ad3...4dceb0ff71afe56484c46d6e52456650a6d643dc">View it on GitLab</a>.
<br>
You're receiving this email because of your account on <a target="_blank" rel="noopener noreferrer" href="https://gitlab.haskell.org">gitlab.haskell.org</a>. <a href="https://gitlab.haskell.org/-/profile/notifications" target="_blank" rel="noopener noreferrer" class="mng-notif-link">Manage all notifications</a> · <a href="https://gitlab.haskell.org/help" target="_blank" rel="noopener noreferrer" class="help-link">Help</a>



</p>
</div>
</body>
</html>