Borrowchecker regression in 1.26

[pietroalbini]

• sorz/moproxy regressed from stable to beta (build log) cc @sorz

[pietroalbini]

cc @nikomatsakis

[pnkfelix]

visiting for triage.

@pietroalbini are you in a position to narrow this into a stand-alone test case?

[pnkfelix]

triage : P-high

[pietroalbini]

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.

[pietroalbini]

@pnkfelix the bisect run points inside of the rollup #49337, and #49299 (edit: wrong copy/paste!) is the one that makes more sense (since the issue affects closures). I'll try investigating more later today.

[pietroalbini]

Didn't have time to investigate this in the past days, sorry! cc @nikomatsakis

[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 Copy before.
• This code creates a closure skip_headers
• This closure is then used from another closure we'll call skip; skip escapes 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 skip must be declared as move

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 Copy could break closures down the line.)

cc @rust-lang/lang

[nikomatsakis]

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 FnOnce that moves but is not declared move).

[nikomatsakis]

Idea, discussed in gitter:

In the edition, if closures are not declared as move but 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 adding Copy to a type breaks consumers.

[pietroalbini]

Ping @nikomatsakis! We're approaching the release of 1.26, what should we do with this regression?

[nikomatsakis]

@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.

[pietroalbini]

@nikomatsakis ok, closing this.