Avoid double rounding decimal literals when materializing f32 values

Đang mở
  • Có gì không ổn?
#939 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
20/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
compilers

Hướng nghiên cứu

Read the literal path through front/lexer/src/scan.rs:470, front/parser/src/expr/primary.rs:349, and front/hir/src/numeric_checks.rs:57 to see where decimal source information is lost before f32 materialization. Discuss the design with @LunaStev before implementation. Reproduce the given program at O0 and O2, then use exact-oracle tests for midpoints, adjacent decimals, negative values, and finite range boundaries; done means the reproduction yields 0x3f800001 while casts, spans, and diagnostics retain their stated semantics.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug help wanted

Problem

Decimal floating literals are first converted to f64 in the lexer, then narrowed when Typed HIR selects f32. Near an f32 halfway point, rounding to f64 first can erase which side of the midpoint the original decimal occupied, producing the wrong nearest f32 value.

Starting points: front/lexer/src/scan.rs:470, front/parser/src/expr/primary.rs:349, and front/hir/src/numeric_checks.rs:57. This differs from #927's accepted f32 default and normal finite rounding: the example is rounded to the wrong f32 neighbor even with an explicit f32 declaration.

Reproduction

Audited canonical master d59bdab376bdc04edacdc8029b256cb8d55b5adf on Linux amd64 with a checkout-built Wave 0.0.1-alpha-dev, Rust 1.89.0 and LLVM 21.1.8.

import("std::math::float")::{float_to_bits_f32};
fun main() {
    var value: f32 = 1.0000000596046448;
    println("{}", float_to_bits_f32(value));
}

At both O0 and O2 the native program prints 1065353216 (0x3f800000, exactly 1.0).

The exact midpoint between 1.0 and its next f32 neighbor is 1 + 2^-24 = 1.000000059604644775390625. The source decimal 1.0000000596046448 is strictly greater than that midpoint, so its nearest f32 is the next neighbor: bits 1065353217 / 0x3f800001.

The midpoint comparison was checked using Python Decimal with precision 80; it does not use another f64 conversion as the oracle.

Scope

Preserve sufficient source information until the selected floating materialization width is known, and round the literal to that width correctly. Keep f32 as the untyped default, contextual f64 behavior, explicit conversion order, signed zero, underflow and overflow diagnostics. Do not reinterpret this as a request to reject all inexact decimals.

Please mention @LunaStev to discuss the design before starting implementation.

This touches the frontend literal representation shared by both backends, so it is not labeled a good first issue.

Completion criteria

  • The reproduction yields 0x3f800001 at O0/O2.
  • Test exact midpoints, decimal values immediately on either side, negative values and finite range boundaries with an exact oracle.
  • Preserve source spans and explicit f64-to-f32 cast semantics; distinguish directly materialized f32 literals from intentionally rounded cast chains.
Ngôn ngữ chính
Rust
Star
56
Fork
21
Merge trung bình
23 giờ 20 phút
Pull request đã merge (30 ngày)
45

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của wavefnd/Wave

Tất cả issue của wavefnd/Wave

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.