Issue-125323: ICE non-ADT in struct pattern when long time constant evaluation is in for loop

[Shunpoco]

This PR fixes #125323

Context

According to the issue, the ICE happens since #121206.
In the PR, some error methods were reorganized. For example, has_errors() was renamed to has_errors_exclude_lint_errors(). However, some codes which used the original has_errors() were not switched to has_errors_exclude_lint_errors(). I finally found that report_error() in writeback.rs causes this ICE. Currently the method uses tainted_by_errors() to get guar (ErrorGuaranteed), but originally it used dcx().has_errors() but it wasn't changed to has_errors_exclude_lint_errors() when changes in #121206 were merged. I don't think I fully understand how an error is propagated, but I suppose that the error from long time constant evaluation is unexpectedly propagated other parts (in this ICE, for loop), then cause the non-ADT in struct pattern ICE.

Change

• Fix report_error() in writeback.rs: use dcx().has_errors_exclude_lint_errors() instead of tainted_by_errors() to prevent error propagation from constant evaluation.
• Add test for the ICE
• Modify some tests to align the change: Due to this fix, E0282 error happens (or not happen anymore) in some tests.

NOTE

The 4th commit aims to revert the fix in #123516 because I confirmed that the ICE solved by the PR doesn't happen if I modify report_error(). I think the root cause of that ICE is the same as #125323 . But I can discard this commit since we can fix #125323 without it.

[rustbot]

r? @estebank

rustbot has assigned @estebank.
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]

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

[compiler-errors]

I don't believe this is the right solution, because using tainted_by_errors in Resolver::report_error is intentional to make sure we don't have non-local dependence on error reporting.

The real root cause of this issue is this:

rust/compiler/rustc_interface/src/passes.rs

Lines 991 to 995 in 75530e9

	// But we exclude lint errors from this, because lint errors are typically
	// less serious and we're more likely to want to continue (#87337).
	if let Some(guar) = sess.dcx().has_errors_excluding_lint_errors() {
	guar.raise_fatal();
	}

...which causes us to enter check_mod_deathness if the only error that was reported was through the const eval lint. I think the code in compiler/rustc_passes/src/dead.rs should handle errors more gracefully, and not walk into modules if the body typeck results are tainted. But I'll pass this onto oli who can confirm my suspicions and guide this PR along, since they've been responsible for some of this error tainting and cleanup work.

r? oli-obk

[compiler-errors]

Please ensure that after this PR is fully reworked that it's squashed into a single commit.

[oli-obk]

Yea errs' analysis is spot on. Skipping the visit_body call if the typeck results are tainted in visit_nested_body would avoid any such ICEs. This would have the fun side effect of causing everything with errors to be marked as dead though, so we likely have to record that we didn't do the analysis properly. The easiest way to do that would be to make the Visitor::Result be an actual Result<(), ErrorGuaranteed> and recording that in the query result.

[Shunpoco]

Thanks both!

@oli-obk
I fixed my code in cd7a8f5.
There are two panics in the issue. Skipping visit_body solves the panic in dead.rs, but I also need to add early return in check_pat in builtin.rs.

The easiest way to do that would be to make the Visitor::Result be an actual Result<(), ErrorGuaranteed> and recording that in the query result.

Are you talking about ResultsVisitor in compiler/rustc_mir_dataflow/src/framework/visitor.rs? So far I don't understand how to record the error into the query result. It would be great if you give me a hint which code I should looking for

[meithecatte]

Does this fix #138361 as well? Seems like a very closely related issue, at the very least. Ideally we'd make sure that the approach taken will take care of both of these.

[Shunpoco]

@meithecatte
Sorry for the late reply!

I think the root cause is the same. I tried your issue's failure case with 3cf7d22, and the ICE didn't happen, although as we discussed above I can't use this commit as the solution.
But I think a solution of your issue may be similar with mine. I will check your issue as well.

@oli-obk @compiler-errors
How does the compiler make tainted_by_error? Is it possible to separate this function into two (tainted_by_error, and something like tainted_by_error_exclude_lint_error)?