[Git][ghc/ghc][wip/T23942] 21 commits: Rephrase error message to say "visible arguments" (#24318)

Matthew Craven (@clyring) gitlab at gitlab.haskell.org
Sat Mar 9 03:32:54 UTC 2024



Matthew Craven pushed to branch wip/T23942 at Glasgow Haskell Compiler / GHC


Commits:
9cd9efb4 by Vladislav Zavialov at 2024-03-07T13:01:54+03:00
Rephrase error message to say "visible arguments" (#24318)

* Main change: make the error message generated by mkFunTysMsg more
  accurate by changing "value arguments" to "visible arguments".

* Refactor: define a new type synonym VisArity and use it instead of
  Arity in a few places.

It might be the case that there other places in the compiler that should
talk about visible arguments rather than value arguments, but I haven't
tried to find them all, focusing only on the error message reported in
the ticket.

- - - - -
d523a6a7 by Ben Gamari at 2024-03-07T19:40:45-05:00
Bump array submodule

- - - - -
7e55003c by Ben Gamari at 2024-03-07T19:40:45-05:00
Bump stm submodule

- - - - -
32d337ef by Ben Gamari at 2024-03-07T19:40:45-05:00
Introduce exception context

Here we introduce the `ExceptionContext` type and `ExceptionAnnotation`
class, allowing dynamically-typed user-defined annotations to be
attached to exceptions.

CLC Proposal: https://github.com/haskell/core-libraries-committee/issues/199
GHC Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/330

- - - - -
39f3d922 by Ben Gamari at 2024-03-07T19:40:46-05:00
testsuite/interface-stability: Update documentation

- - - - -
fdea7ada by Ben Gamari at 2024-03-07T19:40:46-05:00
ghc-internal: comment formatting

- - - - -
4fba42ef by Ben Gamari at 2024-03-07T19:40:46-05:00
compiler: Default and warn ExceptionContext constraints

- - - - -
3886a205 by Ben Gamari at 2024-03-07T19:40:46-05:00
base: Introduce exception backtraces

Here we introduce the `Backtraces` type and associated machinery for
attaching these via `ExceptionContext`. These has a few compile-time
regressions (`T15703` and `T9872d`) due to the additional dependencies
in the exception machinery.

As well, there is a surprisingly large regression in the
`size_hello_artifact` test. This appears to be due to various `Integer` and
`Read` bits now being reachable at link-time. I believe it should be
possible to avoid this but I have accepted the change for now to get the
feature merged.

CLC Proposal: https://github.com/haskell/core-libraries-committee/issues/199
GHC Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/330

Metric Increase:
    T15703
    T9872d
    size_hello_artifact

- - - - -
18c5409f by Ben Gamari at 2024-03-07T19:40:46-05:00
users guide: Release notes for exception backtrace work

- - - - -
f849c5fc by Ben Gamari at 2024-03-07T19:40:46-05:00
compiler: Don't show ExceptionContext of GhcExceptions

Most GhcExceptions are user-facing errors and therefore the
ExceptionContext has little value. Ideally we would enable
it in the DEBUG compiler but I am leaving this for future work.

- - - - -
dc646e6f by Sylvain Henry at 2024-03-07T19:40:46-05:00
Disable T9930fail for the JS target (cf #19174)

- - - - -
bfc09760 by Alan Zimmerman at 2024-03-07T19:41:22-05:00
Update showAstData to honour blanking of AnnParen

Also tweak rendering of SrcSpan to remove extra blank line.

- - - - -
50454a29 by Ben Gamari at 2024-03-08T03:32:42-05:00
ghc-internal: Eliminate GHC.Internal.Data.Kind

This was simply reexporting things from `ghc-prim`. Instead reexport
these directly from `Data.Kind`. Also add build ordering dependency to
work around #23942.

- - - - -
38a4b6ab by Ben Gamari at 2024-03-08T03:33:18-05:00
rts: Fix SET_HDR initialization of retainer set

This fixes a regression in retainer set profiling introduced by
b0293f78cb6acf2540389e22bdda420d0ab874da. Prior to that commit
the heap traversal word would be initialized by `SET_HDR` using
`LDV_RECORD_CREATE`. However, the commit added a `doingLDVProfiling`
check in `LDV_RECORD_CREATE`, meaning that this initialization no longer
happened.

Given that this initialization was awkwardly indirectly anyways, I have
fixed this by explicitly initializating the heap traversal word to
`NULL` in `SET_PROF_HDR`. This is equivalent to the previous behavior,
but much more direct.

Fixes #24513.

- - - - -
35de5373 by Matthew Craven at 2024-03-08T16:01:07-05:00
CorePrep: Rework lowering of BigNat# literals

Don't use bigNatFromWord#, because that's terrible:
 * We shouldn't have to traverse a linked list at run-time
   to build a BigNat# literal. That's just silly!
 * The static List object we have to create is much larger
   than the actual BigNat#'s contents, bloating code size.
 * We have to read the corresponding interface file,
   which causes un-tracked implicit dependencies. (#23942)

Instead, encode them into the appropriate platform-dependent
sequence of bytes, and generate code that copies these bytes
at run-time from an Addr# literal into a new ByteArray#.
A ByteArray# literal would be the correct thing to generate,
but these are not yet supported; see also #17747.

Since this lowering no longer reads the interface file for
GHC.Num.BigNat, the reasoning in Note [Depend on GHC.Num.Integer]
is obsoleted.  But the story of un-tracked built-in dependencies
remains complex, and Note [Tracking dependencies on primitives]
now exists to explain this complexity.

- - - - -
69583bdb by Matthew Craven at 2024-03-08T16:01:07-05:00
small fixes and improvements

- - - - -
a776b257 by Matthew Craven at 2024-03-08T16:01:08-05:00
Accept test output changes

- - - - -
2a506880 by Matthew Craven at 2024-03-08T16:01:08-05:00
review suggestion

- - - - -
177e258e by Matthew Craven at 2024-03-08T22:30:44-05:00
Mess with an awful lot of build-order imports

- - - - -
7530714c by Matthew Craven at 2024-03-08T22:31:24-05:00
Improve a variable name

- - - - -
2e20ca9d by Matthew Craven at 2024-03-08T22:31:59-05:00
'toStrict' is not exported from Data.ByteString until 0.11

- - - - -


30 changed files:

- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/PrimOps.hs-boot
- compiler/GHC/Builtin/Types/Prim.hs
- compiler/GHC/Cmm/Dominators.hs
- compiler/GHC/Core/Predicate.hs
- compiler/GHC/Core/TyCo/Subst.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Data/Word64Map/Strict.hs
- compiler/GHC/Driver/CmdLine.hs
- compiler/GHC/Driver/Config/CoreToStg/Prep.hs
- compiler/GHC/Driver/Config/Diagnostic.hs
- compiler/GHC/Driver/Errors/Ppr.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Hs/Dump.hs
- compiler/GHC/Iface/Errors/Ppr.hs
- compiler/GHC/Iface/Syntax.hs
- compiler/GHC/Iface/Type.hs-boot
- compiler/GHC/Parser/Annotation.hs
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Platform.hs
- compiler/GHC/StgToJS/Types.hs
- compiler/GHC/Tc/Errors/Hole/Plugin.hs-boot
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Errors/Types.hs
- compiler/GHC/Tc/Gen/Match.hs
- compiler/GHC/Tc/Solver.hs
- compiler/GHC/Tc/Types/LclEnv.hs-boot
- compiler/GHC/Tc/Utils/Env.hs
- compiler/GHC/Tc/Utils/Unify.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/438278dd05e17598384b5bd74c930ad1747317a9...2e20ca9d12b4f3b64b2e51a258e6c929c5de4f59

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/438278dd05e17598384b5bd74c930ad1747317a9...2e20ca9d12b4f3b64b2e51a258e6c929c5de4f59
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/20240308/04ee0224/attachment-0001.html>


More information about the ghc-commits mailing list