Raise MSRV to 1.64 and delegate `ctypes` type aliases to `core::ffi`

未关闭 适合新手
#188 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
72/100
Issue 类型
重构
描述清晰度
基本清楚
活跃度
冷清
技术栈
rust
领域
operating-systems

调研方向

从 Cargo.toml 中的 rust-version 设置和 src/lib.rs 中的 ctypes 类型别名模块开始。检查 Rust 1.64 的 core::ffi 类型和现有的目标条件，然后运行现有的测试套件。完成的标准是 MSRV 为 1.64，别名委托给 core::ffi，并且受支持的目标保持当前行为不变。

由索引模型根据 Issue 内容生成。

描述

Just sharing this observation despite the benefit likely being minimal. Delegating the C FFI type aliases to those from core::ffi by bumping rust-version to 1.64 seems desirable?

It'd have avoided the need for PRs like this in March 2026 for example (which is merged but still unreleased).

Details

Presently linux-raw-sys supports Rust 1.63 (Aug 2022) as a minimum (in May 2023 rust-version was bumped from 1.48 to benefit from improved const fn support):

https://github.com/sunfishcode/linux-raw-sys/blob/3b15c17f2688445cd3e9ef2907113829837773dd/Cargo.toml#L13

In Nov 2021 linux-raw-sys switched from a cty crate dep to vendoring it's own ctypes type alias module, which presently has required a bit of maintenance support over the past year for Tier 3 targets with ensuring the correct c_char (m68k, hexagon (as a follow-up to restoring support), MIPS R6).

Since Rust 1.64 (Sep 2022) the equivalent FFI C types have been available via the core crate (the target list is managed by a cfg_select! macro, and prior to that the cfg_if! crate macro).

Although this comment says core was not available for a m68k target? (unless they used rustc_codegen_gcc) but as core is already used elsewhere in this crate I assume that wouldn't equate to a regression 😅

主要语言
Rust
星标
71
派生
63
30 天内没有已合并 PR

贡献指南

这个仓库没有索引到贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

sunfishcode/linux-raw-sys 的其他 Issue

查看 sunfishcode/linux-raw-sys 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。