[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 5 commits: LinearTypes => MonoLocalBinds

[Marge Bot (@marge-bot)]

Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC


Commits:
188b280d by Arnaud Spiwack at 2023-12-11T15:33:31+01:00
LinearTypes => MonoLocalBinds

- - - - -
8e0446df by Arnaud Spiwack at 2023-12-11T15:44:28+01:00
Linear let and where bindings

For expediency, the initial implementation of linear types in GHC
made it so that let and where binders would always be considered
unrestricted. This was rather unpleasant, and probably a big obstacle
to adoption. At any rate, this was not how the proposal was designed.

This patch fixes this infelicity. It was surprisingly difficult to
build, which explains, in part, why it took so long to materialise.

As of this patch, let or where bindings marked with %1 will be
linear (respectively %p for an arbitrary multiplicity p). Unmarked let
will infer their multiplicity.

Here is a prototypical example of program that used to be rejected and
is accepted with this patch:

```haskell
f :: A %1 -> B
g :: B %1 -> C

h :: A %1 -> C
h x = g y
  where
    y = f x
```

Exceptions:
- Recursive let are unrestricted, as there isn't a clear semantics of
  what a linear recursive binding would be.
- Destructive lets with lazy bindings are unrestricted, as their
  desugaring isn't linear (see also #23461).
- (Strict) destructive lets with inferred polymorphic type are
  unrestricted. Because the desugaring isn't linear (See #18461
  down-thread).

Closes #18461 and #18739

Co-authored-by: @jackohughes

- - - - -
6b1335c2 by Matthew Craven at 2023-12-11T22:45:46-05:00
Introduce `dataToTagSmall#` primop (closes #21710)

...and use it to generate slightly better code when dataToTag#
is used at a "small data type" where there is no need to mess
with "is_too_big_tag" or potentially look at an info table.

Metric Decrease:
    T18304

- - - - -
53a54c2f by Matthew Craven at 2023-12-11T22:45:46-05:00
Fix formatting of Note [alg-alt heap check]

- - - - -
a0c7713a by Oleg Grenrus at 2023-12-11T22:45:47-05:00
Allow untyped brackets in typed splices and vice versa.

Resolves #24190

Apparently the check was essentially always (as far as I can trace back: d0d47ba76f8f0501cf3c4966bc83966ab38cac27),
and while it does catch some mismatches, the type-checker will catch
them too. OTOH, it prevents writing completely reasonable programs.

- - - - -


30 changed files:

- compiler/GHC/Builtin/PrimOps.hs
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/Core.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/ConstantFold.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Hs/Binds.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Arrows.hs
- compiler/GHC/HsToCore/Binds.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/ListComp.hs
- compiler/GHC/HsToCore/Match.hs
- compiler/GHC/HsToCore/Match.hs-boot
- compiler/GHC/HsToCore/Utils.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/Bind.hs
- compiler/GHC/Rename/Splice.hs
- compiler/GHC/Stg/InferTags/Rewrite.hs
- compiler/GHC/StgToCmm/Expr.hs
- compiler/GHC/StgToCmm/Prim.hs
- compiler/GHC/StgToJS/Prim.hs
- compiler/GHC/Tc/Gen/Arrow.hs
- compiler/GHC/Tc/Gen/Bind.hs
- compiler/GHC/Tc/Gen/Expr.hs
- compiler/GHC/Tc/Gen/Match.hs
- compiler/GHC/Tc/Gen/Match.hs-boot
- compiler/GHC/Tc/Gen/Pat.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/180aeb4e2c69023fae83ed337ed29de235397dba...a0c7713a0e48502a2ea86ace4d1914649d267973

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/180aeb4e2c69023fae83ed337ed29de235397dba...a0c7713a0e48502a2ea86ace4d1914649d267973
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/20231211/1184cd1e/attachment.html>