Mostly parser: Eliminate code that's been dead / semi-dead since the removal of type ascription syntax

[fmease]

Disclaimer: This PR is intended to mostly clean up code as opposed to bringing about behavioral changes. Therefore it doesn't aim to address any of the 'FIXME: remove after a month [dated: 2023-05-02]: "type ascription syntax has been removed, see issue [#]101728"'.

---

By commit:

1. Removes truly dead code:
   • Since 1.71 (Remove type ascription from parser and diagnostics #109128) let _ = { f: x }; is a syntax error as opposed to a semantic error which allows the parse-time diagnostic (suggestion) "struct literal body without path // you might have forgotten […]" to kick in.
   • The analysis-time diagnostic (suggestion) from <=1.70 "cannot find value `f` in this scope // you might have forgotten […]" is therefore no longer reachable.
2. Updates is_certainly_not_a_block to be in line with the current grammar:
   • The seq. { ident: is definitely not the start of a block. Before the removal of ty ascr, { ident: ty_start would begin a block expr.
   • This shouldn't make more code compile IINM, it should ultimately only affect diagnostics.
   • For example, if T { f: () } {} will now be interpreted as an if with struct lit T { f: () } as its condition (which is banned in the parser anyway) as opposed to just T (with the consequent being f : () which is also invalid (since 1.71)). The diagnostics are almost the same because we have two separate parse recovery procedures + diagnostics: StructLiteralNeedingParens (invalid struct lit) before and StructLiteralNotAllowedHere (struct lits aren't allowed here) now, as you can see from the diff.
   • (As an aside, even before this PR, fn maybe_suggest_struct_literal should've just used the much older & clearer StructLiteralNotAllowedHere)
   • NB: This does sadly regress the compiler output for tests/ui/parser/type-ascription-in-pattern.rs but that can be fixed in follow-up PRs. It's not super important IMO and a natural consequence.
3. Removes code that's become dead due to the prior commit.
   • Basically reverts Detect struct literal needing parentheses #106620 + Fix issue for module name when surround the struct literal with parentheses #112475 (without regressing rustc's output!).
   • Now the older & more robust parse recovery procedure (cc StructLiteralNotAllowedHere) takes care of the cases the removed code used to handle.
   • This automatically fixes the suggestions for [playground]:
     • if Ty::<i32> { f: K }.m() {}: if Ty::<i32> { SomeStruct { f: K } }.m() {} (broken) → if (Ty::<i32> { f: K }).m() {}
     • if <T as Trait>::Out { f: K::<> }.m() {}: if <T as Trait>(::Out { f: K::<> }).m() {} (broken) → if (<T as Trait>::Out { f: K::<> }).m() {}
4. Merge and simplify UI tests pertaining to this issue, so it's easier to add more regression tests like for the two cases mentioned above.
5. Merge UI tests and add the two regression tests.

Best reviewed commit by commit (on request I'll partially squash after approval).

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

[compiler-errors]

r=me, i don't think it needs squashing.

i somewhat think is_certainly_not_a_block should have some sort of prefix like _for_diagnostics to make it clear that it's not a guarantee, but also the way it's being used today is also not really "for diagnosics" either since it influences parsing without may_recover (but, i guess that's fine technically in this situation...)

[compiler-errors]

r? compiler-errors @bors r+

[bors]

📌 Commit d5585b3 has been approved by compiler-errors

It is now in the queue for this repository.

[fmease]

I've allowed myself to further simplify is_certainly_not_a_block and to fix a typo (diff). Sry

@bors r=compiler-errors

[bors]

📌 Commit b501e58 has been approved by compiler-errors

It is now in the queue for this repository.