Don't feel like a secondary source is necessary here, see @kornel's post [1], the actual issue [2] and the related libs-team minutes [3] [4] for the direct context.<p>To be clear, not just Rust but virtually every upgrade has a potential to break <i>someone</i>'s code, so we are really talking about the higher-than-normal breakage ratio due to a particular popular crate being hit by this issue. In my understanding, such type inference failure is already described as an acceptable breakage per RFC 1122 [5] and this issue was deemed acceptable as such. After all, such breakage can be mechanically resolved with an additional annotation and `Cargo.lock` should be easy to update. But it is likely that any future PR with a potential type inference failure will require a mandatory crater run to gauge its actual impact.<p>[1] <a href="https://internals.rust-lang.org/t/type-inference-breakage-in-1-80-has-not-been-handled-well/21374" rel="nofollow">https://internals.rust-lang.org/t/type-inference-breakage-in...</a><p>[2] <a href="https://github.com/rust-lang/rust/issues/127343">https://github.com/rust-lang/rust/issues/127343</a><p>[3] <a href="https://hackmd.io/xS913qb6QFCGHrdHB0uhBw#nominated-rusttf127343-regression-type-annotations-needed-for-Boxlt_gt" rel="nofollow">https://hackmd.io/xS913qb6QFCGHrdHB0uhBw#nominated-rusttf127...</a><p>[4] <a href="https://hackmd.io/ROIVABA2QCOQSYFo9txhLw#nominated-rusttf125319-Type-inference-regression-on-nightly-2024-05-20" rel="nofollow">https://hackmd.io/ROIVABA2QCOQSYFo9txhLw#nominated-rusttf125...</a><p>[5] <a href="https://rust-lang.github.io/rfcs/1122-language-semver.html#underspecified-language-semantics" rel="nofollow">https://rust-lang.github.io/rfcs/1122-language-semver.html#u...</a>