[Git][ghc/ghc][wip/int-index/emb-type] 5 commits: Do primop rep-poly checks when instantiating

Vladislav Zavialov (@int-index) gitlab at gitlab.haskell.org
Tue Jul 18 16:40:15 UTC 2023



Vladislav Zavialov pushed to branch wip/int-index/emb-type at Glasgow Haskell Compiler / GHC


Commits:
889c2bbb by sheaf at 2023-07-18T06:37:32-04:00
Do primop rep-poly checks when instantiating

This patch changes how we perform representation-polymorphism checking
for primops (and other wired-in Ids such as coerce).
When instantiating the primop, we check whether each type variable
is required to instantiated to a concrete type, and if so we create a
new concrete metavariable (a ConcreteTv) instead of a simple MetaTv.
(A little subtlety is the need to apply the substitution obtained from
instantiating to the ConcreteTvOrigins, see
Note [substConcreteTvOrigin] in GHC.Tc.Utils.TcMType.)

This allows us to prevent representation-polymorphism in non-argument
position, as that is required for some of these primops.

We can also remove the logic in tcRemainingValArgs, except for
the part concerning representation-polymorphic unlifted newtypes.
The function has been renamed rejectRepPolyNewtypes; all it does now
is reject unsaturated occurrences of representation-polymorphic newtype
constructors when the representation of its argument isn't a concrete
RuntimeRep (i.e. still a PHASE 1 FixedRuntimeRep check).
The Note [Eta-expanding rep-poly unlifted newtypes] in GHC.Tc.Gen.Head
gives more explanation about a possible path to PHASE 2, which would be
in line with the treatment for primops taken in this patch.

We also update the Core Lint check to handle this new framework. This
means Core Lint now checks representation-polymorphism in continuation
position like needed for catch#.

Fixes #21906

-------------------------
Metric Increase:
    LargeRecord
-------------------------

- - - - -
00648e5d by Krzysztof Gogolewski at 2023-07-18T06:38:10-04:00
Core Lint: distinguish let and letrec in locations

Lint messages were saying "in the body of letrec" even for non-recursive
let.

I've also renamed BodyOfLetRec to BodyOfLet in stg, since there's no
separate letrec.

- - - - -
787bae96 by Krzysztof Gogolewski at 2023-07-18T06:38:50-04:00
Use extended literals when deriving Show

This implements GHC proposal
https://github.com/ghc-proposals/ghc-proposals/pull/596

Also add support for Int64# and Word64#; see testcase ShowPrim.

- - - - -
257f1567 by Jaro Reinders at 2023-07-18T06:39:29-04:00
Add StgFromCore and StgCodeGen linting

- - - - -
2222f5f8 by Vladislav Zavialov at 2023-07-18T18:30:26+02:00
Visible forall in types of terms: Part 1

This patch implements part 1 of GHC Proposal #281,
introducing explicit `type` patterns and `type` arguments.

Summary of the changes:

1. New extension flag:
     RequiredTypeArguments

2. New user-facing syntax:
     `type p` patterns    (represented by EmbTyPat)
     `type e` expressions (represented by HsEmbTy)

3. Functions with required type arguments (visible forall)
   can now be defined and applied:
      idv :: forall a -> a -> a    -- signature   (relevant change: checkVdqOK in GHC/Tc/Validity.hs)
      idv (type a) (x :: a) = x    -- definition  (relevant change: tcPats in GHC/Tc/Gen/Pat.hs)
      x = idv (type Int) 42        -- usage       (relevant change: tcInstFun in GHC/Tc/Gen/App.hs)

4. template-haskell support:
      TH.TypeE corresponds to HsEmbTy
      TH.TypeP corresponds to EmbTyPat

5. Test cases and a new User's Guide section

Changes *not* included here are the t2t (term-to-type) transformation
and term variable capture; those belong to part 2.

- - - - -


30 changed files:

- compiler/GHC/Builtin/Names/TH.hs
- compiler/GHC/Builtin/PrimOps.hs
- compiler/GHC/Builtin/PrimOps/Ids.hs
- compiler/GHC/Builtin/Types.hs
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/Core.hs
- compiler/GHC/Core/DataCon.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/TyCo/Subst.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Driver/Config/Core/Lint.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Syn/Type.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Match.hs
- compiler/GHC/HsToCore/Pmc/Desugar.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/HsToCore/Ticks.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/Bind.hs
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/Rename/Pat.hs
- compiler/GHC/Stg/Lint.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/643b1dae62f41280850855aaaf29d3742c648874...2222f5f8f8f785f77ba9a179057d4603bc9530e5

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/643b1dae62f41280850855aaaf29d3742c648874...2222f5f8f8f785f77ba9a179057d4603bc9530e5
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/20230718/3ceb1822/attachment.html>


More information about the ghc-commits mailing list