[Git][ghc/ghc][wip/tsan/fix-races] 23 commits: LinearTypes => MonoLocalBinds
Ben Gamari (@bgamari)
gitlab at gitlab.haskell.org
Tue Dec 19 22:00:48 UTC 2023
Ben Gamari pushed to branch wip/tsan/fix-races at Glasgow Haskell Compiler / GHC
Commits:
188b280d by Arnaud Spiwack at 2023-12-11T15:33:31+01:00
LinearTypes => MonoLocalBinds
- - - - -
8e0446df by Arnaud Spiwack at 2023-12-11T15:44:28+01:00
Linear let and where bindings
For expediency, the initial implementation of linear types in GHC
made it so that let and where binders would always be considered
unrestricted. This was rather unpleasant, and probably a big obstacle
to adoption. At any rate, this was not how the proposal was designed.
This patch fixes this infelicity. It was surprisingly difficult to
build, which explains, in part, why it took so long to materialise.
As of this patch, let or where bindings marked with %1 will be
linear (respectively %p for an arbitrary multiplicity p). Unmarked let
will infer their multiplicity.
Here is a prototypical example of program that used to be rejected and
is accepted with this patch:
```haskell
f :: A %1 -> B
g :: B %1 -> C
h :: A %1 -> C
h x = g y
where
y = f x
```
Exceptions:
- Recursive let are unrestricted, as there isn't a clear semantics of
what a linear recursive binding would be.
- Destructive lets with lazy bindings are unrestricted, as their
desugaring isn't linear (see also #23461).
- (Strict) destructive lets with inferred polymorphic type are
unrestricted. Because the desugaring isn't linear (See #18461
down-thread).
Closes #18461 and #18739
Co-authored-by: @jackohughes
- - - - -
effa7e2d by Matthew Craven at 2023-12-12T04:37:20-05:00
Introduce `dataToTagSmall#` primop (closes #21710)
...and use it to generate slightly better code when dataToTag#
is used at a "small data type" where there is no need to mess
with "is_too_big_tag" or potentially look at an info table.
Metric Decrease:
T18304
- - - - -
35c7aef6 by Matthew Craven at 2023-12-12T04:37:20-05:00
Fix formatting of Note [alg-alt heap check]
- - - - -
7397c784 by Oleg Grenrus at 2023-12-12T04:37:56-05:00
Allow untyped brackets in typed splices and vice versa.
Resolves #24190
Apparently the check was essentially always (as far as I can trace back: d0d47ba76f8f0501cf3c4966bc83966ab38cac27),
and while it does catch some mismatches, the type-checker will catch
them too. OTOH, it prevents writing completely reasonable programs.
- - - - -
a3ee3b99 by Moritz Angermann at 2023-12-12T19:50:58-05:00
Drop hard Xcode dependency
XCODE_VERSION calls out to `xcodebuild`, which is only available
when having `Xcode` installed. The CommandLineTools are not
sufficient. To install Xcode, you must have an apple id to download
the Xcode.xip from apple.
We do not use xcodebuild anywhere in our build explicilty. At best
it appears to be a proxy for checking the linker or the compiler.
These should rather be done with
```
xcrun ld -version
```
or similar, and not by proxy through Xcode. The CLR should be
sufficient for building software on macOS.
- - - - -
1c9496e0 by Vladislav Zavialov at 2023-12-12T19:51:34-05:00
docs: update information on RequiredTypeArguments
Update the User's Guide and Release Notes to account for the recent
progress in the implementation of RequiredTypeArguments.
- - - - -
d0b17576 by Ben Gamari at 2023-12-13T06:33:37-05:00
rts/eventlog: Fix off-by-one in assertion
Previously we failed to account for the NULL terminator `postString`
asserted that there is enough room in the buffer for the string.
- - - - -
a10f9b9b by Ben Gamari at 2023-12-13T06:33:37-05:00
rts/eventlog: Honor result of ensureRoomForVariableEvent is
Previously we would keep plugging along, even if isn't enough room for
the event.
- - - - -
0e0f41c0 by Ben Gamari at 2023-12-13T06:33:37-05:00
rts/eventlog: Avoid truncating event sizes
Previously ensureRoomForVariableEvent would truncate the desired size to
16-bits, resulting in #24197.
Fixes #24197.
- - - - -
64e724c8 by Artin Ghasivand at 2023-12-13T06:34:20-05:00
Remove the "Derived Constraint" argument of TcPluginSolver, docs
- - - - -
fe6d97dd by Vladislav Zavialov at 2023-12-13T06:34:56-05:00
EPA: Move tokens into GhcPs extension fields (#23447)
Summary of changes
* Remove Language.Haskell.Syntax.Concrete
* Move all tokens into GhcPs extension fields (LHsToken -> EpToken)
* Create new TTG extension fields as needed
* Drop the MultAnn wrapper
Updates the haddock submodule.
Co-authored-by: Alan Zimmerman <alan.zimm at gmail.com>
- - - - -
8106e695 by Zubin Duggal at 2023-12-13T06:35:34-05:00
testsuite: use copy_files in T23405
This prevents the tree from being dirtied when the file is modified.
- - - - -
ed0e4099 by Bryan Richter at 2023-12-14T04:30:53-05:00
Document ghc package's PVP-noncompliance
This changes nothing, it just makes the status quo explicit.
- - - - -
8bef8d9f by Luite Stegeman at 2023-12-14T04:31:33-05:00
JS: Mark spurious CI failures js_fragile(24259)
This marks the spurious test failures on the JS platform as
js_fragile(24259), so we don't hold up merge requests while
fixing the underlying issues.
See #24259
- - - - -
7ea0e864 by Ben Gamari at 2023-12-19T16:51:24-05:00
Fix thunk update ordering
Previously we attempted to ensure soundness of concurrent thunk update
by synchronizing on the access of the thunk's info table pointer field.
This was believed to be sufficient since the indirectee (which may
expose a closure allocated by another core) would not be examined
until the info table pointer update is complete.
However, it turns out that this can result in data races in the presence
of multiple threads racing a update a single thunk. For instance,
consider this interleaving under the old scheme:
Thread A Thread B
--------- ---------
t=0 Enter t
1 Push update frame
2 Begin evaluation
4 Pause thread
5 t.indirectee=tso
6 Release t.info=BLACKHOLE
7 ... (e.g. GC)
8 Resume thread
9 Finish evaluation
10 Relaxed t.indirectee=x
11 Load t.info
12 Acquire fence
13 Inspect t.indirectee
14 Release t.info=BLACKHOLE
Here Thread A enters thunk `t` but is soon paused, resulting in `t`
being lazily blackholed at t=6. Then, at t=10 Thread A finishes
evaluation and updates `t.indirectee` with a relaxed store.
Meanwhile, Thread B enters the blackhole. Under the old scheme this
would introduce an acquire-fence but this would only synchronize with
Thread A at t=6. Consequently, the result of the evaluation, `x`, is not
visible to Thread B, introducing a data race.
We fix this by treating the `indirectee` field as we do all other
mutable fields. This means we must always access this field with
acquire-loads and release-stores.
See #23185.
- - - - -
94d831b5 by Ben Gamari at 2023-12-19T16:55:35-05:00
cmm: Introduce MO_RelaxedRead
In hand-written Cmm it can sometimes be necessary to atomically load
from memory deep within an expression (e.g. see the `CHECK_GC` macro).
This MachOp provides a convenient way to do so without breaking the
expression into multiple statements.
- - - - -
43a26044 by Ben Gamari at 2023-12-19T16:55:35-05:00
codeGen: Use relaxed accesses in ticky bumping
- - - - -
798fb638 by Ben Gamari at 2023-12-19T16:55:35-05:00
base: use atomic write when updating timer manager
- - - - -
b757e1ec by Ben Gamari at 2023-12-19T16:55:35-05:00
Use relaxed atomics to manipulate TSO status fields
- - - - -
d288a8c7 by Ben Gamari at 2023-12-19T16:55:35-05:00
rts: Add necessary barriers when manipulating TSO owner
- - - - -
d5f1f665 by Ben Gamari at 2023-12-19T16:55:35-05:00
rts: Use `switch` to branch on why_blocked
This is a semantics-preserving refactoring.
- - - - -
ba20e31e by Ben Gamari at 2023-12-19T16:55:35-05:00
rts: Fix synchronization on thread blocking state
We now use a release barrier whenever we update a thread's blocking
state. This required widening StgTSO.why_blocked as AArch64 does not
support atomic writes on 16-bit values.
- - - - -
30 changed files:
- compiler/GHC/Builtin/PrimOps.hs
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/Cmm/Expr.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/ThreadSanitizer.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/PPC/CodeGen.hs
- compiler/GHC/CmmToAsm/Wasm/FromCmm.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/CmmToC.hs
- compiler/GHC/CmmToLlvm/CodeGen.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/ConstantFold.hs
- compiler/GHC/Driver/Backpack.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Hs.hs
- compiler/GHC/Hs/Binds.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Extension.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Syn/Type.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Arrows.hs
- compiler/GHC/HsToCore/Binds.hs
- compiler/GHC/HsToCore/Docs.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e308f771917d2b3b6cd44f007cf07cad8c90f620...ba20e31e8733cc23cb1361e1b64279715ac5176a
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e308f771917d2b3b6cd44f007cf07cad8c90f620...ba20e31e8733cc23cb1361e1b64279715ac5176a
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/20231219/225b378b/attachment-0001.html>
More information about the ghc-commits
mailing list