[Git][ghc/ghc][wip/wither-eq1-and-friends] 12 commits: testsuite: 21651 add test for closeFdWith + setNumCapabilities

John Ericson (@Ericson2314) gitlab at gitlab.haskell.org
Thu Aug 11 12:49:51 UTC 2022 


John Ericson pushed to branch wip/wither-eq1-and-friends at Glasgow Haskell Compiler / GHC


Commits:
76b52cf0 by Douglas Wilson at 2022-08-10T06:01:53-04:00
testsuite: 21651 add test for closeFdWith + setNumCapabilities

This bug does not affect windows, which does not use the
base module GHC.Event.Thread.

- - - - -
7589ee72 by Douglas Wilson at 2022-08-10T06:01:53-04:00
base: Fix races in IOManager (setNumCapabilities,closeFdWith)

Fix for #21651

Fixes three bugs:

- writes to eventManager should be atomic. It is accessed concurrently by ioManagerCapabilitiesChanged and closeFdWith.
- The race in closeFdWith described in the ticket.
- A race in getSystemEventManager where it accesses the 'IOArray' in
  'eventManager' before 'ioManagerCapabilitiesChanged' has written to
  'eventManager', causing an Array Index exception. The fix here is to
  'yield' and retry.

- - - - -
dc76439d by Trevis Elser at 2022-08-10T06:02:28-04:00
Updates language extension documentation

Adding a 'Status' field with a few values:
- Deprecated
- Experimental
- InternalUseOnly
- Noting if included in 'GHC2021', 'Haskell2010' or 'Haskell98'

Those values are pulled from the existing descriptions or elsewhere in
the documentation.

While at it, include the :implied by: where appropriate, to provide
more detail.

Fixes #21475

- - - - -
823fe5b5 by Jens Petersen at 2022-08-10T06:03:07-04:00
hadrian RunRest: add type signature for stageNumber

avoids warning seen on 9.4.1:

src/Settings/Builders/RunTest.hs:264:53: warning: [-Wtype-defaults]
    • Defaulting the following constraints to type ‘Integer’
        (Show a0)
          arising from a use of ‘show’
          at src/Settings/Builders/RunTest.hs:264:53-84
        (Num a0)
          arising from a use of ‘stageNumber’
          at src/Settings/Builders/RunTest.hs:264:59-83
    • In the second argument of ‘(++)’, namely
        ‘show (stageNumber (C.stage ctx))’
      In the second argument of ‘($)’, namely
        ‘"config.stage=" ++ show (stageNumber (C.stage ctx))’
      In the expression:
        arg $ "config.stage=" ++ show (stageNumber (C.stage ctx))
    |
264 |             , arg "-e", arg $ "config.stage="    ++ show (stageNumber (C.stage ctx))
    |                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

compilation tested locally

- - - - -
f95bbdca by Sylvain Henry at 2022-08-10T09:44:46-04:00
Add support for external static plugins (#20964)

This patch adds a new command-line flag:

  -fplugin-library=<file-path>;<unit-id>;<module>;<args>

used like this:

  -fplugin-library=path/to/plugin.so;package-123;Plugin.Module;["Argument","List"]

It allows a plugin to be loaded directly from a shared library. With
this approach, GHC doesn't compile anything for the plugin and doesn't
load any .hi file for the plugin and its dependencies. As such GHC
doesn't need to support two environments (one for plugins, one for
target code), which was the more ambitious approach tracked in #14335.

Fix #20964

Co-authored-by: Josh Meredith <joshmeredith2008 at gmail.com>

- - - - -
5bc489ca by Ben Gamari at 2022-08-10T09:45:22-04:00
gitlab-ci: Fix ARMv7 build

It appears that the CI refactoring carried out in
5ff690b8474c74e9c968ef31e568c1ad0fe719a1 failed to carry over some
critical configuration: setting the build/host/target platforms and
forcing use of a non-broken linker.

- - - - -
596db9a5 by Ben Gamari at 2022-08-10T09:45:22-04:00
gitlab-ci: Run ARMv7 jobs when ~ARM label is used

- - - - -
7cabea7c by Ben Gamari at 2022-08-10T15:37:58-04:00
hadrian: Don't attempt to install documentation if doc/ doesn't exist

Previously we would attempt to install documentation even if the `doc`
directory doesn't exist (e.g. due to `--docs=none`). This would result
in the surprising side-effect of the entire contents of the bindist
being installed in the destination documentation directory. Fix this.

Fixes #21976.

- - - - -
67575f20 by normalcoder at 2022-08-10T15:38:34-04:00
ncg/aarch64: Don't use x18 register on AArch64/Darwin

Apple's ABI documentation [1] says: "The platforms reserve register x18.
Don’t use this register." While this wasn't problematic in previous
Darwin releases, macOS 13 appears to start zeroing this register
periodically. See #21964.

[1] https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms

- - - - -
45eb4cbe by Andreas Klebinger at 2022-08-10T22:41:12-04:00
Note [Trimming auto-rules]: State that this improves compiler perf.

- - - - -
5c24b1b3 by Bodigrim at 2022-08-10T22:41:50-04:00
Document that threadDelay / timeout are susceptible to overflows on 32-bit machines

- - - - -
5749029e by John Ericson at 2022-08-11T08:49:21-04:00
Relax instances for Functor combinators; put superclass on Class1 to make non-breaking

The first change makes the `Eq`, `Ord`, `Show`, and `Read` instances for
`Sum`, `Product`, and `Compose` match those for `:+:`, `:*:`, and `:.:`.
These have the proper flexible contexts that are exactly what the
instance needs:

For example, instead of
```haskell
instance (Eq1 f, Eq1 g, Eq a) => Eq (Compose f g a) where
  (==) = eq1
```
we do
```haskell
deriving instance Eq (f (g a)) => Eq (Compose f g a)
```

But, that change alone is rather breaking, because until now `Eq (f a)`
and `Eq1 f` (and respectively the other classes and their `*1`
equivalents too) are *incomparable* constraints. This has always been an
annoyance of working with the `*1` classes, and now it would rear it's
head one last time as an pesky migration.

Instead, we give the `*1` classes superclasses, like so:
```haskell
(forall a. Eq a => Eq (f a)) => Eq1 f
```
along with some laws that canonicity is preserved, like:
```haskell
liftEq (==) = (==)
```

and likewise for `*2` classes:
```haskell
(forall a. Eq a => Eq1 (f a)) => Eq2 f
```
and laws:
```haskell
liftEq2 (==) = liftEq1
```

The `*1` classes also have default methods using the `*2` classes where
possible.

What this means, as explained in the docs, is that `*1` classes really
are generations of the regular classes, indicating that the methods can
be split into a canonical lifting combined with a canonical inner, with
the super class "witnessing" the laws[1] in a fashion.

Circling back to the pragmatics of migrating, note that the superclass
means evidence for the old `Sum`, `Product`, and `Compose` instances is
(more than) sufficient, so breakage is less likely --- as long no
instances are "missing", existing polymorphic code will continue to
work.

Breakage can occur when a datatype implements the `*1` class but not the
corresponding regular class, but this is almost certainly an oversight.
For example, containers made that mistake for `Tree` and `Ord`, which I
fixed in https://github.com/haskell/containers/pull/761, but fixing the
issue by adding `Ord1` was extremely *un*controversial.

`Generically1` was also missing `Eq`, `Ord`, `Read,` and `Show`
instances. It is unlikely this would have been caught without
implementing this change.

-----

[1]: In fact, someday, when the laws are part of the language and not
only documentation, we might be able to drop the superclass field of the
dictionary by using the laws to recover the superclass in an
instance-agnostic manner, e.g. with a *non*-overloaded function with
type:

```haskell
DictEq1 f -> DictEq a -> DictEq (f a)
```

But I don't wish to get into optomizations now, just demonstrate the
close relationship between the law and the superclass.

Bump haddock submodule because of test output changing.

- - - - -


30 changed files:

- .gitlab/gen_ci.hs
- .gitlab/jobs.yaml
- compiler/CodeGen.Platform.h
- compiler/GHC/Driver/Plugins.hs
- + compiler/GHC/Driver/Plugins/External.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Iface/Tidy.hs
- compiler/GHC/Runtime/Loader.hs
- compiler/ghc.cabal.in
- docs/users_guide/bugs.rst
- docs/users_guide/extending_ghc.rst
- docs/users_guide/exts/binary_literals.rst
- docs/users_guide/exts/constrained_class_methods.rst
- docs/users_guide/exts/constraint_kind.rst
- docs/users_guide/exts/datatype_contexts.rst
- docs/users_guide/exts/deriving_extra.rst
- docs/users_guide/exts/duplicate_record_fields.rst
- docs/users_guide/exts/empty_case.rst
- docs/users_guide/exts/empty_data_deriving.rst
- docs/users_guide/exts/existential_quantification.rst
- docs/users_guide/exts/explicit_forall.rst
- docs/users_guide/exts/explicit_namespaces.rst
- docs/users_guide/exts/ffi.rst
- docs/users_guide/exts/field_selectors.rst
- docs/users_guide/exts/flexible_contexts.rst
- docs/users_guide/exts/functional_dependencies.rst
- docs/users_guide/exts/gadt_syntax.rst
- docs/users_guide/exts/generics.rst
- docs/users_guide/exts/hex_float_literals.rst
- docs/users_guide/exts/import_qualified_post.rst


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d4b6fddba81edb62f4496d55c89781355a9f35a4...5749029ece7a328650e3cffb48da4e1c23aada18

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d4b6fddba81edb62f4496d55c89781355a9f35a4...5749029ece7a328650e3cffb48da4e1c23aada18
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/20220811/f16e1a50/attachment-0001.html>

More information about the ghc-commits mailing list