[Git][ghc/ghc][wip/T25281] 5 commits: Fix typo in the @since annotation of annotateIO

Simon Peyton Jones (@simonpj) gitlab at gitlab.haskell.org
Wed Oct 9 21:50:25 UTC 2024



Simon Peyton Jones pushed to branch wip/T25281 at Glasgow Haskell Compiler / GHC


Commits:
55609880 by Andrzej Rybczak at 2024-10-09T16:41:46-04:00
Fix typo in the @since annotation of annotateIO

- - - - -
ef481813 by Alan Zimmerman at 2024-10-09T16:42:23-04:00
EPA: Remove [AddEpAnn] from (most of) HsExpr

EPA: introduce EpAnnLam for lambda annotationsi, and remove `glAA`
from `Parser.y`, it is the same as `glR`

EPA: Remove unused annotation from XOpApp

EPA: Use EpToken for XNPat and XNegApp

EPA: specific anns for XExplicitTuple / XTuplePat / sumPatParens.

EPA: Use specific annotation for MultiIf

EPA: Move annotations into FunRhs

EPA: Remove [AddEpAnn] from SigPat and ExprWithTySig

EPA: Remove [AddEpAnn] from ArithSeq

EPA: Remove [AddEpAnn] from HsProc

EPA: Remove [AddEpAnn] from HsStatic

EPA: Remove [AddEpAnn] from BindStmt

EPA: Remove [AddEpAnn] from TransStmt

EPA: Remove [AddEpAnn] from HsTypedSplice

EPA: Remove [AddEpAnn] from HsUntypedSpliceExpr

- - - - -
3a45b51b by Sebastian Graf at 2024-10-09T22:50:03+01:00
Desugaring, plus -Wincomplete-record-selectors

This commit does several related things:

* Major refactor of the handling of applications in the desugarer.
  Now all applications are handled in `dsApp`, `ds_app` and related
  functions.  This dramatically simplifies the code and removes
  complicated cruft that had accumulated.  Hooray.

  Fixes #25281.

* Improve the handling of -Wincomplete-record-selectors.

  We now incorporate the result type of unsaturated record selector
  applications as well as consider long-distance information in
  getField applications.

  Plus, the implmentation now builds the improved `dsApp` stuff
  above, so it is much easier to understand.

  Plus, incorporates improved error message wording suggested
  by Adam Gundry in !12685.

  Fixes #24824, #24891

  See the long Note [Detecting incomplete record selectors]

* Add -Wincomplete-record-selectors to -Wall, as specified in
  GHC Proposal 516.

  To do this, I also had to add -Wno-incomplete-record-selectors
  to the build flags for Cabal in GHC's CI.  See
  hadrian/src/Settings/Warnings.hs.  We can remove this when
  Cabal is updated so that it doesn't trigger the warning:
  https://github.com/haskell/cabal/issues/10402

2.6% decrease in compile time allocation in RecordUpPerf

Metric Decrease:
    RecordUpdPerf

- - - - -
602a65bc by Simon Peyton Jones at 2024-10-09T22:50:04+01:00
Elmininate incomplete record selectors

This patch is a pure refactor of GHC's source code, to avoid the use
of partial record selectors.  It was provoked by adding
-Wincomplete-record-selectors to -Wall (as the GHC Proposal specified),
which in turn showed up lots of places where GHC was using incomplete
record selectors.

This patch does mostly-simple refactoring to make it clear to the pattern
match checker that there is in fact no partiality.

There is one externally-visible change: I changed the data type HoleFit
to split out the two cases

  data HoleFit = TcHoleFit  TcHoleFit | RawHoleFit SDoc
  data TcHoleFit = HoleFit { ...lots of fields }

There are large swathes of code that just deal with `TcHoleFit`, and
having it as a separate data types makes it apparent that `RawHoleFit`
can't occur.

This makes it much better -- but the change is visible in the
HolePlugin interface.  I decided that there are so few clients of this
API that it's worth the change.

I moved several functions from Language.Haskell.Syntax to GHC.Hs.
Reason, when instantiated at (GhcPass _), the extension data construtcor
is guaranteed unused, and that justifies omitted patterns in these
functions.  By putting them in GHC.Hs.X I can specialise the type for
(GhcPass _) and thereby make the function total.

An interesting side-light is that there were a few local function
definitions without a type signature, like this one in GHC.Parser.Header
     convImport (L _ i) = (ideclPkgQual i, reLoc $ ideclName i)
This is fully closed, and so is generalised; but that generalises
it to any old pass, not (GhcPass _), so GHC rightly complains about the
use of the selector `ideclPkgQual`.  I added a type signature to `i`, thus
     convImport (L _ (i::ImportDecl GhcPs))
         = (ideclPkgQual i, reLoc $ ideclName i)
which specialised the function enough to make the record selector complete.
Quite a surprising consequence of local let-generalisation!

- - - - -
de030c0b by Simon Peyton Jones at 2024-10-09T22:50:04+01:00
Missing record selectors in GHC.Internal.IO.Windows.Handle

This look genuinely wrong: see #25362.  These two fixes need auditing;
but they are better than the status quo.

Actually Ben has fixed this in !13394, so this patch will be
obseleted once !13394 lands.

- - - - -


30 changed files:

- compiler/GHC/CmmToAsm/Dwarf/Types.hs
- compiler/GHC/CmmToAsm/Reg/Graph/Stats.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/ConLike.hs
- compiler/GHC/Core/FVs.hs
- compiler/GHC/Core/LateCC/OverloadedCalls.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/CprAnal.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/Simplify/Env.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Rules.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/Subst.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Hs/Binds.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Dump.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Stats.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/ee8bcb0657e8bf1d91664083a3cd9ff2b611a58a...de030c0b6096a2696f863d1b07151c607ee7a4e0

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/ee8bcb0657e8bf1d91664083a3cd9ff2b611a58a...de030c0b6096a2696f863d1b07151c607ee7a4e0
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/20241009/dd0f6d5f/attachment.html>


More information about the ghc-commits mailing list