[BUG] `DType::from` rejects `S16`, `U16` and `F16`

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

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
78/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
冷清
技术栈
rust
领域
backend

调研方向

从 src/core/util.rs:76-81 中的 DType 转换开始，将其接受范围与 src/core/defines.rs:112-139 中的 enum 进行比较。跟踪 array.rs:427-432 中的 Array::get_type()，并验证 S16、U16 和 F16 不再触发 panic，包括对数组进行 Debug 格式化时；无法识别的值应产生明确的错误。

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

描述

Bug

src/core/util.rs:76-81:

impl From<u32> for DType {
    fn from(t: u32) -> Self {
        assert!(DType::F32 as u32 <= t && t <= DType::U64 as u32);
        unsafe { mem::transmute(t) }
    }
}

The upper bound is DType::U64, which is 9. But the enum continues past it (src/core/defines.rs:112-139):

    U64 = 9,
    S16 = 10,
    U16 = 11,
    F16 = 12,

So the assert fires for three of the crate's own supported types. Array::get_type() (array.rs:427-432) is the caller, which means:

let a = randu::<half::f16>(dim4!(3, 3));
let t = a.get_type();     // panics
println!("{:?}", a);      // panics — Debug impl calls get_type()

This is not a version-skew problem — it's wrong against a correct 3.8 library, and has been since f16 support was added. It's also the inverse mistake to the one in AfError::from: that assert is too loose, this one is too tight.

Fix: bound at DType::F16 as u32, or better, use an exhaustive match with a clear error for unrecognised values. Note ArrayFire 3.10 adds s8 = 13, so a match would future-proof this.

Found by Claude Opus 5. Verified manually.

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

贡献指南

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

从这里开始

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

arrayfire/arrayfire-rust 的其他 Issue

查看 arrayfire/arrayfire-rust 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

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