Rust 采纳 Ferrocene Language Specification
LWN.net News from the source
Rust 采纳 Ferrocene Language Specification
[发布于 2025年3月27日，作者 daroc]
长期以来，对 Rust 的一个批评是该语言没有官方规范。 这在一些注重安全的组织中，以及在编写替代语言实现时，构成了一个采用障碍。 现在，Rust 项目已经宣布它将采纳由 Ferrous Systems 开发的 Ferrocene Language Specification (FLS)，并将其作为核心项目的一部分进行维护。 虽然这可能无法满足狂热的标准制定流程爱好者，但这朝着消除在安全关键系统中使用 Rust 的又一个障碍迈出了一步。
正是基于这种认识，我们很高兴地宣布，我们将把 FLS 纳入 Rust 项目，作为我们正在进行的规范工作的一部分。 这次采纳之所以能够实现，要归功于 Ferrous Systems 对 FLS 的慷慨捐赠。 我们感谢他们在组装FLS、使其适合认证目的、推广其使用以及在安全关键行业中推广 Rust 的使用方面所做的工作，以及现在与我们合作采取下一步行动并将FLS纳入项目中所做的工作。
要发表评论
下一步：共享库？
发布于 2025年3月27日 21:16 UTC (周四)，作者 ballombe (订阅者, #9523) [链接] (12 条回复)
现在 Rust 只是缺少共享库，才能与 C++ 达到同等水平。
下一步：共享库？
发布于 2025年3月27日 22:28 UTC (周四)，作者 firstyear (订阅者, #89081) [链接] (7 条回复)
Rust 中的共享库不会发生。 它们永远不会发生。
请阅读一位深入了解该主题的 Rust 开发人员的文章。
"How Swift Achieved Dynamic Linking Where Rust Couldn't" - https://faultlore.com/blah/swift-abi/
下一步：共享库？
发布于 2025年3月27日 22:34 UTC (周四)，作者 Cyberax (✭ supporter ✭ , #52523) [链接]
不完全正确。 正在推动通过使用动态分发和一些预单态化类型来启用一些共享库代码（以及更紧凑的二进制文件）。
下一步：共享库？
发布于 2025年3月28日 5:40 UTC (周五)，作者 kxxt (订阅者, #172895) [链接]
可能会发生，但这需要在更新共享库时重建所有依赖的二进制文件。 （就像 Arch Linux 打包 Haskell 应用程序的方式：https://wiki.archlinux.org/title/Haskell）
https://www.kxxt.dev/blog/fully-dynamically-linked-rust-b...
共享库可以而且可能会发生
发布于 2025年3月28日 11:20 UTC (周五)，作者 farnz (订阅者, #17727) [链接] (4 条回复)
说“Rust 中的共享库不会发生”是对文章内容的曲解； 她正在撰写关于 Swift 如何实现具有 ABI 稳定性的任意动态链接的文章，其中任何 Swift 代码都可以与任何未来的 Swift 代码动态链接，而不管您使用什么语言特性。 在 Rust 中，等效的做法是您可以动态链接任意模块或 crate，而无需模块或 crate 的作者事先做任何工作来实现它。
至少有两种“共享库”的变体比 Aria 编写的版本简单得多，其中一种今天已经存在：
- 具有完全不稳定 ABI 的共享库。 这要求所有 Rust 代码都使用相同的工具链构建； 因为 Rust 支持单独的编译和链接，所以给定的工具链必须具有稳定的 ABI。 您今天可以做到这一点，但是每次您使用不同的工具链进行编译时（这可能像“我从 x86-64 为 RISC-V 交叉编译，您从 AArch64 交叉编译”一样微不足道的差异 - 这是两个不同的工具链，即使所有组件的版本相同），您需要重建所有内容。 但是，对于您控制整个构建系统和最终输出的嵌入式用例，它在今天是很实用的。
- 限制 crate 的 API 表面，并拥有一个有意导出的稳定 API，借助 crABI 之类的东西，它也可以是稳定的 ABI。 这要求 crate 作者做 glibc 维护者所做的那种工作，拥有一个他们故意保持稳定的 ABI 表面，以方便动态链接。 这在 Rust 中也是完全可能的； 唯一的问题是“谁来做这项工作”，以及“稳定 ABI 的限制有多大” - 目前，您仅限于 psABI，crABI 旨在将其扩展到有趣的类型，如元组、切片和和类型（Rust 枚举）。
然而，与 C 和 Swift 始终不同的是，Rust 动态链接不会是“偶然”发生的事情； 要么您作为下游必须确保您有一个稳定的工具链（第一种选择），要么（一旦第二种选择完全可行），您需要确保指定了稳定的 ABI 表面，并且对于 crate 的用户来说足够用。
共享库可以而且可能会发生
发布于 2025年3月28日 14:44 UTC (周五)，作者 Wol (订阅者, #4433) [链接] (3 条回复)
或者（一旦第二种选择完全可行），您需要确保指定了稳定的 ABI 表面，并且对于 crate 的用户来说足够用。 天真的问题，但我认为您可以使用某种方法从库 crate 中将 ABI 导出为定义文件？ 如果您可以反向运行它并将其提供给编译器以说“这是我想要的定义”，您将获得稳定的 ABI。 这可能吗？
更好的是，当您编译调用该 crate 的程序时，当然您需要导入该 ABI，但这然后意味着您可以在接口上强制执行 Rust 规则，而不是像从 C 调用/被调用时那样，只是信任接口是安全的。
然后，当然，您需要某种方法来标记内部 ABI 已经以（可能不兼容的）方式更改，需要新的定义导出。
但是考虑到 Rust 所做的其他“魔法”，这似乎并非不合理？
干杯，Wol
共享库可以而且可能会发生
发布于 2025年3月28日 15:29 UTC (周五)，作者 daroc (编辑, #160859) [链接]
理论上，编写执行此操作的工具绝对是可能的； 这只是让某人编写和维护它的问题。
这部分已经存在：前面提到的 crABI，它将允许复杂的 Rust 类型在共享库之间传递，以及像 cargo-semver-checks 这样的项目，它可以用来检查对库的更改是否意外地以向后不兼容的方式影响其公共 API。
Rust 的工具已经提供了一个非常好的用户界面，但我确实相信，如果有人愿意这样做，可以进行更多改进。
共享库可以而且可能会发生
发布于 2025年3月28日 15:48 UTC (周五)，作者 farnz (订阅者, #17727) [链接]
一旦您拥有可以指向的稳定 ABI，技术问题就相对容易解决。
更难的部分是社会问题； 有人必须承诺维护稳定的 ABI，并且您需要一些类似于 glibc 附带的 shims，这些 shims 允许链接到旧的、有 bug 版本的 glibc 的人获得他们期望的行为。
例如，glibc 有一个 shim，当人们要求 memcpy 时，会将链接到 2.13 或更早版本的人重定向到 memmove； 这是因为他们更改了 memcpy 的行为（保持在规范范围内），并破坏了 Adobe Flash Player。 通过将重定向 shim 放在适当的位置，依赖于与 2.13 或更早版本错误兼容的人获得了它，而针对较新 glibc 版本构建和测试的人可以看到新行为并修复它。
共享库可以而且可能会发生
发布于 2025年3月28日 17:35 UTC (周五)，作者 khim (订阅者, #9252) [链接]
如果您可以反向运行它并将其提供给编译器以说“这是我想要的定义”，您将获得稳定的 ABI。 这可能吗？
不可能，也没有计划使其成为可能。
当您编译调用该 crate 的程序时，当然您需要导入该 ABI 这正是问题所在：您当然可以导出这样的 ABI。 但是没有办法导入它。
一个版本的编译器产生的东西，另一个版本的编译器必须接受。 这不是技术问题，而是社会问题。
最简单但现实的例子：
#[repr(u8)]
enum Foo {
BAR = 1
}
这是最简单的 enum。 它只有一种可能的值：1。 我们甚至强制编码：它总是被编码为字节 1。 那么哪里可能出现不兼容？
简单: Rust 1.56.0 将 Option<Foo> 的 None 编码为 2，但 Rust 1.57.0 切换到更有效的 0。 没有提供任何产生旧行为的手段。
而且… 就是这样。 没有 Option 和 Result，惯用的 Rust 本质上是不可能的。 Option 和 Result 在 Rust API 中无处不在。
即使使用最简单、最原始的类型，您也无法支持它们。
到此为止。 故事结束。
为了使您所要求的事情可行，Rust 将不得不承担支持旧版本数据结构布局的负担。
Rust 编译器开发人员不想支持这一点。
但是考虑到 Rust 所做的其他“魔法”，这似乎并非不合理？ 作为“魔法”的一部分，您所要求的事情被认为不可行。 因为：明确拒绝和不支持。
crABI 试图提供一个可用数据结构的子集，其中为 Rust 的一些有用子集提供这种保证导出然后导入。 但它似乎陷入了停滞。
下一步：共享库？
发布于 2025年3月28日 7:28 UTC (周五)，作者 pabs (订阅者, #43278) [链接] (3 条回复)
Rust 有共享库，只是目前还没有稳定的 ABI。 在这方面取得了一些进展，但我最近没有看到任何进展。
https://wiki.debian.org/StaticLinking#Rust
下一步：共享库？
发布于 2025年3月28日 9:45 UTC (周五)，作者 xorxornop (订阅者, #176609) [链接] (2 条回复)
我所知道的最相关的工作是 crABI
下一步：共享库？
发布于 2025年3月29日 2:32 UTC (周六)，作者 pabs (订阅者, #43278) [链接] (1 条回复)
这听起来像是一种跨语言 ABI，而不是 Rust 本身的稳定 ABI？
https://github.com/rust-lang/compiler-team/issues/631
下一步：共享库？
发布于 2025年3月29日 4:38 UTC (周六)，作者 xorxornop (订阅者, #176609) [链接]
那是它的预期用途，但在定义共享库使用的通用 ABI 方面也同样有用，从而避免了必须降级到简单的 C ABI