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

Open Beginner friendly
#386 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
rust
Domain
backend

Research direction

Start with the DType conversion in src/core/util.rs:76-81 and compare its accepted range with the enum in src/core/defines.rs:112-139. Trace Array::get_type() in array.rs:427-432 and verify that S16, U16, and F16 no longer panic, including when Debug formatting an array; unrecognised values should have a clear failure.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Rust
Stars
827
Forks
59
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from arrayfire/arrayfire-rust

All issues in arrayfire/arrayfire-rust

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.