This change in 1.46 has broken my builds, both my personal projects as well as some work projects at Cloudflare: https://github.com/rust-lang/rust/pull/75443
I'm concerned that the fix for this issue is not planned to land in 1.47: https://github.com/rust-lang/rust/pull/72412
That would force me to skip two full releases of Rust, which is an unprecedented level of breakage.
If I am seeing this correctly, there was a beta-backport for the fix of the mentioned pr 71412 in this pr https://github.com/rust-lang/rust/pull/77490. So the fix should be in 1.47.
Oh, the backport was done after the start of this thread. Should have looked more closely at the timestamps.
Please consider testing your code on the beta channel. 1.46.0 has been released over a month ago, and 1.47.0 will come out in 5 days. It would help to know about the impact of these bugs earlier.
@jschievink to be fair to @kornel here:
The linked fix PR for the issue was originally opened May 20th, and beta nominated and (master) landed September 18th. It was declined for backport on September 24th, and @kornel asked for the beta backport decision to be reconsidered on October 1st. After little/no more discussion on the issue, @kornel brought up the issue here to bring more attention to it (which appears to have prompted @Mark_Simulacrum to formally renominate the patch and provisionally accept it for backport).
Or in other words, the impact was known. The fix was considered for beta backport (because it's known as fixing a regression) but was (wrongly?) rejected temporarily (due to patch size and a slight miscommunication about the scope of the issue, it seems?), and this post was to bring more attention back to the need for a backport.
(It's also worth noting that the issue was introduced into 1.46 by a backport as well.)
(Note: some dates may be off by one due to fencepost errors where GitHub is just giving "N days ago" rather than saying the actual date.)
(on desktop you can mouse over "N days ago" to get the actual datetime)
Yes, due to nested async fn (#75992). The symptom is exponential type name growth, which makes Rust ask for absurdly large type name length limit (350M-long in my case) and causes seemingly infinite compilation times.
1.45, despite having the root cause of this issue, did not hit the problem for my codebases. Only another change that landed in 1.46 made the problem apparent (bisect pointed to #75443).
I saw @Mark_Simulacrum merged the fix in beta. That addresses my concern. Thank you!
Note that in Exponential compile-time and type_length_limit blowup when nesting closure wrappers · Issue #54540 · rust-lang/rust · GitHub, it was reported on August 20 that there was a regression with the type length limit on beta, and I chimed in there on August 23rd that we had a similar issue in Quinn. These reports did not prevent the issue from being released in 1.46 on August 27th.
Which is to say: I was/am testing on beta, yet it did not prevent this issue from being solved in the stable release. What should I have done differently? It doesn't seem like filing duplicate issues would be an improvement.
This is the first time I saw that issue, and I was the one triaging the regressions right before the 1.46 release. I think what went wrong there is the issue didn't have the "regression-from-stable-to-beta" (or well, any regression- label), so the release team didn't know it was actually a regression. The fact it was reported on an old issue didn't help either.
The best way to ensure the release team knows about a regression is to apply the "regression-from-stable-to-beta" label, and if that doesn't get attention ping the person driving the release (either me or @Mark_Simulacrum, depending on the release). That's not really easy though, as you need to either have access to the repo (to apply the regression label) or know who to ping.
I'm not sure how to make the process more streamlined though, any suggestion?
I would appreciate if there was a better way to apply these labels (like e.g. regression or unsound) other than just waiting and hoping for others to do it. If there is a strong reason for not simply allowing everyone to apply those through rustbot, then perhaps a way to request these labels would be nice. Especially annoying are the rustbot error messages that you get when you first find out that those labels cannot be applied through rustbot. Those can spam a thread quite a lot.
I would be very happy if a straightforward @rustbot modify labels +regression-from-stable-to-beta would trigger some kind of label request in a way that notifies someone with the right to apply the label or reject the request (or if we want a different command then rustsbot should teach us about it in its error message). And rustbots error messages should go away after some time, especially if the comment containing the command gets edited or removed.
I want to second everything Stefan said.
In addition, longer term I'd love tooling that allows for people to catch issues like this more generally with some sort of bisect support. In @kornel's case he had the commit hash. If we had some sort of tooling then a bot could tag things automatically from the output of the tooling users could include in the ticket.
This is being added: https://github.com/rust-lang/rust/pull/77555
That looks great! Maybe it would be worth it doing an Inside Rust blog post that details how this is supposed to be used, potentially with more context about how beta regression triage works/is supposed to work? Since this functionality is probably not that easy to discover, would be good to raise awareness so that people such as myself know what to do when finding regressions.
The blog post is live: https://blog.rust-lang.org/2020/10/20/regression-labels.html
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.