Enable `f16` tests on x86 and x86-64
Since the `compiler_builtins` update [1], ABI bugs on x86 should be resolved. Enable tests for f16 on these platforms now.
`f16` math functions (`reliable_f16_math`) are still excluded because there is an LLVM crash for powi [2].
[1]: https://github.com/rust-lang/rust/pull/125016
[2]: https://github.com/llvm/llvm-project/issues/105747
try-job: dist-i586-gnu-i586-i686-musl
try-job: x86_64-apple-1
epoll: handle edge case for epoll_ctl
There is a test case that revealed that our implementation differs from the real system:
- Set up an epoll watching the FD
- Call epoll_wait
- Set up another epoll watching the same FD
- Call epoll_wait on the first epoll. Nothing should be reported!
This happened because, in ``epoll_ctl``, we used ``check_and_update_readiness``, which is a function that would return notification for all epoll file description that registered a particular file description. But we shouldn't do that because no notification should be returned if there is no I/O activity between two ``epoll_wait`` (every first ``epoll_wait`` that happens after ``epoll_ctl`` is an exception, we should return notification that reflects the readiness of file description).
r? `@oli-obk`
epoll: Add a EINVAL case
In ``epoll_ctl`` documentation, it is mentioned that:
> EINVAL epfd is not an epoll file descriptor, or fd is the same as epfd, or the requested operation op is not supported by this interface.
So I added this EINVAL case for ``epfd == fd`` in ``epoll_ctl``
fix: rust-analyzer should watch build files from rust-project.json
rust-analyzer always watches Cargo.toml for changes, but other build systems using rust-project.json have their own build files.
Ensure we also watch those for changes, so we know when to reconfigure rust-analyzer when dependencies change.
- `new_zeroed` variants move to `new_zeroed_alloc`
- the `write` fn moves to `box_uninit_write`
The remainder will be stabilized in upcoming patches, as
it was decided to only stabilize `uninit*` and `assume_init`.
fix: Wrong `Self: Sized` predicate for trait assoc items
Again while implementing object safety like #17939😅
If we call `generic_predicates_query` on `fn foo` in the following code;
```
trait Foo {
fn foo();
}
```
It returns implicit bound `Self: Sized`, even though `Self` is not appearing as a generic parameter inside angle brackets, but as a parent generic parameter, "trait self".
This PR prevent pushing "implicit" `Self: Sized` predicates in such cases
