[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 5 commits: Utils.JSON: do not escapeJsonString in ToJson String instance

[Marge Bot (@marge-bot)]

Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC


Commits:
ed4b5885 by Joachim Breitner at 2022-10-10T23:16:11-04:00
Utils.JSON: do not escapeJsonString in ToJson String instance

as `escapeJsonString` is used in `renderJSON`, so the `JSString`
constructor is meant to carry the unescaped string.

- - - - -
3ab55b59 by Matthew Pickering at 2022-10-11T05:48:12-04:00
Tidy implicit binds

We want to put implicit binds into fat interface files, so the easiest
thing to do seems to be to treat them uniformly with other binders.

- - - - -
449ca867 by Matthew Pickering at 2022-10-11T05:48:12-04:00
Interface Files with Core Definitions

This commit adds three new flags

* -fwrite-if-simplified-core: Writes the whole core program into an interface
  file
* -fbyte-code-and-object-code: Generate both byte code and object code
  when compiling a file
* -fprefer-byte-code: Prefer to use byte-code if it's available when
  running TH splices.

The goal for including the core bindings in an interface file is to be able to restart the compiler pipeline
at the point just after simplification and before code generation. Once compilation is
restarted then code can be created for the byte code backend.
This can significantly speed up
start-times for projects in GHCi. HLS already implements its own version of these extended interface
files for this reason.

Preferring to use byte-code means that we can avoid some potentially
expensive code generation steps (see #21700)

* Producing object code is much slower than producing bytecode, and normally you
  need to compile with `-dynamic-too` to produce code in the static and dynamic way, the
  dynamic way just for Template Haskell execution when using a dynamically linked compiler.

* Linking many large object files, which happens once per splice, can be quite
  expensive compared to linking bytecode.

And you can get GHC to compile the necessary byte code so
`-fprefer-byte-code` has access to it by using
`-fbyte-code-and-object-code`.

Fixes #21067

- - - - -
d695e730 by Matthew Pickering at 2022-10-11T05:48:12-04:00
Teach -fno-code about -fprefer-byte-code

This patch teachs the code generation logic of -fno-code about
-fprefer-byte-code, so that if we need to generate code for a module
which prefers byte code, then we generate byte code rather than object
code.

We keep track separately which modules need object code and which byte
code and then enable the relevant code generation for each. Typically
the option will be enabled globally so one of these sets should be empty
and we will just turn on byte code or object code generation.

We also fix the bug where we would generate code for a module which
enables Template Haskell despite the fact it was unecessary.

Fixes #22016

- - - - -
87aaea11 by Matthew Pickering at 2022-10-11T05:48:15-04:00
Don't include BufPos in interface files

Ticket #22162 pointed out that the build directory was leaking into the
ABI hash of a module because the BufPos depended on the location of the
build tree.

BufPos is only used in GHC.Parser.PostProcess.Haddock, and the
information doesn't need to be propagated outside the context of a
module.

Fixes #22162

- - - - -


30 changed files:

- compiler/GHC/CoreToIface.hs
- compiler/GHC/Driver/Backpack.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- compiler/GHC/Driver/Pipeline/Phases.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Iface/Ext/Types.hs
- compiler/GHC/Iface/Load.hs
- compiler/GHC/Iface/Make.hs
- compiler/GHC/Iface/Recomp.hs
- compiler/GHC/Iface/Syntax.hs
- compiler/GHC/Iface/Tidy.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Linker/Loader.hs
- compiler/GHC/Linker/Types.hs
- compiler/GHC/Runtime/Eval.hs
- compiler/GHC/Runtime/Interpreter.hs
- compiler/GHC/Types/SrcLoc.hs
- compiler/GHC/Unit/Home/ModInfo.hs
- compiler/GHC/Unit/Module/Graph.hs
- compiler/GHC/Unit/Module/ModIface.hs
- compiler/GHC/Unit/Module/Status.hs
- + compiler/GHC/Unit/Module/WholeCoreBindings.hs
- compiler/GHC/Utils/Binary.hs
- compiler/GHC/Utils/Json.hs
- compiler/ghc.cabal.in
- docs/users_guide/phases.rst


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f6085913ec38ecead100fbe186ae77291fb8e4db...87aaea11565de48ad6523b99c31a9bb2c73ce269

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f6085913ec38ecead100fbe186ae77291fb8e4db...87aaea11565de48ad6523b99c31a9bb2c73ce269
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/20221011/42af6a62/attachment-0001.html>