[Git][ghc/ghc][wip/T22331] 25 commits: Drop a kludge for binutils<2.17, which is now over 10 years old.

Thu Nov 3 10:40:15 UTC 2022

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

Commits:
d45d8cb3 by M Farkas-Dyck at 2022-11-01T12:47:21-04:00
Drop a kludge for binutils<2.17, which is now over 10 years old.

- - - - -
8ee8b418 by Nicolas Trangez at 2022-11-01T12:47:58-04:00
rts: `name` argument of `createOSThread` can be `const`

Since we don't intend to ever change the incoming string, declare this
to be true.

Also, in the POSIX implementation, the argument is no longer `STG_UNUSED`
(since ee0deb8054da2a597fc5624469b4c44fd769ada2) in any code path.

See: https://gitlab.haskell.org/ghc/ghc/-/commit/ee0deb8054da2a597fc5624469b4c44fd769ada2#note_460080

- - - - -
13b5f102 by Nicolas Trangez at 2022-11-01T12:47:58-04:00
rts: fix lifetime of `start_thread`s `name` value

Since, unlike the code in ee0deb8054da2^, usage of the `name` value
passed to `createOSThread` now outlives said function's lifetime, and
could hence be released by the caller by the time the new thread runs
`start_thread`, it needs to be copied.

See: https://gitlab.haskell.org/ghc/ghc/-/commit/ee0deb8054da2a597fc5624469b4c44fd769ada2#note_460080
See: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9066

- - - - -
edd175c9 by Nicolas Trangez at 2022-11-01T12:47:58-04:00
rts: fix OS thread naming in ticker

Since ee0deb805, the use of `pthread_setname_np` on Darwin was fixed
when invoking `createOSThread`. However, the 'ticker' has some
thread-creation code which doesn't rely on `createOSThread`, yet also
uses `pthread_setname_np`.

This patch enforces all thread creation to go through a single
function, which uses the (correct) thread-naming code introduced in
ee0deb805.

See: https://gitlab.haskell.org/ghc/ghc/-/commit/ee0deb8054da2a597fc5624469b4c44fd769ada2
See: https://gitlab.haskell.org/ghc/ghc/-/issues/22206
See: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9066

- - - - -
b7a00113 by Krzysztof Gogolewski at 2022-11-01T12:48:35-04:00
Typo: rename -fwrite-if-simplfied-core to -fwrite-if-simplified-core

- - - - -
30e625e6 by Vladislav Zavialov at 2022-11-01T12:49:10-04:00
ThToHs: fix overzealous parenthesization

Before this patch, when converting from TH.Exp to LHsExpr GhcPs,
the compiler inserted more parentheses than required:

	((f a) (b + c)) d

This was happening because the LHS of the function application was
parenthesized as if it was the RHS.

Now we use funPrec and appPrec appropriately and produce sensibly
parenthesized expressions:

	f a (b + c) d

I also took the opportunity to remove the special case for LamE,
which was not special at all and simply duplicated code.

- - - - -
0560821f by Simon Peyton Jones at 2022-11-01T12:49:47-04:00
Add accurate skolem info when quantifying

Ticket #22379 revealed that skolemiseQuantifiedTyVar was
dropping the passed-in skol_info on the floor when it encountered
a SkolemTv.  Bad!  Several TyCons thereby share a single SkolemInfo
on their binders, which lead to bogus error reports.

- - - - -
38d19668 by Fendor at 2022-11-01T12:50:25-04:00
Expose UnitEnvGraphKey for user-code

- - - - -
77e24902 by Simon Peyton Jones at 2022-11-01T12:51:00-04:00
Shrink test case for #22357

Ryan Scott offered a cut-down repro case
(60 lines instead of more than 700 lines)

- - - - -
4521f649 by Simon Peyton Jones at 2022-11-01T12:51:00-04:00
Add two tests for #17366

- - - - -
6b400d26 by Nicolas Trangez at 2022-11-02T12:06:48-04:00
rts: introduce (and use) `STG_NORETURN`

Instead of sprinkling the codebase with
`GNU(C3)_ATTRIBUTE(__noreturn__)`, add a `STG_NORETURN` macro (for,
basically, the same thing) similar to `STG_UNUSED` and others, and
update the code to use this macro where applicable.

- - - - -
f9638654 by Nicolas Trangez at 2022-11-02T12:06:48-04:00
rts: consistently use `STG_UNUSED`

- - - - -
81a58433 by Nicolas Trangez at 2022-11-02T12:06:48-04:00
rts: introduce (and use) `STG_USED`

Similar to `STG_UNUSED`, have a specific macro for
`__attribute__(used)`.

- - - - -
41e1f748 by Nicolas Trangez at 2022-11-02T12:06:48-04:00
rts: introduce (and use) `STG_MALLOC`

Instead of using `GNUC3_ATTRIBUTE(__malloc__)`, provide a `STG_MALLOC`
macro definition and use it instead.

- - - - -
3a9a8bde by Nicolas Trangez at 2022-11-02T12:06:48-04:00
rts: use `STG_UNUSED`

- - - - -
9ab999de by Nicolas Trangez at 2022-11-02T12:06:48-04:00
rts: specify deallocator of allocating functions

This patch adds a new `STG_MALLOC1` macro (and its counterpart
`STG_MALLOC2` for completeness) which allows to specify the deallocation
function to be used with allocations of allocating functions, and
applies it to `stg*allocBytes`.

It also fixes a case where `free` was used to free up an
`stgMallocBytes` allocation, found by the above change.

See: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-malloc-function-attribute
See: https://gitlab.haskell.org/ghc/ghc/-/issues/22381

- - - - -
81c0c7c9 by Nicolas Trangez at 2022-11-02T12:06:48-04:00
rts: use `alloc_size` attribute

This patch adds the `STG_ALLOC_SIZE1` and `STG_ALLOC_SIZE2` macros which
allow to set the `alloc_size` attribute on functions, when available.

See: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-alloc_005fsize-function-attribute
See: https://gitlab.haskell.org/ghc/ghc/-/issues/22381

- - - - -
99a1d896 by Nicolas Trangez at 2022-11-02T12:06:48-04:00
rts: add and use `STG_RETURNS_NONNULL`

See: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-returns_005fnonnull-function-attribute
See: https://gitlab.haskell.org/ghc/ghc/-/issues/22381

- - - - -
c235b399 by Nicolas Trangez at 2022-11-02T12:06:48-04:00
rts: tag `stgStrndup` as `STG_MALLOC`

See: https://gitlab.haskell.org/ghc/ghc/-/issues/22381

- - - - -
ed81b448 by Oleg Grenrus at 2022-11-02T12:07:27-04:00
Move Symbol implementation note out of public haddock

- - - - -
284fd39c by Ben Gamari at 2022-11-03T01:58:54-04:00
gen-dll: Drop it

Currently it is only used by the make build system, which is soon to be
retired, and it has not built since 41cf758b. We may need to reintroduce
it when dynamic-linking support is introduced on Windows, but we will
cross that bridge once we get there.

Fixes #21753.

- - - - -
24f4f54f by Matthew Pickering at 2022-11-03T01:59:30-04:00
Port foundation numeric tests to GHC testsuite

This commit ports the numeric tests which found a regression in GHC-9.4.

https://github.com/haskell-foundation/foundation/issues/571

Included in the commit is a simple random number generator and
simplified QuickCheck implementation. In future these could be factored
out of this standalone file and reused as a general purpose library
which could be used for other QuickCheck style tests in the testsuite.

See #22282

- - - - -
d51bf7bd by M Farkas-Dyck at 2022-11-03T02:00:13-04:00
git: ignore HIE files.

Cleans up git status if one sets -fwrite-ide-info in hadrian/ghci.

- - - - -
a9fc15b1 by Matthew Pickering at 2022-11-03T02:00:49-04:00
Clarify status of bindings in WholeCoreBindings

Gergo points out that these bindings are tidied, rather than prepd as
the variable claims. Therefore we update the name of the variable to
reflect reality and add a comment to the data type to try to erase any
future confusion.

Fixes #22307

- - - - -
ef590e55 by Simon Peyton Jones at 2022-11-03T10:42:00+00:00
Fix decomposition of TyConApps

Ticket #22331 showed that we were being too eager to decompose
a Wanted TyConApp, leading to incompleteness in the solver.

To understand all this I ended up doing a substantial rewrite
of the old Note [Decomposing equalities], now reborn as
Note [Decomposing TyConApp equalities]. Plus rewrites of other
related Notes.

The actual fix is very minor and actually simplifies the code: in
`can_decompose` in `GHC.Tc.Solver.Canonical.canTyConApp`, we now call
`noMatchableIrreds`.  A closely related refactor: we stop trying to
use the same "no matchable givens" function here as in
`matchClassInst`.  Instead split into two much simpler functions.

- - - - -

30 changed files:

- .gitignore
- CODEOWNERS
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/CmmToAsm/X86/Ppr.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Tc/Solver/Canonical.hs
- compiler/GHC/Tc/Solver/InertSet.hs
- compiler/GHC/Tc/Solver/Interact.hs
- compiler/GHC/Tc/TyCl.hs
- compiler/GHC/Tc/Utils/TcMType.hs
- compiler/GHC/Tc/Utils/TcType.hs
- compiler/GHC/ThToHs.hs
- compiler/GHC/Unit/Env.hs
- compiler/GHC/Unit/Module/WholeCoreBindings.hs
- configure.ac
- docs/users_guide/phases.rst
- libraries/ghc-prim/GHC/Types.hs
- rts/CloneStack.c
- rts/Heap.c
- rts/Hpc.c
- rts/Linker.c
- rts/RtsAPI.c
- rts/RtsFlags.c
- rts/RtsMessages.c
- rts/RtsStartup.c
- rts/RtsUtils.h

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/3438c61d53b7b6b519986148fb5d0f533d00c8c6...ef590e55d72fdd12e9f0aba3cd1f0f09e2bc719e

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/3438c61d53b7b6b519986148fb5d0f533d00c8c6...ef590e55d72fdd12e9f0aba3cd1f0f09e2bc719e
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/20221103/53e2d334/attachment-0001.html>