[Git][ghc/ghc][wip/T25029] 6 commits: Print exception metadata in default handler

Simon Peyton Jones (@simonpj) gitlab at gitlab.haskell.org
Sat Aug 3 22:45:37 UTC 2024



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


Commits:
ff158fcd by Tommy Bidne at 2024-08-02T01:14:32+12:00
Print exception metadata in default handler

CLC proposals 231 and 261:

- Add exception type metadata to SomeException's displayException.
- Add "Exception" header to default exception handler.

See:

https://github.com/haskell/core-libraries-committee/issues/231
https://github.com/haskell/core-libraries-committee/issues/261

Update stm submodule for test fixes.

- - - - -
8b2f70a2 by Andrei Borzenkov at 2024-08-01T23:00:46-04:00
Type syntax in expressions (#24159, #24572, #24226)

This patch extends the grammar of expressions with syntax that is
typically found only in types:
  * function types (a -> b), (a ->. b), (a %m -> b)
  * constrained types (ctx => t)
  * forall-quantification (forall tvs. t)

The new forms are guarded behind the RequiredTypeArguments extension,
as specified in GHC Proposal #281. Examples:

  {-# LANGUAGE RequiredTypeArguments #-}
  e1 = f (Int    -> String)          -- function type
  e2 = f (Int %1 -> String)          -- linear function type
  e3 = f (forall a. Bounded a => a)  -- forall type, constraint

The GHC AST and the TH AST have been extended as follows:

   syntax        | HsExpr   | TH.Exp
  ---------------+----------+--------------
   a -> b        | HsFunArr | ConE (->)
   a %m -> b     | HsFunArr | ConE FUN
   ctx => t      | HsQual   | ConstrainedE
   forall a. t   | HsForAll | ForallE
   forall a -> t | HsForAll | ForallVisE

Additionally, a new warning flag -Wview-pattern-signatures has been
introduced to aid with migration to the new precedence of (e -> p :: t).

Co-authored-by: Vladislav Zavialov <vlad.z.4096 at gmail.com>

- - - - -
66e7f57d by Brandon Chinn at 2024-08-01T21:50:58-07:00
Implement MultilineStrings (#24390)

This commit adds support for multiline strings, proposed at
https://github.com/ghc-proposals/ghc-proposals/pull/569.
Multiline strings can now be written as:

    myString =
      """
      this is a
      multiline string
      """

The multiline string will have leading indentation stripped away.
Full details of this post-processing may be found at the new
GHC.Parser.String module.

In order to cleanly implement this and maximize reusability, I
broke out the lexing logic for strings out of Lexer.x into a
new GHC.Parser.String module, which lexes strings with any
provided "get next character" function. This also gave us the
opportunity to clean up this logic, and even optimize it a bit.
With this change, parsing string literals now takes 25% less
time and 25% less space.

- - - - -
cf47b96f by Rodrigo Mesquita at 2024-08-03T05:59:40-04:00
hi: Stable sort avails

Sorting the Avails in DocStructures is required to produce fully
deterministic interface files in presence of re-exported modules.

Fixes #25104

- - - - -
f3692f6d by Simon Peyton Jones at 2024-08-03T23:45:24+01:00
Refactor only newSysLocalDs

* Change newSysLocalDs to take a scaled type
* Add newSysLocalMDs that takes a type and makes a ManyTy local

Lots of files touched, nothing deep.

- - - - -
6ce2a69f by Simon Peyton Jones at 2024-08-03T23:45:24+01:00
Add defaulting of equalities

This MR adds one new defaulting strategy to the top-level
defaulting story: see Note [Defaulting equalities] in GHC.Tc.Solver.

This resolves #25029 and #25125, which showed that users were
accidentally relying on a GHC bug, which was fixed by

    commit 04f5bb85c8109843b9ac2af2a3e26544d05e02f4
    Author: Simon Peyton Jones <simon.peytonjones at gmail.com>
    Date:   Wed Jun 12 17:44:59 2024 +0100

    Fix untouchability test

    This MR fixes #24938.  The underlying problem was tha the test for
    "does this implication bring in scope any equalities" was plain wrong.

This fix gave rise to a number of user complaints; but the improved
defaulting story of this MR largely resolves them.

On the way I did a bit of refactoring, of course

* Completely restructure the extremely messy top-level defaulting
  code. The new code is in GHC.Tc.Solver.tryDefaulting, and is much,
  much, much esaier to grok.

* In GHC.Core.InstEnv, change the type synonym `Canonical` to a data
  type `CanonicalEvidence`; and document it better.  That in turn made
  me realise that CalLStacks were being treated with a bit of a hack, which
  I documented in `Note [CallStack and ExecptionContext hack]`.

* Fix a bug I found when desugaring RULE left hand sides; see (NC1) in
  Note [Desugaring non-canonical evidence] in GHC.HsToCore.Binds
  This means giving a boolean flag to dsHsWrapper, alas.  But I think it
  will go away again when I have finished with my (entirely separate)
  speciaise-on-values patch.

- - - - -


30 changed files:

- compiler/GHC/Builtin/Names/TH.hs
- compiler/GHC/Core/InstEnv.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Hs/Doc.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/Hs/Lit.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Syn/Type.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/HsToCore/Arrows.hs
- compiler/GHC/HsToCore/Binds.hs
- compiler/GHC/HsToCore/Docs.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Foreign/C.hs
- compiler/GHC/HsToCore/Foreign/Call.hs
- compiler/GHC/HsToCore/Foreign/JavaScript.hs
- compiler/GHC/HsToCore/Foreign/Wasm.hs
- compiler/GHC/HsToCore/ListComp.hs
- compiler/GHC/HsToCore/Match/Literal.hs
- compiler/GHC/HsToCore/Monad.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/HsToCore/Ticks.hs
- compiler/GHC/HsToCore/Utils.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Iface/Make.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/Annotation.hs
- compiler/GHC/Parser/CharClass.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f324f6bcc6980f7ef141dd6114a00c2730eb4145...6ce2a69f75dde9c0ebf4e746f015ac7248a1c7b2

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f324f6bcc6980f7ef141dd6114a00c2730eb4145...6ce2a69f75dde9c0ebf4e746f015ac7248a1c7b2
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/20240803/da4a9b82/attachment.html>


More information about the ghc-commits mailing list