stabby-abi
stabby's core ABI, you shouldn't add this crate to your dependencies, only `stabby`.
72.1.16
6.0M downloads/mo
#4127 most downloaded on crates.io
ZettaScaleLabs/stabby
What this package is like to depend on
Last release 1 months ago
20 Jul 2026
Release timing varies
gaps range from 9 days to 8 months
Nearly every release is documented
notes for 35 of 38 stable releases
5 versions withdrawn
withdrawn after publishing
3 years old
56 releases · first in 2023
5 releases in the last 12 months
see the full history below
Release timeline
56 releases · Mar 2023 to Jul 2026Releases
latest 56-
72.1.1620 Jul 2026Release notes
Open source →- Fix clippy lints for 1.97, and a few typos.
Vec::try_drain's index validation was reversed, making it not only buggy, but unsound:- it would always reject ranges that were in bound, and out-of-bounds ranges could be accepted, risking multiple UBs:
Vec::set_lencould extend the vec into uninitialized memory,- the returned
Draincould iterate over uninitialized memory as well.
- Hopefully, no users were impacted:
Vec::drain(which I expect most users would pick unless they wanted to guarantee no panics could ever occur) was always valid, and I expect most users who triedtry_drainfound it to not work (since it rejected all valid input). - Thanks to @eslerm, who raised the issue privately to avoid broadcasting it before a fix would be made available.
- it would always reject ranges that were in bound, and out-of-bounds ranges could be accepted, risking multiple UBs:
- Improved error message when a stabbied trait declaration attempts to use
Selfin signature, #101 shows that the previous error message was absolutely useless to users.
-
72.1.812 Jun 2026Release notes
Open source →- Make builds more reproducible #136 (thanks @pablo-smith-saronic for raising the issue and providing the fix)
- Fix CI for Rust 1.72, fix support for 1.72
- Enable more lints to prevent unexpected panics
-
72.1.409 Jun 2026 -
72.1.205 Jun 2026 -
72.1.2-rc118 Jan 2026 pre-releaseRelease notes
Open source →- Fixed #112 (thanks @Dasaav-dsv for both raising the issue and providing the fix)
- Fixed #103 (thanks @numberZero for raising the issue)
- Address all lints for Rust and Clippy at
1.92.0 - Add support for
libloading = "0.9" - Make CI run more feature-sets and toolchains
- Fix owned string deserialization
- Fixed Eclipse headers
-
72.1.112 May 2025Release notes
Open source →stabbyis now fully MIRI tested.- To allow certain operations to be made in a way that MIRI confidently detected as non-UB, new lifetime parameters were added to the generated VTable code. While the layout is actually the same, this does cause a breaking change in code that you should rarely interact with.
-
36.2.223 Feb 2025Release notes
Open source →- Ensure
stabbycompiles on non-rustup toolchains (thanks @fuzzypixelz). - Fix lints for CI.
- Ensure
-
36.1.131 Jul 2024Release notes
Open source →36.1.1is the sum of all the previous release candidates. Here's a recap!#[stabby::stabby]can now understand when a type refers to itself to avoid forming proof cycles.stabby::collections::arc_btree's types are now ABI-stable!- Add the
#[stabby::vt_attr(_)]sub-attribute to#[stabby::stabby]on traits, letting you place custom attributes on the v-tables generated for a trait. - Add support for
core::ffi::c_void. - FIx single-niche evaluation for structures.
- Add support for
#[repr(transparent)]and#[repr(align(n))]in#[stabby::stabby]structs up to n=64kiB. - Added more constructors (such as
FromIterator) forBoxedSliceandArcSlice. - Added support for more niche platforms.
- BREAKING CHANGES: Mostly due to a large rework of allocations.
- The in-place constructors for
BoxandArcnow require the initializer function to return a result, yielding the uninitialized allocation if allocation succeeded, but initialization reported a failure. serdeandlibcfeatures are no longer part of the default features set.RustAllocis the new default allocator ofstabby: this allocator is a simple pointer to a v-table allowing cross-ffi use of Rust'salloc::GlobalAlloc.- This allocator is global, thread-safe, and guaranteed to work properly with pointers passed across the FFI.
- Benchmarks indicate that performance between
RustAllocandLibcAllocis equivalent. - However, it is non-zero-sized, and therefore makes types that don't always shove it into their
AllocPrefixare slightly bigger when usingRustAllocrather thanLibcAlloc. - The reason for this change is that
LibcAllocisn't available on certain platforms, whereasRustAllocis available on any platform supported by Rust. Importantly, thewasm32architecture was unsupported until now.
- The
libc_allocmodule was replaced by theallocatorsmodule to improve readability. - While the previous
IAllocversion was fine to interface withlibc::malloc's API, it actually had a few big holes that required patching for custom allocators to be able to do interesting stuff.- This was unearthed by implementing
RustAlloc
- This was unearthed by implementing
- The
AllocPrefix's location relative to prefixed allocations (such as those used by all ofstabby's container types) has changed for types with alignments greater than pointer-size.- The prefix was previously placed as if the allocation held
Tuple2<AllocPrefix, T>, meaning that for larger alignments, there could be padding between the prefix and the pointed value.
- The prefix was previously placed as if the allocation held
- The in-place constructors for
-
36.1.1-rc808 Jul 2024 pre-release -
36.1.1-rc708 Jul 2024 pre-releaseRelease notes
Open source →- BREAKING CHANGES:
- The in-place constructors for
BoxandArcnow require the initializer function to return a result, yielding the uninitialized allocation if allocation succeeded, but initialization reported a failure.
- The in-place constructors for
- Added more constructors (such as
FromIterator) forBoxedSliceandArcSlice.
- BREAKING CHANGES:
-
36.1.1-rc607 Jul 2024 pre-release -
36.1.1-rc506 Jul 2024 pre-releaseRelease notes
Open source →- Refine support for
#[repr(transparent)]and#[repr(align(n))]in#[stabby::stabby]structs up to n=64kiB.
- Refine support for
-
36.1.1-rc405 Jul 2024 pre-releaseRelease notes
Open source →- Add support for
#[repr(transparent)]and#[repr(align(n))]in#[stabby::stabby]structs up to n=64kiB.
- Add support for
-
36.1.1-rc305 Jul 2024 pre-release -
36.1.1-rc205 Jul 2024 pre-releaseRelease notes
Open source →- Add the
#[stabby::vt_attr(_)]sub-attribute to#[stabby::stabby]on traits, letting you place custom attributes on the v-tables generated for a trait. - Add support for
core::ffi::c_void.
- Add the
-
36.1.1-rc105 Jul 2024 pre-releaseRelease notes
Open source →- BREAKING CHANGES: A large rework of allocation occurred, breaking both API and ABI compatibility with the previous version:
RustAllocis the new default allocator ofstabby: this allocator is a simple pointer to a v-table allowing cross-ffi use of Rust'salloc::GlobalAlloc.- This allocator is global, thread-safe, and guaranteed to work properly with pointers passed across the FFI.
- Benchmarks indicate that performance between
RustAllocandLibcAllocis equivalent. - However, it is non-zero-sized, and therefore makes types that don't always shove it into their
AllocPrefixare slightly bigger when usingRustAllocrather thanLibcAlloc. - The reason for this change is that
LibcAllocisn't available on certain platforms, whereasRustAllocis available on any platform supported by Rust. Importantly, thewasm32architecture was unsupported until now.
- The
libc_allocmodule was replaced by theallocatorsmodule to improve readability. - While the previous
IAllocversion was fine to interface withlibc::malloc's API, it actually had a few big holes that required patching for custom allocators to be able to do interesting stuff.- This was unearthed by implementing
RustAlloc
- This was unearthed by implementing
- The
AllocPrefix's location relative to prefixed allocations (such as those used by all ofstabby's container types) has changed for types with alignments greater than pointer-size.- The prefix was previously placed as if the allocation held
Tuple2<AllocPrefix, T>, meaning that for larger alignments, there could be padding between the prefix and the pointed value. - This padding has been removed, as it could cause soundness issues when the pointer was opacified, such as for trait objects.
- The prefix was previously placed as if the allocation held
serdeandlibcfeatures are no longer part of the default features set.
stabby::collections::arc_btree's types are now ABI-stable.#[stabby::stabby]can now understand when a type refers to itself to avoid forming proof cycles.- The
experimental-ctypesfeature-flag was added to mark the integration betweenstabbyandsafer-ffias experimental.- Experimental feature-flags and any API/ABI they annotate are allowed to be broken without triggering a
majorupdate, but aminorinstead. If you rely on these features, pinning your minor is advised.
- Experimental feature-flags and any API/ABI they annotate are allowed to be broken without triggering a
- BREAKING CHANGES: A large rework of allocation occurred, breaking both API and ABI compatibility with the previous version:
-
6.4.1-rc127 Jun 2024 pre-releaseRelease notes
Open source →- Found out that
libcdoesn't expose any allocation primitives forwasmtargets.- These targets now have a poor man's allocator. Be warned that while ABI-stable, this allocator is trivial and probably bad.
Ifwasmis indeed a target which you care a lot about, and you use stabby's allocation primitives a lot, you should probably roll out a better one (maybe even contribute it back). - This allocator is not included in
stabby's cross-version contract: it may be swapped out for a better one in a patch-level API-bump.
If you need me not to do so (i.e. you pass stabby's allocation primitives inwasmbetween multiple packages and can't pin your version ofstabbydown to patch for X reason), please reach out to me.
- These targets now have a poor man's allocator. Be warned that while ABI-stable, this allocator is trivial and probably bad.
- Found out that
-
6.2.201 Jul 2024Release notes
Open source →- Relax many dependency requirements to help avoid conflicts with crates that pin them
-
6.2.127 Jun 2024Release notes
Open source →- Add support for
#[stabby::stabby(version=10, module="my::module")]to let you change the values in those fields without having to implement the whole trait yourself. - Add support for
serdethrough theserdefeature flag. - Add conversions between
stdandstabbyStrings. - Fix an issue where optimized layout checks would prevent compilation due to missing trait bounds.
- Fix estimation of
IStable::CTypefor arrays.
- Add support for
-
6.1.125 Jun 2024Release notes
Open source →- Add support for multi-fields variants in
repr(C, u*)enums.- Deprecate support for
repr(C)by deprecating any enum that uses it without also specifying a determinant size.
- Deprecate support for
- Add support for
Result<T, core::conver::Infallible>, which is fully identical toTdown to its reports. - Remove
CompilerVersion_X_Y_Ztypes: keeping them up to date with new compiler release was too much maintenance. - Remove
CurrentCompilerVersiontype alias: as it could break your code if you upgraded to a version of the compiler thatstabbydidn't know of. - Prepare integration of
stabbyandsafer-ffiby addingCTypeandis_invalidtoIStable. - Switch versioning system to SemVer Prime, using the
api, abias the key. - RFC 3633 which seeks to address the breaking change in Rust 1.78 is scheduled to be discussed in July 2024.
- Add support for multi-fields variants in
-
5.1.007 Jun 2024Release notes
Open source →- Introducing
stabby::collections::arc_btree, a set of copy-on-write btrees:ArcBtreeSetandArcBtreeMapbehave like you would expect, but share nodes with their clones.- When mutating one of their nodes (either because an entry is changed, or because a child node required a carry-over operation to complete its own mutation), one of two cases will happen:
- The node wasn't shared: it is mutated in place.
- The node was shared: it is copied (increasing its children's reference counts), mutated, and the parent node is mutated to replace the shared node by its mutated copy. This behaviour keeps recursing until the root if necessary.
AtomicArcBtreeSetis a lock-free set based onArcBtreeSet: when a node is inserted, the root pointer is cloned, the clone is mutated (causing its root pointer to change), and replaced. If the root pointer changed since reading it, the process is tried again.- This is notably how
stabbyglobal set of vtables is implemented to support stable Rust from version 1.78 onward, until the static-promotion regression is fixed, and this global set can be removed.
- This is notably how
- Add some missing
SendandSyncimplementations for container types. - Fix a lot of nightly lints.
- Introducing
-
5.0.122 May 2024 -
5.0.003 May 2024Release notes
Open source →- BREAKING CHANGE:
- Due to a soundness hole in the previous implementation of
stabby::result::Result, its representation was overhauled. While it's still technically compatible binary-wise (meaning it still follows the original spec), the soundness hole could possibly lead to UB, sostabbywill treat them as incompatible.
- Due to a soundness hole in the previous implementation of
- Add support for Rust 1.78:
- With 1.78, Rust merged a breaking change which impacts
stabby. This change prevents consts from refering to generics entirely, which was key tostabby's implementation of vtables. - More accurately, it prevents consts from refering to generics that aren't bound by
core::marker::Freeze, but that trait hasn't been stabilized at the same time as the new error has. - While the team was aware that this would be a breaking change,
craterfailed to report thatstabbywas impacted by the regression, as it tried compiling an obsolete version ofstabbythat could only build with pre-1.77 versions of Rust due to theu128ABI-break on x86. This led them to judge that the breaking change was acceptable. - To compensate for this,
stabbywill (for non-nighly>=1.78versions of Rust) draw its vtable references from a heap-allocated, lazily populated, global set of vtables. This is in opposition to the<1.78andnightlybehaviour where it'll keep on drawing these vtable references straight from the binary.- From this release onwards, a new priority for
stabbywill be to improve the performance of this behaviour; or better yet find a new way to obtain the previous behaviour that compiles.
- From this release onwards, a new priority for
- While I can't hide that I am very annoyed at this development, I must also state that I understand the Rust Team's choice to ship this breaking change: they considered this potential window for a soundness hole a bug, and even though
craterdidn't report any use of this bug that was unsound, it also failed to reportstabbyas a legitimate user of it. I do wish they'd have waited forFreeze's stabilization to make the breaking change however, as the sound pattern it would prevent, as well as the fact that it couldn't be replicated withoutFreeze, was known.
- With 1.78, Rust merged a breaking change which impacts
- BREAKING CHANGE:
-
4.0.509 Apr 2024Release notes
Open source →- Fix for 1.72:
AllocPtr::prefixisconst fnfrom 1.73 onwards rather than 1.72 onwards (@yellowhatter).
- Fix for 1.72:
-
4.0.403 Apr 2024Release notes
Open source →- Introduce a tutorial to help onboard new users.
- Available as
stabby/TUTORIAL.mdin sources. - Inserted as the documentation to a docs-only
stabby::_tutorial_module. This ensures that codeblocks in it compile and that links to the doc are checked.
- Available as
- Allow
stabby::sync::Weakto function as a pointer-type for fat pointers, allowing thestabby::dynptr!(Weak<dyn Trait>)pattern.- This can be helpful if you're building a plugin that needs to refer to its host weakly to avoid cycles, for example.
- Introduce a tutorial to help onboard new users.
-
4.0.328 Mar 2024Release notes
Open source →- Ensure
stabbycompiles onnightlyby usingcore::marker::Freezeto reassure Rust that a bound that will eventually become required for const static references is respected by v-tables. - Small documentation pass on internals to make nightly clippy happy
- Ensure
-
4.0.211 Mar 2024Release notes
Open source →- Fix lifetimes seeping in code generation in traits, allowing more valid code to compile.
-
4.0.104 Mar 2024Release notes
Open source →- Add constructors from slices for
Vec<T, A>,BoxedSlice<T, A>andArcSlice<T, A>whereTisCopyandAis a default constructible allocator.
- Add constructors from slices for
-
4.0.004 Mar 2024Release notes
Open source →- With Rust 1.77,
u128's alignment changes to 16 bytes. This version ofstabbysupports both and is able to tell them appart. - Fix a soundness hole in
Result, contaminating all#[repr(stabby)]enums: mutable references to a variant can no longer be held past the closure they originate from. This is needed because assigning to such a reference may override the determinant, whichstabbyreinserts at the end of the match. Passing a continuation inmatch_mut_ctxis the proper way to use a reference that may have originated from several variants. - Introduce the
uXandiXtypes. These types are implemented as a newtype on the smallest integer type that is larger than them, but expose niches that are exclusive tostabby. - Some benchmarks have been built to measure
stabby's impact on performance. The global result is thatstabbygenerally has similar performances tostd, being marginally faster and marginally slower depending on cases. Some specific exceptions exist:repr(stabby)enums get much slower than theirstdversions, due to not being able to constify some of its niche handling. They can however be more compact, letting them be faster when memory access become the bottleneck.stabby'sVecis faster at growing than Rust's thanks to a growth factor that minimizes memory partitioning. Note that your mileage may vary here, as a PR in the stdlib was attempted to use the same trick and did not yield better performances.stabbyis much faster at converting betweenVecandArcSlice, and between largeBoxes andArcs. This is thanks to allstabby::alloctypes sharing a slot in front of their payload to allow converting between them without reallocating.
- MIRI passes are being made to ensure that
stabbystays safely within defined behaviour.- Some UB may now no longer occur.
- Some UB is still detected in certain tests. Work is ongoing to remove said UB.
- With Rust 1.77,
-
3.0.312 Feb 2024 -
3.0.3-rc212 Feb 2024 pre-releaseNothing published for this version
-
3.0.3-rc112 Feb 2024 pre-releaseNothing published for this version
-
3.0.3-rc12 Feb 2024 pre-releaseNothing published for this version
-
3.0.209 Feb 2024Release notes
Open source →- Add support for
AtomicDurationandAtomicInstant: these allow storingDurations andInstants in an atomic manner, at the cost of their resolution being limited to 1μs and their range limited to ~270000 years. - Add many convenience methods to
stabby::time::Duration. - Fix typo in symbol mangling of report fetchers in
libloadingintegration: this typo meant that if a symbol was loaded, but the reports mismatched, the loader would be unable to extract the full report. While this wouldn't panic or cause UB, it would make the experience worse than expected. - Improve reliability by ensuring that the CI tests both load-time and runtime linkage with
stabby::importandlibloading::Library::get_stabbied.
- Add support for
-
3.0.109 Feb 2024Release notes
Open source →- Change the symbol mangling of stabbied functions to ensure an ABI-incompatible reports are never mixed.
-
3.0.009 Feb 2024Release notes
Open source →- BREAKING CHANGE:
- From now on, unless
#[repr(stabby)]is specified, stabbiedenums will throw a compile error if using#[repr(u8)]would yield a better or equal layout size. The default layout remains that produced when selecting#[repr(stabby)], so any crate that didn't use either annotation and wishes to keep the same ABI should annotate types that now throw that error with#[repr(stabby)]. - Some internal systems that were previously exposed because they needed to be public to appear in trait bounds have been sealed to avoid over-exposing the ABI.
stabby::report::TypeReportnow uses a singleu32to describe versions, as this is by far sufficient, and avoids clashes when ABI changes (such as invariants) appear between release versions.- For all allocated containers, the
newandmakemethods are now specific to the default allocator. Alternative allocators will have to usenew_in(Default::default())instead, but this makes using these constructors without type hints possible.
- From now on, unless
- DOCUMENT ALL THE THINGS:
stabbyandstabby-abiwill now both fail to compile if some of their elements are undocumented. - Introduce the
IPodtrait to help prove that a type is "Plain Old Data" and safe to transfer between processes that don't share memory or even file-system. This is notably meant to be used inzenoh's shared-memory API.
- BREAKING CHANGE:
-
2.0.106 Oct 2023 -
2.0.028 Sep 2023Release notes
Open source →- BREAKING CHANGE:
std::boxed::Boxandstd::sync::Arcwere originally marked asIStablebecause their representation was indeed stable provided they pointed to sized types. However, Rust has historically changed the default global allocator, and since it can be overriden, it's also possible to create two binaries with mismatching allocators on each side. This meant that these types didn't have "invariant stability": moving one over FFI wasn't guaranteed to not introduce UB.
- Introducing
stabby::alloc:IAlloc: a trait that defines an allocator. It's basically just an ABI-stable equivalent tostd::alloc::GlobalAllocator.Box<T, Alloc>,Arc<T, Alloc>, andVec<T, Alloc>, which emulate theirstdcounterparts.Allocdefaults toLibcAlloc, which is built atopposix_memalign/aligned_malloc. They have been built such that converting between them never causes a reallocation (converting from an emptyVecto aBoxorArcwill allocate, since these two types must always be allocated).BoxedSlice<T, Alloc>,BoxedStr<Alloc>,ArcSlice<T, Alloc>,ArcStr<Alloc>, exist to emulateBox<[T]>&co, and are also built to be convertible fromVec<T>without reallocating.- All of these duplicate all operations that may allocate with
tryvariants that will return an error instead of panicking on allocation failures.
- Better test coverage: the correct implementation of the spec is now fully verified.
- Better documentation:
stabbynow uses thedeny(missing_(safety|errors|panics)_doc)lints to ensure all failure conditions are always documented, and documents all of its macros outputs (often based on your own documentation) to allowstabbyto be used indeny(missing_docs)environments. [T; N]is now marked asIStableforNin0..=128.SingleOrVec<T, Alloc>is aVec-like container that will avoid allocating until you attempt to push a second element in it.- Introducing
NonMaxUx,NonXUx<const X: ux>andNonXIx<const X: ux>: equivalents toNonZerothat allow you to have another value as the niche.
- BREAKING CHANGE:
-
1.0.1013 Sep 2023Release notes
Open source →- Make bound deduction better for enums.
- Introduce
MaybeResolved: a future that may already be resolved to handle "maybe async" functions. stabbynow has support for custom allocators, and uses that to define truly ABI stable allocated types in thereallocmodule.- While Rust's standard
BoxandArchave stable layout, the default global allocator may change withoutstabbynoticing, they are therefore not truly ABI stable. stabby::realloc'sBox,ArcandVecall support custom allocators, and prefix all allocations with the same layout, this allows conversions between those types to never require a reallocation unless the target requires an allocation that the source type didn't, like converting aVecto anArc.
- While Rust's standard
-
1.0.929 Aug 2023Release notes
Open source →- Introduce better matchers for pattern-matching emulations when at the borrrow checker would forbid the previously available ones:
match_ref_ctx,match_mut_ctxandmatch_owned_ctxall take a context, and one closure per variant; and only call the closure corresponding to the current variant, passing the context as first argument.
- Introduce better matchers for pattern-matching emulations when at the borrrow checker would forbid the previously available ones:
-
1.0.829 Aug 2023Release notes
Open source →- Fix duplicated bounds on structures that would cause compile errors when a structure had several fields of the same type
-
1.0.728 Aug 2023 -
1.0.628 Aug 2023Release notes
Open source →- Add trait implementations to
stabby::time::{Duration, Instant, SystemTime}. - Improve release process (releases are now based on changelogs, which should become more accurate)
- Add trait implementations to
-
1.0.527 Aug 2023Release notes
Open source →- Marked
std::os::fd::{OwnedFd, BorrowedFd}as stable. - Added support for
core::time::Durationandstd::time::{Instant, SystemTime}through equivalent types.
- Marked
-
1.0.426 Aug 2023Release notes
Open source →- Added support for
core::iter::Iterator. - Made release process more reliable.
- Added support for
-
1.0.325 Aug 2023Release notes
Open source →- Added support for some of
abi_stable's types - Made checks for potential ABI misreports better
- Added support for some of
-
1.0.225 Aug 2023Nothing published for this version
-
1.0.117 Aug 2023Release notes
Open source →- Fix cyclic trait bounds arising when a stabby trait depended on a dyn-self
-
1.0.003 Jun 2023Release notes
Open source →This is the base release of this CHANGELOG. Please refer to its README for more information.
-
0.1.608 May 2023Nothing published for this version
-
0.1.530 Mar 2023Nothing published for this version
-
0.1.430 Mar 2023 withdrawnNothing published for this version
-
0.1.330 Mar 2023 withdrawnNothing published for this version
-
0.1.228 Mar 2023 withdrawnNothing published for this version
-
0.1.125 Mar 2023 withdrawnNothing published for this version
-
0.1.024 Mar 2023 withdrawnNothing published for this version