Provide suggestion on missing let in binding statement

[estebank]

Fix#78907.

Fallout from the type ascription syntax.

[rust-highfive]

r? @petrochenkov

(rust-highfive has picked a reviewer for you, use r? to override)

[estebank]

r? @compiler-errors

[compiler-errors]

Only side-effect is that now type ascription in LHS will fail during AST validation phase instead of later (I'm guessing AST lowering?). But that's fine, an error will be emitted regardless.

I wonder if we should just gate all type ascription behind a feature error during ast validation, but that might have some strange consequences on diagnostics.

@bors r+

[bors]

📌 Commit 939c2b6 has been approved by compiler-errors

It is now in the queue for this repository.

[estebank]

Only side-effect is that now type ascription in LHS will fail during AST validation phase instead of later (I'm guessing AST lowering?). But that's fine, an error will be emitted regardless.

This is already the case, in fn check_expr the same check already exists, this precludes it (due to the check for prior errors) by emitting earlier, while evaluating the statement.

I wonder if we should just gate all type ascription behind a feature error during ast validation, but that might have some strange consequences on diagnostics.

I've thought about doing so. The problem with doing that for features that affect the syntax is that then we'd never exercise those codepaths as much as we have these, which would make the stabilization process much more traumatic in the regressions caused. That being said, type ascription has no quick path to stabilization, so that's what we should have done back in 2015. Now, I feel we've sunk enough resources in handling most of these that I'm ok with it remaining as is (and even try to stabilize it!), but damn if I don't hate this syntax for its proximity to other valid syntax!.