Serde accidentally raised its MSRV to 1.51.0 in a patch release. They
don't intent to fix it. Nix uses Serde via cargo-hack in CI. Disable it
so we can publish a final release at 1.46.0.
To enforce uniformity for all PRs, the CI checks if the code
is formatted rigth using `cargo fmt` tool.
Signed-off-by: Costin-Robert Sin <sin.costinrobert@gmail.com>
The existing AIO implementation has some problems:
1) The in_progress field is checked at runtime, not compile time.
2) The mutable field is checked at runtime, not compile time.
3) A downstream lio_listio user must store extra state to track whether
the whole operation is partially, completely, or not at all
submitted.
4) Nix does heap allocation itself, rather than allowing the caller to
choose it. This can result in double (or triple, or quadruple)
boxing.
5) There's no easy way to use lio_listio to submit multiple operations with
a single syscall, but poll each individually.
6) The lio_listio usage is far from transparent and zero-cost.
7) No aio_readv or aio_writev support.
8) priority has type c_int; should be i32
9) aio_return should return a usize instead of an isize, since it only
uses negative values to indicate errors, which Rust represents via
the Result type.
This rewrite solves several problems:
1) Unsolved. I don't think it can be solved without something like
C++'s guaranteed type elision. It might require changing the
signature of Future::poll too.
2) Solved.
3) Solved, by the new in_progress method and by removing the complicated
lio_listio resubmit code.
4) Solved.
5) Solved.
6) Solved, by removing the lio_listo resubmit code. It can be
reimplemented downstream if necessary. Or even in Nix, but it
doesn't fit Nix's theme of zero-cost abstractions.
7) Solved.
8) Solved.
9) Solved.
The rewrite includes functions that don't work on FreeBSD, so add CI
testing for FreeBSD 14 too.
By default only enable tests that will pass on FreeBSD 12.3. But run a
CI job on FreeBSD 14 and set a flag that will enable such tests.
1699: Revert "Pin nightly compiler used in CI for uclibc" r=rtzoeller a=asomers
This reverts commit 23f18dfc18.
libc v0.2.124 fixes the problem.
Co-authored-by: Alan Somers <asomers@gmail.com>
The latest redox-syscall crate requires at least Rust 1.59.0, but they
don't define an MSRV policy. And the version given in the
rust-toolchain file in the Redox repository doesn't work. So until they
clarify their MSRV, use nightly.
30f29c3295
On some platforms, mqd_t is a pointer. That means code like the below
can trigger a segfault. Fix it by defining a Newtype around mqd_t that
prevents use-after-free and dangling pointer scenarios.
```rust
fn invalid_mqd_t() {
let mqd: libc::mqd_t = std::ptr::null_mut();
mq_close(mqd).unwrap();
}
```
Also, get test coverage for mqueue in CI on FreeBSD.
When testing with older versions of rustc, there's a CI failure mode
when our dependency, which used to be compatible with that Rust version,
publishes a new version which can't be compiled using that old Rust
anymore. That's pretty unfortunate, as that means that third parties can
break our CI without any changes to the code in this repo.
To protect against that, let's use Cargo.lock on CI, but only when
testing against older versions. For stable Rust, we continue to generate
Cargo.lock with freshest dependencies. Implementation wise, we save
known-good Cargo.lock as `Cargo.lock.msrv`, and just copy that in every
relevant CI job.
To get a working `Cargo.lock.msrv`, I run `cargo +nightly
generate-lockfile -Zminimal-versions` -- that is guaranteed to support
the oldest Rust version we can.
libc::stat is deprecated on DragonflyBSD in libc. But there isn't any
alternative yet, so Nix must simply suppress the warnings. It's used in
too many places to suppress each one individually, so just suppress all
deprecation warnings globally until it's properly fixed.
https://github.com/rust-lang/libc/pull/2522
The latest libc uses the native_link_modifiers feature, which isn't
known by the old compiler used in the Redox builds. Update Redox's
compiler to that used by the Redox project itself.
A bug in gimli-rs/object is causing the build to fail at the
"cargo install cross" step. Until that's fixed, we must use Rust 1.51.0
or newer for cross-based builds.
https://github.com/gimli-rs/object/issues/394
Apparently AWS Graviton containers don't support it. socket() retunrs
EAFNOSUPPORT in that environment.
Also, be more selective about skipping tests under QEMU
Instead of skipping them on architectures where we happen to use QEMU,
only skip them when QEMU is actually being used.
* Install cross the easy way, via cargo
* Don't test in release mode. Nix contains no release-dependent paths,
and release mode testing has to my knowledge never revealed a bug in
Nix.
* Add Linux powerpc back to CI, fixed by the latest cross.
* Check the tests even on platforms that can't run them.
* DRY for the Illumos and Redox sections
* Cross-check iOS from a Linux VM instead of OSX
* Revert the workaround for rust-lang/rustup issue 2774
* libc::aiocb must not be moved while the kernel has a pointer to it.
This change enforces that requirement by using std::pin.
* Split LioCbBuilder out of LioCb. struct LioCb relied on the
(incorrect) assumption that a Vec's elements have a stable location in
memory. That's not true; they can be moved during Vec::push. The
solution is to use a Vec in the new Builder struct, but finalize it to
a boxed slice (which doesn't support push) before allowing it to be
submitted to the kernel.
* Eliminate owned buffer types. mio-aio no longer uses owned buffers
with nix::aio. There's little need for it in the world of
async/await. I'm not aware of any other consumers. This
substantially simplifies the code.
Travis didn't compile check tests on platforms that couldn't run tests
in CI, so they bitrotted. Let's see how bad they are.
Most annoyingly, 32-bit Android defines mode_t as 16 bits, but
stat.st_mode as 32-bits.
