当加载共享库时，链接器可以检查这些符号的存在，从而防止在加载器请求不兼容版本的canaries时进行链接。

#[stabby::导入(...)]

使用此注释来标记一个extern块，等同于#[link(...)]，但符号将通过使用<fn_name>_stabbied进行惰性初始化，确保在调用它之前函数参数的报告是一致的。

如果您想在不惊慌的情况下处理潜在的匹配错误，可以调用<fn_name>.as_ref()，这将在失败的情况下允许您检查<fn_name>的报告。

#[stabby::导入(金丝雀="rustc, opt_level", ...)]

使用此注释来标记一个extern块，等同于#[link(...)]，但需要与您的规格对应的canaries才能进行链接。这类似于export(canaries)，它总是导出所有可用的canaries，但您可以从以下集合中选择要启用的canaries。

• paranoid：启用所有canaries，如果您使用canaries=""，也将选择此选项。
• rustc：启用rustc版本上的canary（总是更新到commit版本）。
• opt_level：启用opt_level上的canary（对于extern "rust" fn是必要的，因为优化级别可能会改变调用约定）。
• target：启用用于构建对象的编译器目标三重态上的canary。
• num_jobs（paranoid）：启用用于构建对象的作业数量上的canary。这可能影响优化，因此可能会影响ABI（未经证实）。
• debug（paranoid）：启用是否使用调试符号构建对象的canary。对ABI的影响未经证实，但并未排除。
• host（paranoid）：启用由编译器设置的编译器宿主三重态上的canary。对ABI的影响未经证实，但并未排除。
• none：主要是为了让您完全禁用canaries，但需自行承担风险。

stabby::libloading::StabbyLibrary特质

为libloading::Library提供的附加方法，这些方法公开了符号获取器，如果canaries不存在或报告不匹配，则这些获取器会失败。

这些方法仍然被认为是不可安全的，但它们将减少意外加载ABI不兼容代码的风险。报告还充当运行时类型检查，减少错误输入符号的风险。

异步

在任何稳定类型上实现 core::future::Future，都将适用于该稳定类型被构造的FFI边界哪一侧。然而，由异步块和异步函数创建的future并不具有ABI稳定性，因此必须通过trait对象来使用。

stabby 通过 stabby::future::Future trait 支持future。异步函数被 #[stabby::stabby] 转换为返回 Dyn<Box<()>, vtable!(stabby::future::Future + Send + Sync)>（可以使用 #[stabby::stabby(unsync, unsend)] 移除 Send 和 Sync 的界限），它本身实现了 core::future::Future。

stabby 目前还不支持异步trait，但你可以使用以下模式来实现它们

use stabby::{slice::SliceMut, future::DynFuture};
#[stabby::stabby]
pub trait AsyncRead {
	fn read<'a>(&'a mut self, buffer: SliceMut<'a, [u8]>) -> DynFuture<'a, usize>;
}
impl MyAsyncTrait for SocketReader {
	extern "C" fn read<'a>(&'a mut self, mut buffer: SliceMut<'a, [u8]>) -> DynFuture<'a, usize> {
		Box::new(
			async move {
				let slice = buffer.deref_mut();
				let read = SocketReader::read_async(&mut self.socket, slice).await;
				buffer = slice.into();
				read
			}
		).into()
	}
}

增量稳定性

stabby 还允许你使用 stabby::abi::StableLike 告诉它某些内容即使你没有使用 #[stabby::stabby] 全程也可以是ABI稳定的。

与在 stabby::compiler_version 中实现的 stabby::IStable 相关的ZST相结合，但这仅限于使用相应编译器的版本编译时。这允许你声明某些类型只有在编译时使用适当的编译器版本才具有稳定性。但是，即使不使用相应的编译器版本，ZST仍然存在，因此这些类型仍然可以在没有 stabby::IStable 界定的任何地方使用。

stabby 的“宣言”

stabby 是针对Rust生态系统中缺乏ABI稳定性而构建的，这使得编写插件和其他基于动态链接的程序变得痛苦。目前，Rust的唯一稳定ABI是C ABI，它没有sum-type的概念，更不用说利基利用了。

然而，我们在软件工程方面的经验表明，类型大小对性能有很大影响，因此sum-type应该以占用空间最少的方式编码。

我对 stabby 的希望有两种口味

• Rust生态系统的采用：这是我最不喜欢的选项，但这至少可以让人们在需要动态链接的情况下有更好的Rust体验。
• 引发了一场关于为Rust提供非稳定而是版本化ABI的讨论：stabby通过选择版本化的stabby-abi crate本质上已经提供了版本化的ABI。然而，让库实现类型布局，这通常是编译器的任务，迫使abi-stability需要针对每个类型进行显式处理，而不是适用于整个编译单元。在我看来，在cargo清单中添加一个abi = "<stabby/crabi/c>"键将是一个更好的方法。更好的是，将这个想法与RFC 3435合并，允许基于函数选择ABI，并让编译器在注解函数接口的类型中引入所选的稳定ABI，这将更加细致，但仍然允许最终用户通过承诺依赖项的单一版本来实现ABI稳定性。

stabby的SemVer策略

Stabby将其所有stabby_abi::IStable实现包含在其公共API中：对IStable类型内存表示的任何更改都是破坏性更改，这将导致MAJOR版本更改。

从6.1.1版本开始，Stabby遵循SemVer Prime，使用api, abi作为关键。以下是一些你可以解释的方法

• stabby.version[level] = 2^(api[level]) * 3^(abi[level])让你计算stabby的ABI和API的确切版本。
• 当升级stabby时，你可以通过除以新版本和上一个版本来检查发生了什么变化：如果除法结果是2的倍数，则更改影响了API；如果是3的倍数，则影响了ABI。
  • ABI版本化
    • 将新类型添加到ABI稳定类型集合将提高ABI补丁版本。
    • 以任何方式修改现有类型的ABI将提高ABI主版本。
  • API版本化严格遵循SemVer策略。任何在文档中可见的API都视为公共API，以及文档中提到的任何合同。