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

Offen Anfängerfreundlich

#386 erstellt am 03.8.2026 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 2/5
Geschätzter Aufwand: 1-3 Stunden
Anfängerfreundlichkeit: 78/100

Issue-Typ: Bug
Klarheit: Klar beschrieben
Aktivitätsstatus: Ruhig
Tech-Stack: rust
Bereich: backend

Rechercherichtung

Beginne mit der DType-Konvertierung in src/core/util.rs:76-81 und vergleiche ihren akzeptierten Wertebereich mit dem Enum in src/core/defines.rs:112-139. Verfolge Array::get_type() in array.rs:427-432 und stelle sicher, dass S16, U16 und F16 nicht mehr paniken, auch nicht beim Debug-Formatieren eines Arrays; nicht erkannte Werte sollten zu einem eindeutigen Fehler führen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache: Rust
Sterne: 827
Forks: 59
PR-Merge-Kennzahlen: Keine gemergten PRs in 30 T.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Erste Schritte

Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
Forken Sie das Repository und arbeiten Sie in einem Branch.
Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus arrayfire/arrayfire-rust

[BUG] `af_set_backend` is declared with the wrong parameter width Offen

Bug

Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100

arrayfire/arrayfire-rust#388 · Erstellt am 03.8.2026
[BUG] `Array::get_backend()` can never return `OPENCL` Offen

Bug

Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100

arrayfire/arrayfire-rust#387 · Erstellt am 03.8.2026
[BUG] device_info() buffers are 64 bytes; CUDA backend writes 257, corrupting the stack Offen

Bug

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100

arrayfire/arrayfire-rust#384 · Erstellt am 03.8.2026
[BUG] Multiple soundness issues reachable from safe code Offen

Bug

Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100

arrayfire/arrayfire-rust#385 · 1 Kommentar · Erstellt am 03.8.2026
[BUG] opencl-interop `get_device_type` always returns `DeviceType::ALL` Offen

Bug

Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100

arrayfire/arrayfire-rust#382 · Erstellt am 27.1.2025

Alle Issues in arrayfire/arrayfire-rust