dianne ed01a20514 typeck: catch continues pointing to blocks ... This taints the typeck results with errors if a `continue` is found not pointing to a loop, which fixes an ICE. A few things were going wrong here. First, since this wasn't caught in typeck, we'd end up building the THIR and then running liveness lints on ill-formed HIR. Since liveness assumes all `continue`s point to loops, it wasn't setting a live node for the `continue`'s destination. However, the fallback for this was faulty; it would create a new live node to represent the erroneous state after the analysis's RWU table had already been built. This would ICE if the new live node was used in operations, such as merging results from the arms of a match. I've removed this error-recovery since it was buggy, and we should really catch bad labels before liveness. I've also replaced an outdated comment about when liveness lints are run. At this point, I think the call to `check_liveness` could be moved elsewhere, but if it can be run when the typeck results are tainted by errors, it'll need some slight refactoring so it can bail out in that case. In lieu of that, I've added an assertion.		2025-05-20 17:45:16 -07:00
..
src	typeck: catch continues pointing to blocks	2025-05-20 17:45:16 -07:00
Cargo.toml	don't depend on rustc_attr_parsing if rustc_data_structures will do	2025-05-09 23:16:55 +02:00
messages.ftl	Initial support for dynamically linked crates	2025-05-04 22:03:15 +03:00