Avoid double rounding decimal literals when materializing f32 values

Abierto
  • ¿Algo no está bien?
#939 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
compilers

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Rust
Estrellas
56
Forks
21
Merge medio
23 h 20 min
PR fusionados (30 d)
45

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de wavefnd/Wave

Todos los issues de wavefnd/Wave

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.