Fix non-capturing closure return type coercion #88147
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @cjgillot (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
inquisitivecrystal
added
the
T-compiler
|
r? @jackh726 |
|
So, this is certainly a fix. But I have to think a little harder on the subtlety of this error. Specifically, I would expect that the check if the two types are equal to be an optimization and this could fail in other cases still. Regardless, in the meantime, can you add a comment? |
Sure, where and about what exactly? A reference to #88097 and/or this PR? |
jackh726
reviewed
Aug 31, 2021
| @@ -941,6 +941,10 @@ impl<'a, 'tcx> FnCtxt<'a, 'tcx> { | |||
| exprs.len() | |||
| ); | |||
|
|
|||
| if prev_ty == new_ty { | |||
There was a problem hiding this comment.
Comment here referencing #88097 and coercion of a closure to itself
There was a problem hiding this comment.
Got it; fixed now.
|
Thanks, I'll try to get back to this soon and think more about this in depth. |
|
I'm not 100% sure this is the only way to do this, but it's a very reasonable change, so I'm going to go ahead and @bors r+ rollup |
|
📌 Commit bbe3be9 has been approved by |
bors
added
S-waiting-on-bors
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Sep 11, 2021
Fix non-capturing closure return type coercion Fixes rust-lang#88097. For the example given there: ```rust fn peculiar() -> impl Fn(u8) -> u8 { return |x| x + 1 } ``` which incorrectly reports an error, I noticed something weird in the debug log: ``` DEBUG rustc_typeck::check::coercion coercion::try_find_coercion_lub([[email protected]:2:12: 2:21], [[email protected]:2:12: 2:21], exprs=1 exprs) ``` Apparently, `try_find_coercion_lub()` thinks that the LUB for two closure types always has to be a function pointer (which explains the `expected closure, found fn pointer` error in rust-lang#88097). There is one corner case where that isn't true, though — namely, when the two closure types are equal, in which case the trivial LUB is the type itself. This PR fixes this by inserting an explicit check for type equality in `try_find_coercion_lub()`.
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Sep 11, 2021
Fix non-capturing closure return type coercion Fixes rust-lang#88097. For the example given there: ```rust fn peculiar() -> impl Fn(u8) -> u8 { return |x| x + 1 } ``` which incorrectly reports an error, I noticed something weird in the debug log: ``` DEBUG rustc_typeck::check::coercion coercion::try_find_coercion_lub([[email protected]:2:12: 2:21], [[email protected]:2:12: 2:21], exprs=1 exprs) ``` Apparently, `try_find_coercion_lub()` thinks that the LUB for two closure types always has to be a function pointer (which explains the `expected closure, found fn pointer` error in rust-lang#88097). There is one corner case where that isn't true, though — namely, when the two closure types are equal, in which case the trivial LUB is the type itself. This PR fixes this by inserting an explicit check for type equality in `try_find_coercion_lub()`.
This was referenced Sep 11, 2021
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 11, 2021
…ingjubilee Rollup of 10 pull requests Successful merges: - rust-lang#87904 (Reword description of automatic impls of `Unsize`.) - rust-lang#88147 (Fix non-capturing closure return type coercion) - rust-lang#88209 (Improve error message when _ is used for in/inout asm operands) - rust-lang#88668 (Change more x64 size checks to not apply to x32.) - rust-lang#88733 (Fix ICE for functions with more than 65535 arguments) - rust-lang#88757 (Suggest wapping expr in parentheses on invalid unary negation) - rust-lang#88779 (Use more accurate spans for "unused delimiter" lint) - rust-lang#88830 (Add help for E0463) - rust-lang#88849 (don't clone types that are Copy (clippy::clone_on_copy)) - rust-lang#88850 (don't convert types into identical types) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #88097. For the example given there:
which incorrectly reports an error, I noticed something weird in the debug log:
Apparently,
try_find_coercion_lub()thinks that the LUB for two closure types always has to be a function pointer (which explains theexpected closure, found fn pointererror in #88097). There is one corner case where that isn't true, though — namely, when the two closure types are equal, in which case the trivial LUB is the type itself. This PR fixes this by inserting an explicit check for type equality intry_find_coercion_lub().