[Git][ghc/ghc][wip/romes/hardwire-ghc-unit-id] 50 commits: nonmoving: Disable slop-zeroing

Thu Apr 20 15:19:57 UTC 2023

Matthew Pickering pushed to branch wip/romes/hardwire-ghc-unit-id at Glasgow Haskell Compiler / GHC

Commits:
d1bb16ed by Ben Gamari at 2023-04-06T03:40:45-04:00
nonmoving: Disable slop-zeroing

As noted in #23170, the nonmoving GC can race with a mutator zeroing the
slop of an updated thunk (in much the same way that two mutators would
race). Consequently, we must disable slop-zeroing when the nonmoving GC
is in use.

Closes #23170

- - - - -
04b80850 by Brandon Chinn at 2023-04-06T03:41:21-04:00
Fix reverse flag for -Wunsupported-llvm-version
- - - - -
0c990e13 by Pierre Le Marre at 2023-04-06T10:16:29+00:00
Add release note for GHC.Unicode refactor in base-4.18.

Also merge CLC proposal 130 in base-4.19 with CLC proposal 59 in
base-4.18 and add proper release date.

- - - - -
cbbfb283 by Alex Dixon at 2023-04-07T18:27:45-04:00
Improve documentation for ($) (#22963)

- - - - -
5193c2b0 by Alex Dixon at 2023-04-07T18:27:45-04:00
Remove trailing whitespace from ($) commentary

- - - - -
b384523b by Sebastian Graf at 2023-04-07T18:27:45-04:00
Adjust wording wrt representation polymorphism of ($)
- - - - -
6a788f0a by Torsten Schmits at 2023-04-07T22:29:28-04:00
Add structured error messages for GHC.Tc.TyCl.Utils

Tracking ticket: #20117

MR: !10251

This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.

- - - - -
3ba77b36 by sheaf at 2023-04-07T22:30:07-04:00
Renamer: don't call addUsedGRE on an exact Name

When looking up a record field in GHC.Rename.Env.lookupRecFieldOcc,
we could end up calling addUsedGRE on an exact Name, which would then
lead to a panic in the bestImport function: it would be incapable of
processing a GRE which is not local but also not brought into scope
by any imports (as it is referred to by its unique instead).

Fixes #23240

- - - - -
bc4795d2 by Krzysztof Gogolewski at 2023-04-11T19:24:54-04:00
Add support for -debug in the testsuite

Confusingly, GhcDebugged referred to GhcDebugAssertions.

- - - - -
b7474b57 by Krzysztof Gogolewski at 2023-04-11T19:24:54-04:00
Add missing cases in -Di prettyprinter

Fixes #23142

- - - - -
6c392616 by Cheng Shao at 2023-04-11T19:25:31-04:00
compiler: make WasmCodeGenM an instance of MonadUnique

- - - - -
05d26a65 by Cheng Shao at 2023-04-11T19:25:31-04:00
compiler: apply cmm node-splitting for wasm backend

This patch applies cmm node-splitting for wasm32 NCG, which is
required when handling irreducible CFGs. Fixes #23237.

- - - - -
f1892cc0 by Bodigrim at 2023-04-11T19:26:09-04:00
Set base 'maintainer' field to CLC

- - - - -
ecf22da3 by Simon Peyton Jones at 2023-04-11T19:26:45-04:00
Clarify a couple of Notes about 'nospec'

- - - - -
ebd8918b by Oleg Grenrus at 2023-04-12T12:32:57-04:00
Allow generation of TTH syntax with TH

In other words allow generation of typed splices and brackets with
Untyped Template Haskell.

That is useful in cases where a library is build with TTH in mind,
but we still want to generate some auxiliary declarations,
where TTH cannot help us, but untyped TH can.
Such example is e.g. `staged-sop` which works with TTH,
but we would like to derive `Generic` declarations with TH.

An alternative approach is to use `unsafeCodeCoerce`, but then the
derived `Generic` instances would be type-checked only at use sites,
i.e. much later. Also `-ddump-splices` output is quite ugly:
user-written instances would use TTH brackets, not `unsafeCodeCoerce`.

This commit doesn't allow generating of untyped template splices
and brackets with untyped TH, as I don't know why one would want to do
that (instead of merging the splices, e.g.)

- - - - -
690d0225 by Rodrigo Mesquita at 2023-04-12T12:33:33-04:00
Add regression test for #23229

- - - - -
59321879 by Sylvain Henry at 2023-04-13T08:50:33-04:00
Add quotRem rules (#22152)

  case quotRemInt# x y of
     (# q, _ #) -> body
  ====>
   case quotInt# x y of
     q -> body

  case quotRemInt# x y of
     (# _, r #) -> body
  ====>
   case remInt# x y of
     r -> body

- - - - -
4dd02122 by Sylvain Henry at 2023-04-13T08:50:33-04:00
Add quot folding rule (#22152)

   (x / l1) / l2
   l1 and l2 /= 0
   l1*l2 doesn't overflow
   ==> x / (l1 * l2)

- - - - -
1148ac72 by Sylvain Henry at 2023-04-13T08:50:33-04:00
Make Int64/Word64 division ok for speculation too.

Only when the divisor is definitely non-zero.

- - - - -
8af401cc by Sylvain Henry at 2023-04-13T08:50:33-04:00
Make WordQuotRem2Op ok-for-speculation too

- - - - -
27d2978e by Josh Meredith at 2023-04-13T08:51:09-04:00
Base/JS: GHC.JS.Foreign.Callback module (issue 23126)

* Add the Callback module for "exporting" Haskell functions
to be available to plain JavaScript code

* Fix some primitives defined in GHC.JS.Prim

* Add a JavaScript section to the user guide with instructions
on how to use the JavaScript FFI, building up to using Callbacks
to interact with the browser

* Add tests for the JavaScript FFI and Callbacks

- - - - -
a34aa8da by Adam Sandberg Ericsson at 2023-04-14T04:17:52-04:00
rts: improve memory ordering and add some comments in the StablePtr implementation

- - - - -
d7a768a4 by Matthew Pickering at 2023-04-14T04:18:28-04:00
docs: Generate docs/index.html with version number

* Generate docs/index.html to include the version of the ghc library

* This also fixes the packageVersions interpolations which were
  - Missing an interpolation for `LIBRARY_ghc_VERSION`
  - Double quoting the version so that "9.7" was being inserted.

Fixes #23121

- - - - -
d48fbfea by Simon Peyton Jones at 2023-04-14T04:19:05-04:00
Stop if type constructors have kind errors

Otherwise we get knock-on errors, such as #23252.

This makes GHC fail a bit sooner, and I have not attempted to add
recovery code, to add a fake TyCon place of the erroneous one,
in an attempt to get more type errors in one pass.  We could
do that (perhaps) if there was a call for it.

- - - - -
2371d6b2 by Simon Peyton Jones at 2023-04-14T20:01:02+02:00
Major refactor in the handling of equality constraints

This MR substantially refactors the way in which the constraint
solver deals with equality constraints.  The big thing is:

* Intead of a pipeline in which we /first/ canonicalise and /then/
  interact (the latter including performing unification) the two steps
  are more closely integreated into one.  That avoids the current
  rather indirect communication between the two steps.

The proximate cause for this refactoring is fixing #22194, which involve
solving   [W] alpha[2] ~ Maybe (F beta[4])
by doing this:
          alpha[2] := Maybe delta[2]
          [W] delta[2] ~ F beta[4]
That is, we don't promote beta[4]!  This is very like introducing a cycle
breaker, and was very awkward to do before, but now it is all nice.
See GHC.Tc.Utils.Unify Note [Promotion and level-checking] and
Note [Family applications in canonical constraints].

The big change is this:

* Several canonicalisation checks (occurs-check, cycle-breaking,
  checking for concreteness) are combined into one new function:
     GHC.Tc.Utils.Unify.checkTyEqRhs

  This function is controlled by `TyEqFlags`, which says what to do
  for foralls, type families etc.

* `canEqCanLHSFinish` now sees if unification is possible, and if so,
  actually does it: see `canEqCanLHSFinish_try_unification`.

There are loads of smaller changes:

* The on-the-fly unifier `GHC.Tc.Utils.Unify.unifyType` has a
  cheap-and-cheerful version of `checkTyEqRhs`, called
  `simpleUnifyCheck`.  If `simpleUnifyCheck` succeeds, it can unify,
  otherwise it defers by emitting a constraint. This is simpler than
  before.

* I simplified the swapping code in `GHC.Tc.Solver.Equality.canEqCanLHS`.
  Especially the nasty stuff involving `swap_for_occurs` and
  `canEqTyVarFunEq`.  Much nicer now.  See
      Note [Orienting TyVarLHS/TyFamLHS]
      Note [Orienting TyFamLHS/TyFamLHS]

* Added `cteSkolemOccurs`, `cteConcrete`, and `cteCoercionHole` to the
  problems that can be discovered by `checkTyEqRhs`.

* I fixed #23199 `pickQuantifiablePreds`, which actually allows GHC to
  to accept both cases in #22194 rather than rejecting both.

Yet smaller:

* Added a `synIsConcrete` flag to `SynonymTyCon` (alongside `synIsFamFree`)
  to reduce the need for synonym expansion when checking concreteness.
  Use it in `isConcreteType`.

* Renamed `isConcrete` to `isConcreteType`

* Defined `GHC.Core.TyCo.FVs.isInjectiveInType` as a more efficient
  way to find if a particular type variable is used injectively than
  finding all the injective variables.  It is called in
  `GHC.Tc.Utils.Unify.definitely_poly`, which in turn is used quite a
  lot.

* Moved `rewriterView` to `GHC.Core.Type`, so we can use it from the
  constraint solver.

Fixes #22194, #23199

Compile times decrease by an average of 0.1%; but there is a 7.4%
drop in compiler allocation on T15703.

Metric Decrease:
    T15703

- - - - -
99b2734b by Simon Peyton Jones at 2023-04-14T20:01:02+02:00
Add some documentation about redundant constraints

- - - - -
3f2d0eb8 by Simon Peyton Jones at 2023-04-14T20:01:02+02:00
Improve partial signatures

This MR fixes #23223. The changes are in two places:

* GHC.Tc.Bind.checkMonomorphismRestriction
  See the new `Note [When the MR applies]`
  We now no longer stupidly attempt to apply the MR when the user
  specifies a context, e.g.   f :: Eq a => _ -> _

* GHC.Tc.Solver.decideQuantification
  See rewritten `Note [Constraints in partial type signatures]`

Fixing this bug apparently breaks three tests:

* partial-sigs/should_compile/T11192
* partial-sigs/should_fail/Defaulting1MROff
* partial-sigs/should_fail/T11122

However they are all symptoms of #23232, so I'm marking them as
expect_broken(23232).

I feel happy about this MR. Nice.

- - - - -
23e2a8a0 by Simon Peyton Jones at 2023-04-14T20:01:02+02:00
Make approximateWC a bit cleverer

This MR fixes #23224: making approximateWC more clever

See the long `Note [ApproximateWC]` in GHC.Tc.Solver

All this is delicate and ad-hoc -- but it /has/ to be: we are
talking about inferring a type for a binding in the presence of
GADTs, type families and whatnot: known difficult territory.
We just try as hard as we can.

- - - - -
2c040246 by Matthew Pickering at 2023-04-15T00:57:14-04:00
docs: Update template-haskell docs to use Code Q a rather than Q (TExp a)

Since GHC Proposal #195, the type of [|| ... ||] has been Code Q a
rather than Q (TExp a). The documentation in the `template-haskell`
library wasn't updated to reflect this change.

Fixes #23148

- - - - -
0da18eb7 by Krzysztof Gogolewski at 2023-04-15T14:35:53+02:00
Show an error when we cannot default a concrete tyvar

Fixes #23153

- - - - -
bad2f8b8 by sheaf at 2023-04-15T15:14:36+02:00
Handle ConcreteTvs in inferResultToType

inferResultToType was discarding the ir_frr information, which meant
some metavariables ended up being MetaTvs instead of ConcreteTvs.

This function now creates new ConcreteTvs as necessary, instead of
always creating MetaTvs.

Fixes #23154

- - - - -
3b0ea480 by Simon Peyton Jones at 2023-04-16T18:12:20-04:00
Transfer DFunId_ness onto specialised bindings

Whether a binding is a DFunId or not has consequences for the `-fdicts-strict`
flag, essentially if we are doing demand analysis for a DFunId then `-fdicts-strict` does
not apply because the constraint solver can create recursive groups of dictionaries.

In #22549 this was fixed for the "normal" case, see
Note [Do not strictify the argument dictionaries of a dfun].
However the loop still existed if the DFunId was being specialised.

The problem was that the specialiser would specialise a DFunId and
turn it into a VanillaId and so the demand analyser didn't know to
apply special treatment to the binding anymore and the whole recursive
group was optimised to bottom.

The solution is to transfer over the DFunId-ness of the binding in the specialiser so
that the demand analyser knows not to apply the `-fstrict-dicts`.

Fixes #22549

- - - - -
a1371ebb by Oleg Grenrus at 2023-04-16T18:12:59-04:00
Add import lists to few GHC.Driver.Session imports

Related to https://gitlab.haskell.org/ghc/ghc/-/issues/23261.
There are a lot of GHC.Driver.Session which only use DynFlags,
but not the parsing code.

- - - - -
51479ceb by Matthew Pickering at 2023-04-17T08:08:48-04:00
Account for special GHC.Prim import in warnUnusedPackages

The GHC.Prim import is treated quite specially primarily because there
isn't an interface file for GHC.Prim. Therefore we record separately in
the ModSummary if it's imported or not so we don't go looking for it.

This logic hasn't made it's way to `-Wunused-packages` so if you
imported GHC.Prim then the warning would complain you didn't use
`-package ghc-prim`.

Fixes #23212

- - - - -
1532a8b2 by Simon Peyton Jones at 2023-04-17T08:09:24-04:00
Add regression test for #23199

- - - - -
0158c5f1 by Ryan Scott at 2023-04-17T18:43:27-04:00
validDerivPred: Reject exotic constraints in IrredPreds

This brings the `IrredPred` case in sync with the treatment of `ClassPred`s as
described in `Note [Valid 'deriving' predicate]` in `GHC.Tc.Validity`. Namely,
we should reject `IrredPred`s that are inferred from `deriving` clauses whose
arguments contain other type constructors, as described in `(VD2) Reject exotic
constraints` of that Note.  This has the nice property that `deriving` clauses
whose inferred instance context mention `TypeError` will now emit the type
error in the resulting error message, which better matches existing intuitions
about how `TypeError` should work.

While I was in town, I noticed that much of `Note [Valid 'deriving' predicate]`
was duplicated in a separate `Note [Exotic derived instance contexts]` in
`GHC.Tc.Deriv.Infer`. I decided to fold the latter Note into the former so that
there is a single authority on describing the conditions under which an
inferred `deriving` constraint can be considered valid.

This changes the behavior of `deriving` in a way that existing code might
break, so I have made a mention of this in the GHC User's Guide. It seems very,
very unlikely that much code is relying on this strange behavior, however, and
even if there is, there is a clear, backwards-compatible migration path using
`StandaloneDeriving`.

Fixes #22696.

- - - - -
10364818 by Krzysztof Gogolewski at 2023-04-17T18:44:03-04:00
Misc cleanup

- Use dedicated list functions
- Make cloneBndrs and cloneRecIdBndrs monadic
- Fix invalid haddock comments in libraries/base

- - - - -
5e1d33d7 by Matthew Pickering at 2023-04-18T10:31:02-04:00
Convert interface file loading errors into proper diagnostics

This patch converts all the errors to do with loading interface files
into proper structured diagnostics.

* DriverMessage: Sometimes in the driver we attempt to load an interface
  file so we embed the IfaceMessage into the DriverMessage.
* TcRnMessage: Most the time we are loading interface files during
  typechecking, so we embed the IfaceMessage

This patch also removes the TcRnInterfaceLookupError constructor which
is superceded by the IfaceMessage, which is now structured compared to
just storing an SDoc before.

- - - - -
df1a5811 by sheaf at 2023-04-18T10:31:43-04:00
Don't panic in ltPatersonSize

The function GHC.Tc.Utils.TcType.ltPatersonSize would panic when it
encountered a type family on the RHS, as usually these are not allowed
(type families are not allowed on the RHS of class instances or of
quantified constraints). However, it is possible to still encounter
type families on the RHS after doing a bit of constraint solving, as
seen in test case T23171. This could trigger the panic in the call to
ltPatersonSize in GHC.Tc.Solver.Canonical.mk_strict_superclasses, which
is involved in avoiding loopy superclass constraints.

This patch simply changes ltPatersonSize to return "I don't know, because
there's a type family involved" in these cases.

Fixes #23171

- - - - -
d442ac05 by Sylvain Henry at 2023-04-19T20:04:35-04:00
JS: fix thread-related primops

- - - - -
7a96f90b by Bryan Richter at 2023-04-19T20:05:11-04:00
CI: Disable abi-test-nightly

See #23269

- - - - -
ab6c1d29 by Sylvain Henry at 2023-04-19T20:05:50-04:00
Testsuite: don't use obsolescent egrep (#22351)

Recent egrep displays the following message, breaking golden tests:

  egrep: warning: egrep is obsolescent; using grep -E

Switch to using "grep -E" instead

- - - - -
f15b0ce5 by Matthew Pickering at 2023-04-20T11:01:06-04:00
hadrian: Pass haddock file arguments in a response file

In !10119 CI was failing on windows because the command line was too
long. We can mitigate this by passing the file arguments to haddock in a
response file.

We can't easily pass all the arguments in a response file because the
`+RTS` arguments can't be placed in the response file.

Fixes #23273

- - - - -
7012ec2f by tocic at 2023-04-20T11:01:42-04:00
Fix doc typo in GHC.Read.readList

- - - - -
e51af4b3 by Matthew Pickering at 2023-04-20T16:19:37+01:00
hadrian: Flavour: Change args -> extraArgs

Previously in a flavour definition you could override all the flags
which were passed to GHC. This causes issues when needed to compute a
package hash because we need to know what these extra arguments are
going to be before computing the hash. The solution is to modify flavour
so that the arguments you pass here are just extra ones rather than all
the arguments that you need to compile something.

This makes things work more like how cabal.project files work when you
give extra arguments to a package and also means that flavour
transformers correctly affect the hash.

- - - - -
61df2dd7 by romes at 2023-04-20T16:19:37+01:00
Hardwire a better unit-id for ghc

Previously, the unit-id of ghc-the-library was fixed as `ghc`.
This was done primarily because the compiler must know the unit-id of
some packages (including ghc) a-priori to define wired-in names.

However, as seen in #20742, a reinstallable `ghc` whose unit-id is fixed
to `ghc` might result in subtle bugs when different ghc's interact.

A good example of this is having GHC_A load a plugin compiled by GHC_B,
where GHC_A and GHC_B are linked to ghc-libraries that are ABI
incompatible. Without a distinction between the unit-id of the ghc library
GHC_A is linked against and the ghc library the plugin it is loading was
compiled against, we can't check compatibility.

This patch gives a slightly better unit-id to ghc (ghc-version) by
(1) Not setting -this-unit-id to ghc, but rather to the new unit-id (modulo stage0)
(2) Adding a definition to `GHC.Settings.Config` whose value is the new unit-id.
    (2.1) `GHC.Settings.Config` is generated by Hadrian
    (2.2) and also by cabal through `compiler/Setup.hs`
This unit-id definition is imported by `GHC.Unit.Types` and used to
set the wired-in unit-id of "ghc", which was previously fixed to "ghc"

The commits following this one will improve the unit-id with a
cabal-style package hash and check compatibility when loading plugins.

Note that we also ensure that ghc's unit key matches unit id both when
hadrian or cabal builds ghc, and in this way we no longer need to add
`ghc` to the WiringMap.

- - - - -
687c2d2b by romes at 2023-04-20T16:19:37+01:00
Validate compatibility of ghcs when loading plugins

- - - - -
b9f6f6d5 by romes at 2023-04-20T16:19:37+01:00
Add hashes to unit-ids created by hadrian

This commit adds support for computing an inputs hash for packages
compiled by hadrian. The result is that ABI incompatible packages should
be given different hashes and therefore be distinct in a cabal store.

Hashing is enabled by the `--flag`, and is off by default as the hash
contains a hash of the source files. We enable it when we produce
release builds so that the artifacts we distribute have the right unit
ids.

- - - - -
2ef4c3a3 by Matthew Pickering at 2023-04-20T16:19:37+01:00
Use hash-unit-ids in release jobs

- - - - -
8488080c by GHC GitLab CI at 2023-04-20T16:19:37+01:00
Fix upload_ghc_libs glob

- - - - -

30 changed files:

- .gitlab-ci.yml
- .gitlab/gen_ci.hs
- .gitlab/jobs.yaml
- .gitlab/rel_eng/upload_ghc_libs.py
- compiler/GHC/Builtin/PrimOps.hs
- compiler/GHC/CmmToAsm/Wasm/FromCmm.hs
- compiler/GHC/CmmToAsm/Wasm/Types.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/Core/InstEnv.hs
- compiler/GHC/Core/Make.hs
- compiler/GHC/Core/Opt/ConstantFold.hs
- compiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Opt/Specialise.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/Subst.hs
- compiler/GHC/Core/TyCo/FVs.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Type.hs-boot
- compiler/GHC/Core/Utils.hs
- compiler/GHC/Data/Bag.hs
- compiler/GHC/Data/Maybe.hs
- compiler/GHC/Driver/Config/Diagnostic.hs
- compiler/GHC/Driver/Config/Tidy.hs
- compiler/GHC/Driver/Errors.hs
- compiler/GHC/Driver/Errors/Ppr.hs
- compiler/GHC/Driver/Errors/Types.hs
- compiler/GHC/Driver/Make.hs

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b46a92e80d0b04dee969a27361dc2435105224b1...8488080c632408d2397f9f129078f579e61e8652

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b46a92e80d0b04dee969a27361dc2435105224b1...8488080c632408d2397f9f129078f579e61e8652
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/20230420/b2d125a5/attachment-0001.html>