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.
To be clear, not just Rust but virtually every upgrade has a potential to break someone'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.
To be clear, not just Rust but virtually every upgrade has a potential to break someone'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.
[1] https://internals.rust-lang.org/t/type-inference-breakage-in...
[2] https://github.com/rust-lang/rust/issues/127343
[3] https://hackmd.io/xS913qb6QFCGHrdHB0uhBw#nominated-rusttf127...
[4] https://hackmd.io/ROIVABA2QCOQSYFo9txhLw#nominated-rusttf125...
[5] https://rust-lang.github.io/rfcs/1122-language-semver.html#u...