[Git][ghc/ghc][master] 3 commits: Desugaring, plus -Wincomplete-record-selectors

Marge Bot (@marge-bot) gitlab at gitlab.haskell.org
Tue Oct 15 02:16:04 UTC 2024



Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC


Commits:
81a570bf by Sebastian Graf at 2024-10-14T22:15:31-04: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

- - - - -
ae7bc08e by Simon Peyton Jones at 2024-10-14T22:15:31-04: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!

- - - - -
6a067226 by Simon Peyton Jones at 2024-10-14T22:15:31-04:00
Add -Werror=-Wno-error=incomplete-record-selectors to hadrian-multi

In the main MR, -Wall now includes -Wincomplete-record-selectors.
However `hadrian-multi` has many, many warnings about incomplete
record selectors, so this patch stops those warnings being treated
as errors.  (See discussion on !13308.)

A better fix would be to remove the use of incomplete record
selectors, since each of them represents a potential crash.

- - - - -


30 changed files:

- .gitlab-ci.yml
- 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/Expr.hs
- compiler/GHC/Hs/Extension.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Stats.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/Hs/Utils.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e9cc469954eb19c5c131f9cfc1f0ede6ea9e9848...6a067226d094fbe59fd71c502c6977619f546953

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e9cc469954eb19c5c131f9cfc1f0ede6ea9e9848...6a067226d094fbe59fd71c502c6977619f546953
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/20241014/e33aa262/attachment-0001.html>


More information about the ghc-commits mailing list