[Git][ghc/ghc][wip/T22696] 17 commits: base: Document GHC versions associated with past base versions in the changelog
Ryan Scott (@RyanGlScott)
gitlab at gitlab.haskell.org
Wed Mar 29 12:34:43 UTC 2023
Ryan Scott pushed to branch wip/T22696 at Glasgow Haskell Compiler / GHC
Commits:
6a73655f by Li-yao Xia at 2023-03-25T00:02:44-04:00
base: Document GHC versions associated with past base versions in the changelog
- - - - -
43bd7694 by Teo Camarasu at 2023-03-25T00:03:24-04:00
Add regression test for #17574
This test currently fails in the nonmoving way
- - - - -
f2d56bf7 by Teo Camarasu at 2023-03-25T00:03:24-04:00
fix: account for large and compact object stats with nonmoving gc
Make sure that we keep track of the size of large and compact objects that have been moved onto the nonmoving heap.
We keep track of their size and add it to the amount of live bytes in nonmoving segments to get the total size of the live nonmoving heap.
Resolves #17574
- - - - -
7131b705 by David Feuer at 2023-03-25T00:04:04-04:00
Modify ThreadId documentation and comments
For a long time, `GHC.Conc.Sync` has said
```haskell
-- ToDo: data ThreadId = ThreadId (Weak ThreadId#)
-- But since ThreadId# is unlifted, the Weak type must use open
-- type variables.
```
We are now actually capable of using `Weak# ThreadId#`, but the
world has moved on. To support the `Show` and `Ord` instances, we'd
need to store the thread ID number in the `ThreadId`. And it seems
very difficult to continue to support `threadStatus` in that regime,
since it needs to be able to explain how threads died. In addition,
garbage collection of weak references can be quite expensive, and it
would be hard to evaluate the cost over he whole ecosystem. As discussed
in
[this CLC issue](https://github.com/haskell/core-libraries-committee/issues/125),
it doesn't seem very likely that we'll actually switch to weak
references here.
- - - - -
c421bbbb by Ben Gamari at 2023-03-25T00:04:41-04:00
rts: Fix barriers of IND and IND_STATIC
Previously IND and IND_STATIC lacked the acquire barriers enjoyed by
BLACKHOLE. As noted in the (now updated) Note [Heap memory barriers],
this barrier is critical to ensure that the indirectee is visible to the
entering core.
Fixes #22872.
- - - - -
62fa7faa by Bodigrim at 2023-03-25T00:05:22-04:00
Improve documentation of atomicModifyMutVar2#
- - - - -
b2d14d0b by Cheng Shao at 2023-03-25T03:46:43-04:00
rts: use performBlockingMajorGC in hs_perform_gc and fix ffi023
This patch does a few things:
- Add the missing RtsSymbols.c entry of performBlockingMajorGC
- Make hs_perform_gc call performBlockingMajorGC, which restores
previous behavior
- Use hs_perform_gc in ffi023
- Remove rts_clearMemory() call in ffi023, it now works again in some
test ways previously marked as broken. Fixes #23089
- - - - -
d9ae24ad by Cheng Shao at 2023-03-25T03:46:44-04:00
testsuite: add the rts_clearMemory test case
This patch adds a standalone test case for rts_clearMemory that mimics
how it's typically used by wasm backend users and ensures this RTS API
isn't broken by future RTS refactorings. Fixes #23901.
- - - - -
80729d96 by Bodigrim at 2023-03-25T03:47:22-04:00
Improve documentation for resizing of byte arrays
- - - - -
c6ec4cd1 by Ben Gamari at 2023-03-25T20:23:47-04:00
rts: Don't rely on EXTERN_INLINE for slop-zeroing logic
Previously we relied on calling EXTERN_INLINE functions defined in
ClosureMacros.h from Cmm to zero slop. However, as far as I can tell,
this is no longer safe to do in C99 as EXTERN_INLINE definitions may be emitted
in each compilation unit.
Fix this by explicitly declaring a new set of non-inline functions in
ZeroSlop.c which can be called from Cmm and marking the ClosureMacros.h
definitions as INLINE_HEADER.
In the future we should try to eliminate EXTERN_INLINE.
- - - - -
c32abd4b by Ben Gamari at 2023-03-25T20:23:48-04:00
rts: Fix capability-count check in zeroSlop
Previously `zeroSlop` examined `RtsFlags` to determine whether the
program was single-threaded. This is wrong; a program may be started
with `+RTS -N1` yet the process may later increase the capability count
with `setNumCapabilities`. This lead to quite subtle and rare crashes.
Fixes #23088.
- - - - -
656d4cb3 by Ryan Scott at 2023-03-25T20:24:23-04:00
Add Eq/Ord instances for SSymbol, SChar, and SNat
This implements [CLC proposal #148](https://github.com/haskell/core-libraries-committee/issues/148).
- - - - -
4f93de88 by David Feuer at 2023-03-26T15:33:02-04:00
Update and expand atomic modification Haddocks
* The documentation for `atomicModifyIORef` and `atomicModifyIORef'`
were incomplete, and the documentation for `atomicModifyIORef` was
out of date. Update and expand.
* Remove a useless lazy pattern match in the definition of
`atomicModifyIORef`. The pair it claims to match lazily
was already forced by `atomicModifyIORef2`.
- - - - -
e1fb56b2 by David Feuer at 2023-03-26T15:33:41-04:00
Document the constructor name for lists
Derived `Data` instances use raw infix constructor names when applicable.
The `Data.Data [a]` instance, if derived, would have a constructor name
of `":"`. However, it actually uses constructor name `"(:)"`. Document this
peculiarity.
See https://github.com/haskell/core-libraries-committee/issues/147
- - - - -
c1f755c4 by Simon Peyton Jones at 2023-03-27T22:09:41+01:00
Make exprIsConApp_maybe a bit cleverer
Addresses #23159.
See Note Note [Exploit occ-info in exprIsConApp_maybe]
in GHC.Core.SimpleOpt.
Compile times go down very slightly, but always go down,
never up. Good!
Metrics: compile_time/bytes allocated
------------------------------------------------
CoOpt_Singletons(normal) -1.8%
T15703(normal) -1.2% GOOD
geo. mean -0.1%
minimum -1.8%
maximum +0.0%
Metric Decrease:
CoOpt_Singletons
T15703
- - - - -
76bb4c58 by Ryan Scott at 2023-03-28T08:12:08-04:00
Add COMPLETE pragmas to TypeRep, SSymbol, SChar, and SNat
This implements
[CLC proposal #149](https://github.com/haskell/core-libraries-committee/issues/149).
- - - - -
6ba0aed8 by Ryan Scott at 2023-03-29T08:34:32-04:00
validDerivPred: Reject non-well-formed 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) 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 it is, there is a clear migration path using `StandaloneDeriving`.
Fixes #22696.
- - - - -
30 changed files:
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Tc/Deriv/Infer.hs
- compiler/GHC/Tc/Validity.hs
- docs/users_guide/9.8.1-notes.rst
- libraries/base/Data/Data.hs
- libraries/base/Data/IORef.hs
- libraries/base/Data/Typeable/Internal.hs
- libraries/base/GHC/Conc/Sync.hs
- libraries/base/GHC/IORef.hs
- libraries/base/GHC/TypeLits.hs
- libraries/base/GHC/TypeNats.hs
- libraries/base/changelog.md
- + libraries/base/tests/CLC149.hs
- libraries/base/tests/all.T
- rts/HsFFI.c
- rts/RtsSymbols.c
- rts/StgMiscClosures.cmm
- + rts/ZeroSlop.c
- rts/include/Cmm.h
- rts/include/rts/storage/ClosureMacros.h
- rts/include/stg/SMP.h
- rts/rts.cabal.in
- rts/sm/NonMoving.c
- rts/sm/NonMoving.h
- rts/sm/NonMovingMark.c
- rts/sm/NonMovingMark.h
- rts/sm/Storage.c
- testsuite/.gitignore
- + testsuite/tests/deriving/should_compile/T22696a.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5cc1ddb273c47c07b1835b82c674355e51e2ae23...6ba0aed804d28a19eb10359b8c049b9deadfeb56
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5cc1ddb273c47c07b1835b82c674355e51e2ae23...6ba0aed804d28a19eb10359b8c049b9deadfeb56
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/20230329/9286a5e8/attachment-0001.html>
More information about the ghc-commits
mailing list