<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html lang="en">
<head>
<meta content="text/html; charset=US-ASCII" http-equiv="Content-Type">
<title>
GitLab
</title>



<style>img {
max-width: 100%; height: auto;
}
</style>
</head>
<body>
<div class="content">

<h3>
 Marge Bot pushed to branch wip/marge_bot_batch_merge_job
at <a href="https://gitlab.haskell.org/ghc/ghc">Glasgow Haskell Compiler / GHC</a>
</h3>
<h4>
Commits:
</h4>
<ul>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/31fcb55f4ff8c06c5ab100a6817cae8b571295a9">31fcb55f</a></strong>
<div>
<span>by Ryan Scott</span>
<i>at 2020-10-30T18:52:50-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Split HsConDecl{H98,GADT}Details

Haskell98 and GADT constructors both use `HsConDeclDetails`, which includes
`InfixCon`. But `InfixCon` is never used for GADT constructors, which results
in an awkward unrepresentable state. This removes the unrepresentable state by:

* Renaming the existing `HsConDeclDetails` synonym to `HsConDeclH98Details`,
  which emphasizes the fact that it is now only used for Haskell98-style data
  constructors, and
* Creating a new `HsConDeclGADTDetails` data type with `PrefixConGADT` and
  `RecConGADT` constructors that closely resemble `PrefixCon` and `InfixCon`
  in `HsConDeclH98Details`. The key difference is that `HsConDeclGADTDetails`
  lacks any way to represent infix constructors.

The rest of the patch is refactoring to accommodate the new structure of
`HsConDecl{H98,GADT}Details`. Some highlights:

* The `getConArgs` and `hsConDeclArgTys` functions have been removed, as
  there is no way to implement these functions uniformly for all
  `ConDecl`s. For the most part, their previous call sites now
  pattern match on the `ConDecl`s directly and do different things for
  `ConDeclH98`s and `ConDeclGADT`s.

  I did introduce one new function to make the transition easier:
  `getRecConArgs_maybe`, which extracts the arguments from a `RecCon(GADT)`.
  This is still possible since `RecCon(GADT)`s still use the same representation
  in both `HsConDeclH98Details` and `HsConDeclGADTDetails`, and since the
  pattern that `getRecConArgs_maybe` implements is used in several places,
  I thought it worthwhile to factor it out into its own function.
* Previously, the `con_args` fields in `ConDeclH98` and `ConDeclGADT` were
  both of type `HsConDeclDetails`. Now, the former is of type
  `HsConDeclH98Details`, and the latter is of type `HsConDeclGADTDetails`,
  which are distinct types. As a result, I had to rename the `con_args` field
  in `ConDeclGADT` to `con_g_args` to make it typecheck.

  A consequence of all this is that the `con_args` field is now partial, so
  using `con_args` as a top-level field selector is dangerous. (Indeed, Haddock
  was using `con_args` at the top-level, which caused it to crash at runtime
  before I noticed what was wrong!) I decided to add a disclaimer in the 9.2.1
  release notes to advertise this pitfall.

Fixes #18844. Bumps the `haddock` submodule.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/109f3cfe2546313156ff297aaec42a3496f687da">109f3cfe</a></strong>
<div>
<span>by Ryan Scott</span>
<i>at 2020-10-30T19:23:37-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Make typechecker equality consider visibility in ForAllTys

Previously, `can_eq_nc'` would equate `ForAllTy`s regardless of their
`ArgFlag`, including `forall i -> i -> Type` and `forall i. i -> Type`! To fix
this, `can_eq_nc'` now uses the `sameVis` function to first check if the
`ArgFlag`s are equal modulo specificity. I have also updated `tcEqType`'s
implementation to match this behavior. For more explanation on the "modulo
specificity" part, see the new `Note [ForAllTy and typechecker equality]`
in `GHC.Tc.Solver.Canonical`.

While I was in town, I fixed some related documentation issues:

* I added `Note [Typechecker equality]` to `GHC.Tc.Utils.TcType` to describe
  what exactly distinguishes `can_eq_nc'` and `tcEqType` (which implement
  typechecker equality) from `eqType` (which implements definitional equality,
  which does not care about the `ArgFlags` of `ForAllTy`s at all).
* The User's Guide had some outdated prose on the specified/inferred
  distinction being different for types and kinds, a holdover from #15079. This
  is no longer the case on today's GHC, so I removed this prose, added some new
  prose to take its place, and added a regression test for the programs in
  #15079.
* The User's Guide had some _more_ outdated prose on inferred type variables
  not being allowed in `default` type signatures for class methods, which is no
  longer true as of the resolution of #18432.
* The related `Note [Deferred Unification]` was being referenced as
  `Note [Deferred unification]` elsewhere, which made it harder to `grep`
  for. I decided to change the name of the Note to `Deferred unification`
  for consistency with the capitalization style used for most other Notes.

Fixes #18863.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/904a038ce63f0b11525e1658750f8c5199b9c3b0">904a038c</a></strong>
<div>
<span>by Sylvain Henry</span>
<i>at 2020-10-30T19:23:42-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Refactor numeric constant folding rules

Avoid the use of global pattern synonyms.

1) I think it's going to be helpful to implement constant folding for
   other numeric types, especially Natural which doesn't have a wrapping
   behavior. We'll have to refactor these rules even more so we'd better
   make them less cryptic.

2) It should also be slightly faster because global pattern synonyms
   matched operations for every numeric types instead of the current one:
   e.g., ":**:" pattern was matching multiplication for both Int# and
   Word# types. As we will probably want to implement constant folding
   for other numeric types (Int8#, Int16#, etc.), it is more efficient
   to only match primops for a given type as we do now.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/67a26cdbf4a7a7b54954c4c646d8155547689c04">67a26cdb</a></strong>
<div>
<span>by Sylvain Henry</span>
<i>at 2020-10-30T19:23:42-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Simplify constant-folding (#18032)

See #18032 for the details.

* Use `Lit (LitNumber _ i)` instead of `isLitValue_maybe` which does
  more work but that is not needed for constant-folding
* Don't export `GHC.Types.Literal.isLitValue_maybe`
* Kill `GHC.Types.Literal.isLitValue` which isn't used
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/4c9c8ee881d7ba46566af1d838050bd037eb35e1">4c9c8ee8</a></strong>
<div>
<span>by Ben Gamari</span>
<i>at 2020-10-30T19:23:43-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">primops.txt.pp: Move ByteArray# primops to separate file

This file will be generated.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/bba8aec71bcf39ffd2e6497ad99b320c0419dbe1">bba8aec7</a></strong>
<div>
<span>by Ben Gamari</span>
<i>at 2020-10-30T19:23:43-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">primops: Generate ByteArray# index/read/write primops

Previously these were mostly undocumented and was ripe for potential
inconsistencies.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/5b3972b563c8b871c424ad703daa4c4322b673a8">5b3972b5</a></strong>
<div>
<span>by Sylvain Henry</span>
<i>at 2020-10-30T19:23:45-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Move loadDecl into IfaceToCore
</pre>
</li>
</ul>
<h4>30 changed files:</h4>
<ul>
<li class="file-stats">
<a href="#ee840b93f51ee5ed4233a2f892343421ba49af58">
<span class="new-file">
+
compiler/GHC/Builtin/bytearray-ops.txt.pp
</span>
</a>
</li>
<li class="file-stats">
<a href="#451725cc4e5d443a3b7c2adcdf224840f953b7e2">
compiler/GHC/Builtin/primops.txt.pp
</a>
</li>
<li class="file-stats">
<a href="#aa79261abf782f3dc603af7fbd5c4b08ed3ddb88">
compiler/GHC/Core/Opt/ConstantFold.hs
</a>
</li>
<li class="file-stats">
<a href="#578c7c3857d66d963736ff6742f3433a0e8d01b7">
compiler/GHC/Core/TyCo/Rep.hs
</a>
</li>
<li class="file-stats">
<a href="#84c9d3ba34173297e7d7747e02caa2e004b164fc">
compiler/GHC/Core/Type.hs
</a>
</li>
<li class="file-stats">
<a href="#75bfcd03f3ba9315d33104fcb0424c6bfeb4e334">
compiler/GHC/Hs/Decls.hs
</a>
</li>
<li class="file-stats">
<a href="#9f00edfedb0f969865b049a78de3866545b4a60b">
compiler/GHC/Hs/Instances.hs
</a>
</li>
<li class="file-stats">
<a href="#018be522bc4813b147a1525e4f96a7a493207d96">
compiler/GHC/Hs/Type.hs
</a>
</li>
<li class="file-stats">
<a href="#7a1af22e4c32b9aa6ec708d9d3788e1c4db5da9a">
compiler/GHC/Hs/Utils.hs
</a>
</li>
<li class="file-stats">
<a href="#ea46b374e004d4416e29a563ee063542f98e48c5">
compiler/GHC/HsToCore/Docs.hs
</a>
</li>
<li class="file-stats">
<a href="#3c19c0be465f9a28d7b69f89c55648080fcc37eb">
compiler/GHC/HsToCore/Quote.hs
</a>
</li>
<li class="file-stats">
<a href="#649144a78135a23cabfc90dd83c4aabf448eb6ab">
compiler/GHC/Iface/Ext/Ast.hs
</a>
</li>
<li class="file-stats">
<a href="#7d51edda4fa76a202cce0bca672ef300249ba8ea">
compiler/GHC/Iface/Load.hs
</a>
</li>
<li class="file-stats">
<a href="#079d6b28856775716c78fdd4a4b35bb45a59002c">
compiler/GHC/Iface/Syntax.hs
</a>
</li>
<li class="file-stats">
<a href="#06ff7bac58fd8cfe0c17b81963b03f4cce86a065">
compiler/GHC/IfaceToCore.hs
</a>
</li>
<li class="file-stats">
<a href="#4def5b79230b3c716cc9a08bdea7ac8a5c0c3ebf">
compiler/GHC/IfaceToCore.hs-boot
</a>
</li>
<li class="file-stats">
<a href="#bf951467d4a9aa443cb109cb4c84a2891945649b">
compiler/GHC/Parser.y
</a>
</li>
<li class="file-stats">
<a href="#446cb12ca6cefaf1c6eb79b7db643632744263c7">
compiler/GHC/Parser/PostProcess.hs
</a>
</li>
<li class="file-stats">
<a href="#13755bdc5d6c6b4c6f31604eb0da778521355795">
compiler/GHC/Parser/PostProcess/Haddock.hs
</a>
</li>
<li class="file-stats">
<a href="#892acbb198a9095c917740d3c1297b56df4e3b7e">
compiler/GHC/Rename/HsType.hs
</a>
</li>
<li class="file-stats">
<a href="#7dd1cd0f6f2164a14c83d9aa564dd32bc30e447a">
compiler/GHC/Rename/Module.hs
</a>
</li>
<li class="file-stats">
<a href="#e05ee69330b0f7088f11a5f3567137547489664d">
compiler/GHC/Rename/Names.hs
</a>
</li>
<li class="file-stats">
<a href="#f018e77421f495c6f75733fee4a511cfe57bebe8">
compiler/GHC/Tc/Solver/Canonical.hs
</a>
</li>
<li class="file-stats">
<a href="#83d23a46bb6cdc8b1edc16f1fd2c8f5c53e2c9ca">
compiler/GHC/Tc/TyCl.hs
</a>
</li>
<li class="file-stats">
<a href="#5461e7beeb7ae73d7c01f720cbaa3fa2c5333590">
compiler/GHC/Tc/Utils/TcType.hs
</a>
</li>
<li class="file-stats">
<a href="#74295edeac870ee7f2f3484ebaffab5c948b735a">
compiler/GHC/Tc/Utils/Unify.hs
</a>
</li>
<li class="file-stats">
<a href="#2eac51f9871ca0c0698aa1fc7f79c05ef8fc4a49">
compiler/GHC/ThToHs.hs
</a>
</li>
<li class="file-stats">
<a href="#ee98f016857ad5548bb7cdc5dd85246585acdfd6">
compiler/GHC/Types/Literal.hs
</a>
</li>
<li class="file-stats">
<a href="#49adaedbb694748035a5c7111adf7480c110ea21">
compiler/GHC/Types/TyThing.hs
</a>
</li>
<li class="file-stats">
<a href="#d87dfc77856eeaef6134e28336290ddcbcf18d7d">
docs/users_guide/9.2.1-notes.rst
</a>
</li>
</ul>
<h5>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: #777;">

<br>
<a href="https://gitlab.haskell.org/ghc/ghc/-/compare/5ac6f8806bb9524d2e7cd8f9518e8391c07e3d79...5b3972b563c8b871c424ad703daa4c4322b673a8">View it on GitLab</a>.
<br>
You're receiving this email because of your account on gitlab.haskell.org.
If you'd like to receive fewer emails, you can
adjust your notification settings.



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