One of `CStr` constructors, `CStr::from_bytes_with_nul(bytes: &[u8])` handles 3 cases:
1. `bytes` has one NULL as the last value - creates CStr
2. `bytes` has no NULL - error
3. `bytes` has a NULL in some other position - error

The 3rd case is error that may require lossy conversion, but the 2nd case can easily be handled by the user code. Unfortunately, this function returns an opaque `FromBytesWithNulError` error in both 2nd and 3rd case, so the user cannot detect just the 2nd case - having to re-implement the entire function and bring in the `memchr` dependency.

In [this code](https://github.com/gquintard/varnish-rs/blob/f86d7a87683b08d2e634d63e77d9dc1d24ed4a13/varnish-sys/src/vcl/ws.rs#L158), my FFI code needs to copy user's `&[u8]` into a C-allocated memory blob in a NUL-terminated `CStr` format.  My code must first validate if `&[u8]` has a trailing NUL (case 1), no NUL (adds one on the fly - case 2), or NUL in the middle (3rd case - error). I had to re-implement `from_bytes_with_nul` and add `memchr`dependency just to handle the 2nd case.

This PR renames the former `kind` enum from `FromBytesWithNulErrorKind` to `FromBytesWithNulError`, and removes the original struct.

Enable optimised AArch64 dist builds with the opt-dist pipeline.

For the time being, disable bolt on aarch64 due to upstream bolt bugs.

Co-authored-by: Eric Huss <eric@huss.org>

Combined with [1], this will change the overflowing multiplication
operations to return an `extern "C"`-safe type.

Link: rust-lang/compiler-builtins#735 [1]

0.1.142 fixes an issue parsing optimization flags, and 0.1.143 changes
`__rust_[ui]128_*` builtins to use a C-safe signature.

…rly monomorphizing drop for structs

…ptr).field` instead of `ptr.offset(...).cast()`.

Also, the macro is only called three times, and all with the same local variable entry_ptr, so just use the local variable directly,
and rename the macro to entry_field_ptr.

Make missing_abi lint warn-by-default.

This makes the missing_abi lint warn-by-default, as suggested here: rust-lang/rfcs#3722 (comment)

This needs a lang FCP.

…Kobzol

ci: Enable opt-dist for dist-aarch64-linux builds

Move the CI dist-aarch64-linux job to an aarch64 runner and enable optimised dist builds with the opt-dist pipeline.

For the time being, disable bolt on aarch64 due to upstream bolt bugs.

r? `@Kobzol`
cc `@lqd`

try-job: dist-aarch64-linux

Convert `struct FromBytesWithNulError` into enum

This PR renames the former `kind` enum from `FromBytesWithNulErrorKind` to `FromBytesWithNulError`, and removes the original struct.

See rust-lang/libs-team#493

## Possible Changes - TBD
* [x] should the new `enum FromBytesWithNulError` derive `Copy`?
* [ ] should there be any new/changed attributes?
* [x] add some more tests

## Problem

One of `CStr` constructors, `CStr::from_bytes_with_nul(bytes: &[u8])` handles 3 cases:
1. `bytes` has one NULL as the last value - creates CStr
2. `bytes` has no NULL - error
3. `bytes` has a NULL in some other position - error

The 3rd case is error that may require lossy conversion, but the 2nd case can easily be handled by the user code. Unfortunately, this function returns an opaque `FromBytesWithNulError` error in both 2nd and 3rd case, so the user cannot detect just the 2nd case - having to re-implement the entire function and bring in the `memchr` dependency.

## Motivating examples or use cases

In [this code](https://github.com/gquintard/varnish-rs/blob/f86d7a87683b08d2e634d63e77d9dc1d24ed4a13/varnish-sys/src/vcl/ws.rs#L158), my FFI code needs to copy user's `&[u8]` into a C-allocated memory blob in a NUL-terminated `CStr` format.  My code must first validate if `&[u8]` has a trailing NUL (case 1), no NUL (adds one on the fly - case 2), or NUL in the middle (3rd case - error). I had to re-implement `from_bytes_with_nul` and add `memchr`dependency just to handle the 2nd case.

r? `@Amanieu`

…=bjorn3,antoyo

Use a C-safe return type for `__rust_[ui]128_*` overflowing intrinsics

Combined with [1], this will change the overflowing multiplication operations to return an `extern "C"`-safe type.

Link: rust-lang/compiler-builtins#735 [1]

Update `ReadDir::next` in `std::sys::pal::unix::fs` to use `&raw const (*p).field` instead of `p.byte_offset().cast()`

Since rust-lang/reference#1387 and rust-lang#117572, `&raw mut (*p).field`/`addr_of!((*p).field)` is defined to have the same inbounds preconditions as `ptr::offset`/`ptr::byte_offset`. I.e. `&raw const (*p).field` does not require that `p: *const T` point to a full `size_of::<T>()` bytes of memory, only that `p.byte_add(offset_of!(T, field))` is defined.

The old comment "[...] we don't even get to use `&raw const (*entry_ptr).d_name` because that operation requires the full extent of *entry_ptr to be in bounds of the same allocation, which is not necessarily the case here [...]" is now outdated, and the code can be simplified to use `&raw const (*entry_ptr).field`.

-------

There should be no behavior differences from this PR.

The `: *const dirent64` on line 716 and the `const _: usize = mem::offset_of!(dirent64, $field);` and comment on lines 749-751 are just sanity checks and should not affect semantics.

Since the `offset_ptr!` macro is only called three times, and all with the same local variable entry_ptr, I just used the local variable directly in the macro instead of taking it as an input, and renamed the macro to `entry_field_ptr!`.

The whole macro could also be removed and replaced with just using `&raw const (*entry_ptr).field`  in the three places, but the comments on the macro seemed worthwhile to keep.

…huss

Detect unstable lint docs that dont enable their feature

Makes sure that we detect cases where unstable lint's docs don't enable the corresponding feature.

r? ehuss

…op-with-lifetimes, r=BoxyUwU

Make sure we actually use the right trivial lifetime substs when eagerly monomorphizing drop for ADTs

Absolutely clueless mistake of mine. Whoops.

When eagerly collecting mono items, when we encounter an ADT, we try to monomorphize its drop glue. In rust-lang#135313, I made it so that this acts more like eagerly monomorphizing functions, where we allow (in this case) ADTs with lifetimes, since those can be erased by codegen.

However, I did not account for the call to `instantiate_and_check_impossible_predicates`, which was still passing an empty set of args. This means that if the ADT in question had any predicates, we'd get an index out of bounds panic.

This PR creates the correct set of args for the ADT.

Fixes rust-lang#135515. I assume that this manifests in that issue because of `-Clink-dead-code` or something.