Rust 自动修复生成 20._f32 并报 E0610，补齐小数位再指定类型

给接受 Into<f32> 的函数传入 20.，代码可能先出现 float_literal_f32_fallback 警告。照着建议补上类型，或执行自动修复后，结果却变成 20._f32，接着报 E0610：整数没有字段。此时要检查改动后的字面量，别把错误归到函数的 trait 实现上。

Rust 1.97.1 的一个 Linux x86_64 报告用下面的代码触发了这一问题：

fn with_weight(_: impl Into<f32>) {}

fn main() {
    with_weight(20.);
}

警告想让调用者明确选择 f32，但受影响的建议把 _f32 接在了末尾句点后面。20._f32 并不是合法的浮点类型后缀写法；编译器把它理解为对整数 20 访问名为 _f32 的字段，于是新错误指向句点后的位置。自动修复输出里还可能提示使用 --broken-code，强行接受这段改动并不能使语法有效。

先手动把值写完整，再明确类型：

fn with_weight(_: impl Into<f32>) {}

fn main() {
    with_weight(20.0_f32);
}

20.0f32 也是可以使用的写法。若这个值在多个地方复用，可以先声明 let weight: f32 = 20.0;，再传入 weight。这里修正的是数值字面量与类型后缀，没必要为此给函数添加另一个 From 实现，也不需要把整个调用链改成 f64。

Into<f32> 的泛型参数与直接接收 f32 的参数不完全一样。不要把“浮点字面量通常默认成 f64”理解成任何位置都能任意转换到 f32；从 f64 到 f32 还涉及精度变化。应当按函数真正要求的类型写入这个常量，而不是对来源不明的表达式机械追加 as f32。如果修正字面量以后仍报 trait bound 错误，继续检查传入变量的真实类型，那已经是另一个诊断分支。

Rust 1.99.0 的正式源码包含了末尾句点的处理：生成建议前去掉这个多余的点，再拼接显式类型。相应回归样例将 0. 的建议写成 0_f32。这说明 0_f32 也可表示带 f32 类型的数值，不能看到它没有小数点就再改回错误的 0._f32。这里不据此推断所有早期版本都受影响，也不把 1.99.0 称为首次修复版本。

验收时先检查 Git diff，确认实际改动是 20.0_f32、20.0f32 或其他合法的明确类型写法，再运行项目原来的 cargo check。若还有自动修复步骤，先在可查看差异的工作区执行，检查生成代码后再次编译。最小样例通过后仍要检查真实调用位置；这项处理只针对末尾句点的字面量建议，不保证其他自动修复失败、类型转换或数值精度问题一并解决。