[Git][ghc/ghc][wip/T25029] 9 commits: haddock: Build haddock-api and haddock-library using hadrian

Simon Peyton Jones (@simonpj) gitlab at gitlab.haskell.org
Tue Aug 13 23:24:22 UTC 2024 


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


Commits:
6ae4b76a by Zubin Duggal at 2024-08-13T13:36:57-04:00
haddock: Build haddock-api and haddock-library using hadrian

We build these two packages as regular boot library dependencies rather
than using the `in-ghc-tree` flag to include the source files into the haddock
executable.

The `in-ghc-tree` flag is moved into haddock-api to ensure that haddock built
from hackage can still find the location of the GHC bindist using `ghc-paths`.

Addresses #24834

This causes a metric decrease under non-release flavours because under these
flavours libraries are compiled with optimisation but executables are not.

Since we move the bulk of the code from the haddock executable to the
haddock-api library, we see a metric decrease on the validate flavours.

Metric Decrease:
    haddock.Cabal
    haddock.base
    haddock.compiler

- - - - -
51ffba5d by Arnaud Spiwack at 2024-08-13T13:37:50-04:00
Add an extension field to HsRecFields

This is the Right Thing to Do™. And it prepares for storing a
multiplicity coercion there.

First step of the plan outlined here and below
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12947#note_573091

- - - - -
4d2faeeb by Arnaud Spiwack at 2024-08-13T13:37:50-04:00
Add test for #24961

- - - - -
623b4337 by Arnaud Spiwack at 2024-08-13T13:37:50-04:00
Ensures that omitted record fields in pattern have multiplicity Many

Omitted fields were simply ignored in the type checker and produced
incorrect Core code.

Fixes #24961

Metric Increase:
    RecordUpdPerf

- - - - -
c749bdfd by Sylvain Henry at 2024-08-13T13:38:41-04:00
AARCH64 linker: skip NONE relocations

This patch is part of the patches upstreamed from haskell.nix.
See https://github.com/input-output-hk/haskell.nix/pull/1960 for the
original report/patch.

- - - - -
682a6a41 by Brandon Chinn at 2024-08-13T13:39:17-04:00
Support multiline strings in TH

- - - - -
8562e6f6 by Simon Peyton Jones at 2024-08-14T00:21:37+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.

- - - - -
fb697b0e by Simon Peyton Jones at 2024-08-14T00:23:43+01:00
Don't introduce 'nospec' on the LHS of a RULE

This patch address #25160.  The main payload is:

* When desugaring the LHS of a RULE, do not introduce the `nospec` call
  for non-canonical evidence.  See GHC.Core.InstEnv
  Note [Coherence and specialisation: overview]

  The `nospec` call usually introdued in `dsHsWrapper`, but we don't want it
  on the LHS of a RULE (that's what caused #25160).  So now `dsHsWrapper` takes
  a flag to say if it's on the LHS of a RULE.  See wrinkle (NC1) in
  `Note [Desugaring non-canonical evidence]` in GHC.HsToCore.Binds.

But I think this flag will go away again when I have finished with my
(entirely separate) speciaise-on-values patch (#24359).

All this meant I had to re-understand the `nospec` stuff and coherence, and
that in turn made me do some refactoring, and add a lot of new documentation

The big change is that in GHC.Core.InstEnv, I changed
  the /type synonym/ `Canonical` into
  a /data type/ `CanonicalEvidence`
and documented it a lot 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]`.

- - - - -
db0dcf8b by Simon Peyton Jones at 2024-08-14T00:23:43+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.

- - - - -


30 changed files:

- compiler/GHC/Core/InstEnv.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/HsToCore/Arrows.hs
- compiler/GHC/HsToCore/Binds.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/Monad.hs
- compiler/GHC/HsToCore/Pmc/Desugar.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/HsToCore/Ticks.hs
- compiler/GHC/HsToCore/Utils.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/Rename/Pat.hs
- compiler/GHC/Tc/Deriv/Generate.hs
- compiler/GHC/Tc/Errors.hs
- compiler/GHC/Tc/Gen/Bind.hs
- compiler/GHC/Tc/Gen/Expr.hs
- compiler/GHC/Tc/Gen/Pat.hs
- compiler/GHC/Tc/Gen/Splice.hs
- compiler/GHC/Tc/Instance/Class.hs
- compiler/GHC/Tc/Solver.hs
- compiler/GHC/Tc/Solver/Dict.hs
- compiler/GHC/Tc/Solver/Equality.hs
- compiler/GHC/Tc/Solver/Irred.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f8435e8b424fc52eba80d8aaf473798ae84aa43b...db0dcf8bf9df93ab42bf8aefc288a62223e54af9

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f8435e8b424fc52eba80d8aaf473798ae84aa43b...db0dcf8bf9df93ab42bf8aefc288a62223e54af9
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/20240813/3206e055/attachment.html>

More information about the ghc-commits mailing list