For some implementations of pthreads, the address of pthread_rwlock_t
(or its fields) is used to identify the lock. That means that if the
contents of a pthread_rwlock_t are moved in memory, effectively a new
lock object is created, which is completely independted from the
original. Thus we want to detect when when such objects are moved and
show an error.

Renamed variable and fixed comments referring to renamed FileDescriptor

Fixes rust-lang#3808, does not change any functionality

ci: bump actions/checkout to v4

Required for using Node.js 20.x in CI
* Changelog for actions/checkout@v4 https://github.com/actions/checkout/blob/main/CHANGELOG.md?rgh-link-date=2024-09-04T18%3A38%3A10Z#v400
* GitHub Blog post https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/

Refs: rust-lang#130124 (comment)

…fJung

detect when pthread_rwlock_t is moved

For some implementations of pthreads, the address of pthread_rwlock_t (or its fields) is used to identify the lock. That means that if the contents of a pthread_rwlock_t are moved in memory, effectively a new lock object is created, which is completely independted from the original. Thus we want to detect when when such objects are moved and show an error.

see also rust-lang#3749 for more context

…an be kept local

a bit of refactoring in "sync"

- Use `Box<dyn Any>` to keep the "extra data" local to the module implementing the primitive
- Pass around places, not pointers

Cc `@Mandragorian` -- sorry I couldn't resist and did the `Any` thing ;)

Rustup

Automatic Rustup

Automatic Rustup

add non-portable linux pthread initializers to layout sanity check

Also, turns out we can enable all pthread tests on Solarish.

smoke-test './miri run --dep'

I don't actually know if this works on Windows.^^

./miri run: directly run binary instead of using 'cargo run'

This avoids re-building miri without dev dependencies, so it makes `./miri run` a lot faster if `./miri test` was already executed before.

Automatic Rustup

Closes rust-lang#3749

detect when pthread_cond_t is moved

Closes rust-lang#3749

On FreeBSD, DEFAULT maps to ERRORCK. This clashes with the existing PTHREAD_MUTEX_NORMAL_FLAG:
hack so we replace it by a different hack that works better cross-platform.

Also fix a case of "accidental early UB" in a UB test -- pthread_mutexattr_t must be initialized.

support pthread primitives on FreeBSD

Fixes rust-lang/miri#3571: makes out pthread implementation support FreeBSD.

FreeBSD sets PHTREAD_MUTEX_DEFAULT == PHTREAD_MUTEX_ERRORCK, so the logic for handling "default vs explicitly set mutex kind" had to be adjusted.

The rest is just some general cleanup of the pthread logic, and I realized that we can enable the std::sync tests on Solarish.

add Android pthread support

Also extend what we test on Solarish / FreeBSD, turns out a few more things are working.

Automatic Rustup

…nikic"

This reverts commit 8c7a7e3, reversing
changes made to a00bd75.

Co-authored-by: David Tolnay <[email protected]>

Bump ui test to 0.26

lots of issues fixed and various improvements

🤞 that it works this time around

Automatically add/remove labels when github review (requests) are used

Automatic Rustup

…to WeakFileDescriptionRef

Fix tokio test ICE

Fixes rust-lang#3858

It turned out that the issue mentioned [here](rust-lang/miri#3858 (comment)) is the exact cause of ICE.
So in this PR, I changed the type of ``EpollEventInterest::epfd`` from ``i32`` to ``WeakFileDescriptionRef``.

This line number calculation was both wrong and unnecessary.

…compiler-errors

Fix fluent diagnostics

This line number calculation was both wrong and unnecessary.

… r=dtolnay

Add new_cyclic_in for Rc and Arc

Currently, new_cyclic_in does not exist for Rc and Arc. This is an oversight according to rust-lang/wg-allocators#132.

This PR adds new_cyclic_in for Rc and Arc. The implementation is almost the exact same as new_cyclic with some small differences to make it allocator-specific. new_cyclic's implementation has been replaced with a call to `new_cyclic_in(data_fn, Global)`.

Remaining questions:
* ~~Is requiring Allocator to be Clone OK? According to rust-lang/wg-allocators#88, Allocators should be cheap to clone. I'm just hesitant to add unnecessary constraints, though I don't see an obvious workaround for this function since many called functions in new_cyclic_in expect an owned Allocator. I see Allocator.by_ref() as an option, but that doesn't work on when creating Weak { ptr: init_ptr, alloc: alloc.clone() }, because the type of Weak then becomes Weak<T, &A> which is incompatible.~~ Fixed, thank you `@zakarumych!` This PR no longer requires the allocator to be Clone.
* Currently, new_cyclic_in's documentation is almost entirely copy-pasted from new_cyclic, with minor tweaks to make it more accurate (e.g. Rc<T> -> Rc<T, A>). The example section is removed to mitigate redundancy and instead redirects to cyclic_in. Is this appropriate?
* ~~The comments in new_cyclic_in (and much of the implementation) are also copy-pasted from new_cyclic. Would it be better to make a helper method new_cyclic_in_internal that both functions call, with either Global or the custom allocator? I'm not sure if that's even possible, since the internal method would have to return Arc<T, Global> and I don't know if it's possible to "downcast" that to an Arc<T>. Maybe transmute would work here?~~ Done, thanks `@zakarumych`
* Arc::new_cyclic is #[inline], but Rc::new_cyclic is not. Which is preferred?
* nit: does it matter where in the impl block new_cyclic_in is defined?

…ners, r=ehuss

Update Trusty target maintainers

Remove Stephen Crane from the list of Trusty target maintainers and add Andrei Homescu (`@ahomescu)` and Chris Wailes.

Miri subtree update

r? `@ghost`

Revert rust-lang#129749 to fix segfault in LLVM

This reverts commit 8c7a7e3, reversing changes made to a00bd75.

Reported in rust-lang#129749 (comment). `@nikic's` theory is that the LLVM API changed in a way that makes it impossible to use concurrently from multiple threads (llvm/llvm-project#106427 (comment)). I pinged `@krasimirgg` who was fine with reverting.

r? `@rust-lang/wg-llvm`