-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support coercion between (FnDef | Closure) and (FnDef | Closure) #71599
Conversation
r? @cramertj (rust_highfive has picked a reviewer for you, use r? to override) |
r? @eddyb |
Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Hmm, so, let me double check my understanding here. The current rule for closures is:
But we are trying to extend that rule to permit coercions in other cases as well? (i.e., not just based on the expected type)? |
@nikomatsakis Yes, that's currently how it works and what this PR is going to achieve. The Closure and FnDef are pretty similar and I think this extended rule respects the RFC 1558 (tracking issue: #39817). One thing I forget to add is the non-capturing closure restriction. I'm working on it. |
Non-capturing closure restriction added. |
Found this also fixes #48109, check-pass test added. |
Side note that this PR reminded me that I think we ought to improve our diagnostics here, so I filed #71895. |
Nominating for discussion in the @rust-lang/lang meeting -- this PR is proposing an extension to our rules around closure capture and coercion. It is probably a good change, but I thought I would raise it so we can discuss briefly. |
… Closure is non-capturing
We discussed this in our rust-lang meeting and the consensus was that extending coercions for non-capturing closures to occur in other contexts was pretty reasonable. |
I guess this is more or less ready to land. I'm wondering whether we need to update the rust reference, but I guess its coverage of coercions is insufficiently detailed at the moment to really make that make sense. |
@nikomatsakis I think we need it. So I filed a PR for it. rust-lang/reference#808. But sadly the RFC 401 seems to be ignoring the LUB coercion. So I haven't seen any regulation on it. |
@ldm0 yeah, I don't think it was an RFC'd change. |
@bors r+ |
📌 Commit 42396b1 has been approved by |
Support coercion between (FnDef | Closure) and (FnDef | Closure) Fixes rust-lang#46742, fixes rust-lang#48109 Inject `Closure` into the `FnDef x FnDef` coercion special case, which makes coercion of `(FnDef | Closure) x (FnDef | Closure)` possible, where closures should be **non-capturing**.
Rollup of 5 pull requests Successful merges: - rust-lang#71599 (Support coercion between (FnDef | Closure) and (FnDef | Closure)) - rust-lang#71973 (Lazy normalization of constants (Reprise)) - rust-lang#72283 (Drop Elaboration Elaboration) - rust-lang#72290 (Add newer rust versions to linker-plugin-lto.md) - rust-lang#72318 (Add help text for remote-test-client) Failed merges: r? @ghost
Fixes #46742, fixes #48109
Inject
Closure
into theFnDef x FnDef
coercion special case, which makes coercion of(FnDef | Closure) x (FnDef | Closure)
possible, where closures should be non-capturing.