[Git][ghc/ghc][wip/global-package-db] 8 commits: Introduce ListTuplePuns extension

Mon Mar 4 13:07:05 UTC 2024

Matthew Pickering pushed to branch wip/global-package-db at Glasgow Haskell Compiler / GHC

Commits:
d91d00fc by Torsten Schmits at 2024-03-01T15:01:50-05:00
Introduce ListTuplePuns extension

This implements Proposal 0475, introducing the `ListTuplePuns` extension
which is enabled by default.

Disabling this extension makes it invalid to refer to list, tuple and
sum type constructors by using built-in syntax like `[Int]`,
`(Int, Int)`, `(# Int#, Int# #)` or `(# Int | Int #)`.
Instead, this syntax exclusively denotes data constructors for use with
`DataKinds`.
The conventional way of referring to these data constructors by
prefixing them with a single quote (`'(Int, Int)`) is now a parser
error.

Tuple declarations have been moved to `GHC.Tuple.Prim` and the `Solo`
data constructor has been renamed to `MkSolo` (in a previous commit).
Unboxed tuples and sums now have real source declarations in `GHC.Types`.
Unit and solo types for tuples are now called `Unit`, `Unit#`, `Solo`
and `Solo#`.
Constraint tuples now have the unambiguous type constructors `CTuple<n>`
as well as `CUnit` and `CSolo`, defined in `GHC.Classes` like before.

A new parser construct has been added for the unboxed sum data
constructor declarations.

The type families `Tuple`, `Sum#` etc. that were intended to provide
nicer syntax have been omitted from this change set due to inference
problems, to be implemented at a later time.
See the MR discussion for more info.

Updates the submodule utils/haddock.
Updates the cabal submodule due to new language extension.

    Metric Increase:
        haddock.base

    Metric Decrease:
        MultiLayerModulesTH_OneShot
        size_hello_artifact

Proposal document: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0475-tuple-syntax.rst

Merge request: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8820

Tracking ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/21294

- - - - -
bbdb6286 by Sylvain Henry at 2024-03-01T15:01:50-05:00
JS linker: filter unboxed tuples

- - - - -
dec6d8d3 by Arnaud Spiwack at 2024-03-01T15:02:30-05:00
Improve error messages coming from non-linear patterns

This enriched the `CtOrigin` for non-linear patterns to include data
of the pattern that created the constraint (which can be quite useful
if it occurs nested in a pattern) as well as an explanation why the
pattern is non-restricted in (at least in some cases).

- - - - -
6612388e by Arnaud Spiwack at 2024-03-01T15:02:30-05:00
Adjust documentation of linear lets according to committee decision

- - - - -
1c064ef1 by Cheng Shao at 2024-03-02T17:11:19-05:00
compiler: start deprecating cmmToRawCmmHook

cmmToRawCmmHook was added 4 years ago in
d561c8f6244f8280a2483e8753c38e39d34c1f01. Its only user is the
Asterius project, which has been archived and deprecated in favor of
the ghc wasm backend. This patch starts deprecating cmmToRawCmmHook by
placing a DEPRECATED pragma, and actual removal shall happen in a
future GHC major release if no issue to oppose the deprecation has
been raised in the meantime.

- - - - -
9b74845f by Andrew Lelechenko at 2024-03-02T17:11:55-05:00
Data.List.NonEmpty.unzip: use WARNING with category instead of DEPRECATED

CLC proposal: https://github.com/haskell/core-libraries-committee/issues/258

- - - - -
9fffd397 by Matthew Pickering at 2024-03-04T12:43:58+00:00
Read global package database from settings file

Before this patch, the global package database was always assumed to be
in libdir </> package.conf.d.

This causes issues in GHC's build system because there are sometimes
situations where the package database you need to use is not located in
the same place as the settings file.

* The stage1 compiler needs to use stage2 libraries, so we should set
  "Global Package DB" for the stage1 compiler to the stage2 package
  database.
* Stage 2 cross compilers need to use stage3 libraries, so likewise, we
  should set to stage

* When installing we have rearranged everything so that the settings
  file and package database line up properly, so then everything should
  continue to work as before.

* ghc-pkg needs to be modified as well to look in the settings file fo
  the package database rather than assuming the global package database
  location relative to the lib folder.

* Cabal/cabal-install will work correctly because they query the global
  package database using `--print-global-package-db`.

A reasonable question is why not generate the "right" settings files in
the right places in GHC's build system. In order to do this you would
need to engineer wrappers for all executables to point to a specific
libdir. There are also situations where the same package db is used by
two different compilers with two different settings files (think stage2
cross compiler and stage3 compiler).

In short, this 10 line patch allows for some reasonable simplifications
in Hadrian at very little cost to anything else.

- - - - -
6a9a06de by Matthew Pickering at 2024-03-04T13:06:47+00:00
hadrian: Remove stage1 testsuite wrappers logic

Now instead of producing wrappers which pass the global package database
argument to ghc and ghc-pkg, we write the location of the correct
package database into the settings file so you can just use the intree
compiler directly.

- - - - -

30 changed files:

- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/Types.hs
- compiler/GHC/Builtin/Types.hs-boot
- compiler/GHC/Builtin/Uniques.hs
- compiler/GHC/Core/Predicate.hs
- compiler/GHC/Data/Bag.hs
- compiler/GHC/Driver/DynFlags.hs
- compiler/GHC/Driver/Hooks.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/HsToCore/Match/Constructor.hs
- compiler/GHC/Iface/Type.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/Errors/Ppr.hs
- compiler/GHC/Parser/Errors/Types.hs
- compiler/GHC/Parser/Lexer.x
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Runtime/Eval.hs
- compiler/GHC/Settings/IO.hs
- compiler/GHC/StgToJS/Linker/Linker.hs
- compiler/GHC/StgToJS/Linker/Utils.hs
- compiler/GHC/StgToJS/Utils.hs
- compiler/GHC/Tc/Errors.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Gen/Bind.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Tc/Gen/Pat.hs
- compiler/GHC/Tc/Instance/Typeable.hs
- compiler/GHC/Tc/Types/Origin.hs

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/187b4a5310600331c4c54177143b4c46df9d641f...6a9a06debfc3acf933734c0b0e681e92e928e899

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/187b4a5310600331c4c54177143b4c46df9d641f...6a9a06debfc3acf933734c0b0e681e92e928e899
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/20240304/30b85907/attachment.html>