Lint on (nearly) all `{integer}`/`{float}` fallback

[scottmcm]

Note: this is currently at the phase of a lang vibe check, not an approved proposal. I personally currently think I like it, but if you're interested in working on it beware that the answer might end up being "no, we don't want a lint for that".

The integer fallback to i32 and float fallback to f64 is very important for beginner friendliness. We absolutely want a simple thing like

println!("{}", 123.456);

or

for x in 0..10 {
    println!("{}", x);
}

to compile, because we don't want to add extra friction to the "my first rust program" examples.

That said, it's not obvious that fallback is what you want in "real" code, and you'd much prefer it be unified to something the vast majority of the time. Like for i in 0..10 { a[i] = 0; } ends up constrained by the indexing, and similar. And any time something is derived from an argument or returned that unifies the integer/float type as well.

See for example #139087 where there's no type to unify with, just a trait bound, and not having the type annotation causes evolution problems.

We'll probably find some examples where it turns out that we need to allow it -- maybe x << 4 for example will need to continue to allow fallback, for example, since it's a heterogeneous RHS -- but what would people think about this general direction?

(It feels like at very least it should exist for the "I'm a popular crate who really wants to make sure I'm not broken by updates to things" group we keep talking about.)

[joshtriplett]

General vibe: I think we need to do something here. It's not clear if it's this, exactly, but the concept seems reasonable. I do think that it'd be too restrictive as a general lint; I don't think we ever want to stop people from writing (for instance) just 0 or 1 or 2, in common contexts, even if those contexts are technically generic (e.g. x - 1 or x + 1, where there might be another trait impl).

I would broadly speaking hope for something closer to (eventually) replacing fallback with "special type for literals, used directly in trait impls, and with some mechanism for compile-time conversions", rather than "lint on most fallbacks".

[scottmcm]

From the lang discussion today:

• Tests are another case where this could be annoying. for _ in 0..100 is using fallback, but making people put a type on there would plausibly be annoying.
• This is very coupled to the one-impl rule in ways that we might not be happy about. If a BigInteger type has Add<iN> for all the integer types, linting on mybigint + 2 might be annoying.
• General cautious interest in seeing just how much stuff this would trigger on, but expecting it to be substantially high in practice.
• Musing on whether the lint could be smarter about uses in some way so that things like the unused loop counter wouldn't hit it. (Maybe it's only a problem if used in math or something? Though distinguishing that from Range would be hard.)
• Potential interest in having this allow-by-default for "persnickity" lints turned on by library crates wanting extra durability.