Project "Remove memoffset"

Draft, here be dragons.
I recently attempted to prune some dependencies for one of my projects which resulted in this PR replacing memoffset::offset_of with core::mem::offset_of.

Two things made this possible:
  1. That crate’s MSRV
    Minimum Supported Rust Version
    was above 1.77 which was when core::mem::offset_of was stabilised.
  2. The two macros should be completely compatible. memoffset states that

If you’re using a rustc version greater or equal to 1.77, this crate’s offset_of!() macro simply forwards to core::mem::offset_of!().

The PR was merged :)

I then wondered how many other crates still unnecessarily have such a dependency on memoffset?

crates.io showed 237 reverse dependencies, of which 1 has already accepted my PR to fix things.

I am NOT going to fix all of them
and some can’t remove this dependency because they want to support a MSRV below 1.77
but let’s have a go and fire off a bunch of PRs, shall we?

Some observations from looking at a bunch of crates and sending out a lot of PRs.

MSRV is often quite unclear. Upstream MSRV can differ substantially from the MSRV in the latest release version, particularly for crates with a low release frequency. The edition (like e.g. Rust 2021) required is sometimes not available on the declared MSRV. Platform-specific or dev-dependencies can have more relaxed standards than the “main” codebase. Component or helper crates in larger codebases sometimes don’t have any MSRV declared while the “main” crates do.

People are really friendly. I’ve had nothing but good interactions with complete strangers during this project which actually brightened up my day. It feels good, worth trying if you need a dose of positivity. Many issues and PRs were swiftly handled and so far none were refused.

There’s low-hanging fruit in removing old dependencies. I stumbled on this by accident but the list of other crates (partially) moved into std is substantial. Admittedly, many uses are only as a dev-dependency.

In a year or so we can start doing the same trick by replacing uses of the cfg-if crate with cfg_select introduced recently in 1.95.

I started thinking about what other old dependencies can be removed but this list from rust-lang/std-replacement-data contains exactly that information!

Here’s a list of reverse dependencies sorted by total downloads, I stopped when total downloads dipped below 50k.
Crate MSRV PR sent Fixed/PR accepted
rustix 1.65 No, also uses span_of!
nix 1.69 No, aware
zlib-rs 1.75 No, aware
objc2 1.71 Issue Yes
wayland-sys 1.86 Yes Yes
uds_windows 1.85 Yes
field-offset No
solana-program 1.81 Yes Yes
egui_glow 1.92 Yes Yes
intrusive-collections 1.82 Yes Yes
wasmtime-runtime dead crate
foyer-intrusive-collections
wasmer-types 1.93 Yes Yes
wasmer-vm 1.93 Yes Yes
solana-stable-layout 1.89 Yes Yes
solana-loader-v4-interface 1.89
solana-runtime 2024 edition
blazesym-c 1.88 Yes Yes
starlark 2024 edition Issue Yes
glium
virtio-queue
authenticator Yes Yes
solana-accounts-db
const-field-offset-macro 1.88
imgui 1.82 Yes
speedy
type-layout
ggez 1.56
implib
near-vm-runner
wasmer-vm-near
wasmer-compiler-singlepass-near
ntfs 1.83 Yes
gpgme
az-cvm-vtpm
linera-wasmer-vm
cargo-modules 1.91 Waiting on intrusive-collections
pgx-pg-sys
savefile
mpi 1.78 Yes Yes
perf-event-open-sys2
intuicio-core
imgui-glow-renderer
c-scape
dep-obj
samply
authenticator-ctap2-2021
fdt-rs
lean-sys No
ktls 1.75 Issue
nbdkit
substrate-wasmtime-runtime
pc-ints 1.91 Yes
libertyos_kernel dead crate
fyrox-core 1.87 Yes Yes
lightbeam
light-bounded-vec
pete 1.64
ferrisetw
miraland-program
super_speedy_syslog_searcher
redbpf-probes
redbpf-macros
near-vm-vm
eastl-rs
rg3d-core dead crate
near-vm-compiler-singlepass
rafx-framework
mmtk 1.84 Yes Yes

Not sure how I feel about helping (even this tiniest bit) facebook and blockchain companies…