43d44fff75
Completes issue 0095 (attempt 2). The attempt-1 coerce arm only caught a direct `const_float` literal, so a non-integral const-folded float EXPRESSION still truncated silently at a typed local / field default / param default: M :: 2; local : s64 = M + 0.5; // → 2 (silent truncation — BUG; now ERRORS) fld : s64 = M + 0.5; // field default — same take(x : s64 = M + 0.5) // param default — same while the typed-CONST site already errored. The integral expression (`M + 2.0` → 4) folded but the runtime/explicit-cast paths must stay untouched. Fix: - New `program_index.evalConstFloatExpr` — the f64 counterpart to `evalConstIntExpr`, delegating every integer subtree back to it (no parallel integer logic) and adding only the float literal / unary-negate / `+ - * /` arms. Pure (no diagnostics, no resolution side effects). - `Lowering.foldComptimeFloatInit` applies the unified rule to a typed-binding initializer EXPRESSION: an integral comptime float folds to its `constInt`, a non-integral one errors, a genuine runtime float / `xx`-cast falls through to the normal path. It runs `evalConstFloatExpr` FIRST (pure) so a `$pack[i]` argument is never spuriously type-resolved outside an active binding, then gates on `isFloat(inferExprType)` so a plain comptime int is left alone. Wired into the typed-local path, the three struct field-default sites (via a shared `lowerCoercedDefault`), and the call-argument loop (covers expanded param defaults). - One `Lowering.diagNonIntegralNarrow` now emits the narrowing wording at all five sites (coerce arm, global init, const-expr value, the typed-binding sites, and the typed-const path). The typed-CONST non-integral diagnostic therefore reads "cannot implicitly narrow non-integral float …" instead of the stale "initializer is a float literal / floating-point expression". Tests: examples/1146 (negative) extended with non-integral const-EXPRESSION cases at local/field/param; examples/0168 (positive) extended with integral const-EXPRESSION folds and `xx (M + 0.5)` truncation; examples/1143 reconciled to the aligned const message (G/BAD/BAD2 stay errors); unit test `evalConstFloatExpr folds comptime float expressions`. Full gate green (447).
36 lines
1.7 KiB
Plaintext
36 lines
1.7 KiB
Plaintext
// Unified float→int narrowing rule (F0.11), NEGATIVE side: a NON-INTEGRAL float
|
|
// implicitly narrowing to an integer-typed binding is a COMPILE ERROR — not a
|
|
// silent truncation. The rule fires at a typed LOCAL initializer, a function
|
|
// PARAM default, and a struct FIELD default; each emits a narrowing diagnostic
|
|
// at the offending float and aborts (exit 1). It fires whether the float is a
|
|
// LITERAL (`1.5`) or a compile-time const EXPRESSION (`M + 0.5`) — the latter is
|
|
// the core of issue 0095, which previously slipped through and truncated to 2.
|
|
// The fix is the integral-fold / non-integral-error rule shared with the
|
|
// array-dimension path.
|
|
//
|
|
// The escape hatch stays open: `y : s64 = xx 1.5` (or `cast(s64) 1.5`)
|
|
// truncates with no error — exercised on the POSITIVE side (example 0168).
|
|
//
|
|
// Regression (issue 0095): `y : s64 = 1.5` silently truncated to 1, and
|
|
// `y : s64 = M + 0.5` silently truncated to 2.
|
|
#import "modules/std.sx";
|
|
|
|
M :: 2; // module const, for the const-EXPRESSION cases
|
|
|
|
Bad :: struct {
|
|
f : s64 = 3.5; // non-integral float LITERAL field default → error
|
|
fe : s64 = M + 0.5; // non-integral const-EXPRESSION field default → error
|
|
}
|
|
|
|
badLit :: (x : s64 = 2.5) -> s64 { return x; } // non-integral LITERAL param default → error
|
|
badExpr :: (x : s64 = M + 0.5) -> s64 { return x; } // non-integral const-EXPR param default → error
|
|
|
|
main :: () {
|
|
y : s64 = 1.5; // non-integral float LITERAL local → error
|
|
ye : s64 = M + 0.5; // non-integral const-EXPRESSION local → error
|
|
b := Bad.{};
|
|
print("{} {}\n", b.f, b.fe);
|
|
print("{} {}\n", badLit(), badExpr());
|
|
print("{} {}\n", y, ye);
|
|
}
|