Skip to content
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

Nonsensical diagnostic when returning closure #89620

Open
danielkeller opened this issue Oct 7, 2021 · 4 comments
Open

Nonsensical diagnostic when returning closure #89620

danielkeller opened this issue Oct 7, 2021 · 4 comments
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-impl-trait Area: impl Trait. Universally / existentially quantified anonymous types with static dispatch. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@danielkeller
Copy link

Given the following code:

fn bar<Input>() -> impl Fn(Input) {
    |i| todo!()
}
    
fn foo() -> impl Fn(&str) {
    bar()
}

The current output is:

error[E0308]: mismatched types
 --> src/lib.rs:5:13
  |
1 | fn bar<Input>() -> impl Fn(Input) {
  |                    --------------
  |                    |
  |                    the expected opaque type
  |                    the found opaque type
...
5 | fn foo() -> impl Fn(&str) {
  |             ^^^^^^^^^^^^^ one type is more general than the other
  |
  = note: expected associated type `<impl Fn<(&str,)> as FnOnce<(&str,)>>::Output`
             found associated type `<impl Fn<(&str,)> as FnOnce<(&str,)>>::Output`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `playground` due to previous error

It seems like a bug that the "expected" and "found" types are the same.

@danielkeller danielkeller added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 7, 2021
@lqd
Copy link
Member

lqd commented Oct 7, 2021

Note that these impl Fns, and the others in https://internals.rust-lang.org/t/nonsensical-error-message-about-mismatched-types/15422, will unfortunately trigger #57374 with NLLs turned on.

@bjorn3
Copy link
Member

bjorn3 commented Oct 7, 2021

With the nightly only -Zverbose the output is:

error[E0308]: mismatched types
 --> <anon>:5:13
  |
1 | fn bar<Input>() -> impl Fn(Input) {
  |                    --------------
  |                    |
  |                    the expected opaque type
  |                    the found opaque type
...
5 | fn foo() -> impl Fn(&str) {
  |             ^^^^^^^^^^^^^ one type is more general than the other
  |
  = note: expected associated type `<Opaque(DefId(0:5 ~ rust_out[8787]::bar::{opaque#0}), [&'_#0r str]) as FnOnce<(&'_#0r str,)>>::Output`
             found associated type `<Opaque(DefId(0:5 ~ rust_out[8787]::bar::{opaque#0}), [&'_#0r str]) as FnOnce<(&RePlaceholder(Placeholder { universe: U3, name: BrAnon(0) }) str,)>>::Output`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.

@estebank
Copy link
Contributor

estebank commented Oct 7, 2021

CC @oli-obk, who has a couple of PRs in flight that will likely affect the output of this code.

@oli-obk
Copy link
Contributor

oli-obk commented Oct 7, 2021

there may be an easy fix in old regionck, as we should be able to normalize the placeholder lifetime back to the higher kinded lifetime that it came from (even if just for diagnostics).

But our efforts are probably better spent in fixing nll error once I get through all this.

@oli-obk oli-obk self-assigned this Oct 7, 2021
@oli-obk oli-obk added the A-impl-trait Area: impl Trait. Universally / existentially quantified anonymous types with static dispatch. label Oct 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-impl-trait Area: impl Trait. Universally / existentially quantified anonymous types with static dispatch. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants