Hide type errors likely caused by incorrect struct literal

[estebank]

When encountering a parse error that could be a struct literal, but that we can't be certain, keep the found span around until we find a type error that confirms it, provide the appropriate suggestion to surround with braces and hide every type error and non-found ident error coming from within the likely struct literal's span.

r? @petrochenkov

Follow up to #59981

[rust-timer]

Success: Queued 392a7be89b77c187cb74e1b6f29d6b81d9540093 with parent 8aaae42, comparison URL.

[petrochenkov]

I wouldn't do this personally, too many hacks for covering one specific case.
(Any extra code is a burden that hinders learning and refactorings, in general.)

cc @rust-lang/compiler

[nikomatsakis]

I think I agree with @petrochenkov that this PR is going to impose a difficult maintenance burden -- the reason is that it seems quite "non-local" in the way that it communicates information (also, adding shared mutable state will generally interfere with incremental and parallelization efforts, even if it is using a lock).

However, I am generally in favor of us trying to get more sophisticated in the way that we suppress downstream errors -- but I think we should be careful in how we engineer it.

[petrochenkov]

However, I am generally in favor of us trying to get more sophisticated in the way that we suppress downstream errors

We have a number of generic tools for doing that - Expr::Err/Ty::Err at parsing stage, Def::Err at resolution stage, ty::Err in type checking.
This case is tricky because we need to silence further errors not in the node that produced the initial error, but in some other code in proximity of it.

[nikomatsakis]

Right.

[petrochenkov]

Perhaps we need a generic NodeId poisoning.
All nodes poisoned before lowering to HIR will be lowered into Errs.
Or something like that.