Repository navigation
Borrowchecker regression in 1.26 #49945
Description
- sorz/moproxy regressed from stable to beta (build log) cc @sorz
Activity
visiting for triage.
@pietroalbini are you in a position to narrow this into a stand-alone test case?
triage : P-high
are you in a position to narrow this into a stand-alone test case?
That was just from crater, I can try bisecting in a few hours though.
Didn't have time to investigate this in the past days, sorry! cc @nikomatsakis
OK, I see what is happening. Fascinating; I did not anticipate this side-effect of making closures implement
Copy. I think the problem is this:- Closures were never
Copybefore. - This code creates a closure
skip_headers - This closure is then used from another closure we'll call
skip;skipescapes from the fn.- In the olden days, because the closure was not copy, it was implicitly moved into
skip - But now, the closure is copy, and therefore it is taken by shared reference and copied out
- hence
skipmust be declared asmove
- hence
- In the olden days, because the closure was not copy, it was implicitly moved into
I guess this is "working as expected", but it's a surprise interaction I had not considered in advance. (More generally, it seems to suggest that making any struct
Copycould break closures down the line.)cc @rust-lang/lang
- Closures were never
Still, I don't think it's worth reverting the change, and we are certainly not going to change this aspect of closure upvar inference; if we did, then a TON of things would stop working (basically any
FnOncethat moves but is not declaredmove).Idea, discussed in gitter:
In the edition, if closures are not declared as
movebut reference non-zero upvars, then we could give them a phantom lifetime to prevent them from escaping the enclosing function. This would prevent the "semver-fail" that we observe here, where addingCopyto a type breaks consumers.Ping @nikomatsakis! We're approaching the release of 1.26, what should we do with this regression?
@pietroalbini I believe we are going to categorize this as "won't fix". The crate in question has already worked around it, in any case.
@nikomatsakis ok, closing this.
