- 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
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.
- Ensure
stabbycompiles on non-rustup toolchains (thanks @fuzzypixelz). - Fix lints for CI.
- Make
Box::into_rawa const fn.
36.1.1 is 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
- Improve
DefaultAllocatorhandling
- 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.
- Refine
RustAlloc's implementation such that it stays a ZST.
- Refine support for
#[repr(transparent)]and#[repr(align(n))]in#[stabby::stabby]structs up to n=64kiB.
- Add support for
#[repr(transparent)]and#[repr(align(n))]in#[stabby::stabby]structs up to n=64kiB.
- Allow structures to compute their single-niche evaluation properly.
- 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.
- 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
- Relax many dependency requirements to help avoid conflicts with crates that pin them
- 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.
- 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 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.
- 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.
- Fix a regression in MSRV
- 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
- Fix for 1.72:
AllocPtr::prefixisconst fnfrom 1.73 onwards rather than 1.72 onwards (@yellowhatter).
- 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.
- 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
- Fix lifetimes seeping in code generation in traits, allowing more valid code to compile.
- Add constructors from slices for
Vec<T, A>,BoxedSlice<T, A>andArcSlice<T, A>whereTisCopyandAis a default constructible allocator.
- 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.
- Ensure docrs can properly build docs
- 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.
- Change the symbol mangling of stabbied functions to ensure an ABI-incompatible reports are never mixed.
- 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.
- Update constness to fit 1.72
- Ensure that 1.66 MSRV is respected
- 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.
- 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
- 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.
- Fix duplicated bounds on structures that would cause compile errors when a structure had several fields of the same type
- Actually expose
stabby::time::{Instant, SystemTime}
- Add trait implementations to
stabby::time::{Duration, Instant, SystemTime}. - Improve release process (releases are now based on changelogs, which should become more accurate)
- Marked
std::os::fd::{OwnedFd, BorrowedFd}as stable. - Added support for
core::time::Durationandstd::time::{Instant, SystemTime}through equivalent types.
- Added support for
core::iter::Iterator. - Made release process more reliable.
- Added support for some of
abi_stable's types - Made checks for potential ABI misreports better
- Fix cyclic trait bounds arising when a stabby trait depended on a dyn-self
This is the base release of this CHANGELOG. Please refer to its README for more information.