[Git][ghc/ghc][ghc-9.4] 4 commits: Fix nested type splices in hie files

Ben Gamari (@bgamari) gitlab at gitlab.haskell.org
Wed Nov 2 21:54:10 UTC 2022



Ben Gamari pushed to branch ghc-9.4 at Glasgow Haskell Compiler / GHC


Commits:
edfa9f46 by Matthew Pickering at 2022-11-01T17:46:56-04:00
Fix nested type splices in hie files

The issue is that when we compile a typed bracket we replace the splice
with HsSpliced (unTypeCode ...).

Then when computing types for

> [|| T $$(...) ||]

GHC is asked to compute the type of `T $$(..)`, which panics because
of the bogus type of T applied to `HsSpliced`, which is not type
correct.

The fix is to not attempt to compute the type for `HsSpliceE`
constructors if we come across them as they should have either been
already evaluated or lifted into a splice environment.

As part of the patch I made hie files traverse into the splice
environments so now we also get type information for things used inside
nested splices.

Fixes #21619

- - - - -
27f5c67e by Alan Zimmerman at 2022-11-01T17:46:56-04:00
EPA: DotFieldOcc does not have exact print annotations

For the code

    {-# LANGUAGE OverloadedRecordUpdate #-}

    operatorUpdate f = f{(+) = 1}

There are no exact print annotations for the parens around the +
symbol, nor does normal ppr print them.

This MR fixes that.

Closes #21805

(cherry picked from commit 792ef44d455c6e987f342fb61515464322a9fa77)

- - - - -
0633665f by Simon Peyton Jones at 2022-11-01T17:46:56-04:00
Fix arityType: -fpedantic-bottoms, join points, etc

This MR fixes #21694 and #21755

* For #21694 the underlying problem was that we were calling arityType
  on an expression that had free join points.  This is a Bad Bad Idea.
  See Note [No free join points in arityType].

* I also made andArityType work correctly with -fpedantic-bottoms;
  see Note [Combining case branches: andWithTail].

* I realised that, now we have ae_sigs giving the ArityType for
  let-bound Ids, we don't need the (pre-dating) special code in
  arityType for join points. But instead we need to extend the env for
  Rec bindings, which weren't doing before.  More uniform now.  See
  Note [arityType for let-bindings].

  This meant we could get rid of ae_joins, and in fact get rid of
  EtaExpandArity altogether.  Simpler.

  And finally, it was the strange treatment of join-point Ids (involving
  a fake ABot type) that led to a serious bug: #21755.  Fixed by this
  refactoring

* Rewrote Note [Combining case branches: optimistic one-shot-ness]

Compile time improves slightly on average:

Metrics: compile_time/bytes allocated
---------------------------------------------------------------------------------------
CoOpt_Read(normal) ghc/alloc    803,788,056    747,832,680  -7.1% GOOD
    T18223(normal) ghc/alloc    928,207,320    959,424,016  +3.1%  BAD
         geo. mean                                          -0.3%
         minimum                                            -7.1%
         maximum                                            +3.1%

On Windows it's a bit better: geo mean is -0.6%, and three more
benchmarks trip their compile-time bytes-allocated threshold (they
were all close on the other build):

   T18698b(normal) ghc/alloc    235,619,776    233,219,008  -1.0% GOOD
     T6048(optasm) ghc/alloc    112,208,192    109,704,936  -2.2% GOOD
    T18140(normal) ghc/alloc     85,064,192     83,168,360  -2.2% GOOD

I had a quick look at T18223 but it is knee deep in coercions and
the size of everything looks similar before and after.  I decided
to accept that 3.4% increase in exchange for goodness elsewhere.

Metric Decrease:
    CoOpt_Read
    LargeRecord
    ManyAlternatives
    ManyConstructors
    MultiComponentModules
    MultiComponentModulesRecomp
    T10421
    T12425
    T12707
    T13035
    T13253
    T13379
    T14683
    T15703
    T18698a
    T1969
    T3064
    T3294
    T4801
    T5321FD
    T5321Fun
    T5631
    T783
    T9020
    T9198
    T9233
    T9872b
    T9872c
    T9961
    parsing001
Metric Increase:
    T18223

(cherry picked from commit 5e282da37e19a1ab24ae167daf32276a64ed2842)

- - - - -
f4200e22 by Ben Gamari at 2022-11-01T17:49:13-04:00
Bump process submodule to v1.6.16.0

- - - - -


30 changed files:

- compiler/GHC/Core.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Syn/Type.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Parser/PostProcess.hs
- compiler/Language/Haskell/Syntax/Expr.hs
- libraries/process
- + testsuite/tests/arityanal/should_compile/Arity17.hs
- + testsuite/tests/arityanal/should_compile/T21755.hs
- + testsuite/tests/arityanal/should_compile/T21755.stderr
- testsuite/tests/arityanal/should_compile/all.T
- + testsuite/tests/callarity/should_compile/T21694a.hs
- + testsuite/tests/callarity/should_compile/T21694a.stderr
- testsuite/tests/hiefile/should_compile/all.T
- + testsuite/tests/hiefile/should_compile/hie011.hs
- + testsuite/tests/hiefile/should_compile/hie011.stderr
- + testsuite/tests/hiefile/should_run/SpliceTypes.hs
- + testsuite/tests/hiefile/should_run/SpliceTypes.stdout
- testsuite/tests/hiefile/should_run/all.T
- testsuite/tests/linters/notes.stdout
- testsuite/tests/printer/Makefile
- + testsuite/tests/printer/Test21805.hs
- testsuite/tests/printer/all.T
- + testsuite/tests/simplCore/should_compile/T21694b.hs
- + testsuite/tests/simplCore/should_compile/T21694b.stderr
- utils/check-exact/ExactPrint.hs
- utils/check-exact/Main.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/9c08d9a1b40c8c66a5fdcd6cb1b02b20121c93c4...f4200e2219606e73d051f0e2de98cf75d72bd683

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/9c08d9a1b40c8c66a5fdcd6cb1b02b20121c93c4...f4200e2219606e73d051f0e2de98cf75d72bd683
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/20221102/484bef6a/attachment.html>


More information about the ghc-commits mailing list