Skip to content

Fix nonsense non-tupled Fn trait error #99942

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged

Conversation

compiler-errors
Copy link
Member

@compiler-errors compiler-errors commented Jul 30, 2022

Given this code:

#![feature(unboxed_closures)]

fn a<F: Fn<usize>>(f: F) {}

fn main() {
    a(|_: usize| {});
}

We currently emit this error:

error[E0631]: type mismatch in closure arguments
 --> src/main.rs:6:5
  |
6 |     a(|_: usize| {});
  |     ^ ---------- found signature of `fn(usize) -> _`
  |     |
  |     expected signature of `fn(usize) -> _`
  |
note: required by a bound in `a`
 --> src/main.rs:3:9
  |
3 | fn a<F: Fn<usize>>(f: F) {}
  |         ^^^^^^^^^ required by this bound in `a`

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

Notably, it says the same thing for "expected" and "found"!

Fix the output so that we instead emit:

error[E0308]: mismatched types
 --> /home/gh-compiler-errors/test.rs:6:5
  |
6 |     a(|_: usize| {});
  |     ^ types differ
  |
  = note: expected trait `Fn<usize>`
             found trait `Fn<(usize,)>`
note: required by a bound in `a`
 --> /home/gh-compiler-errors/test.rs:3:9
  |
3 | fn a<F: Fn<usize>>(f: F) {}
  |         ^^^^^^^^^ required by this bound in `a`

error: aborting due to previous error

The error could still use some work, namely the "mismatched types" part, but I'm leaving it a bit rough since the only way you'd ever get this error is when you're messing with #![feature(unboxed_closures)].

Simply making sure we actually print out the difference in trait-refs is good enough for me. I could probably factor in some additional improvements if those are desired.

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jul 30, 2022
@rust-highfive
Copy link
Contributor

r? @cjgillot

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 30, 2022
@compiler-errors compiler-errors changed the title Nonsense un tupled fn trait error Fix nonsense non-tupled Fn trait error Jul 30, 2022
Copy link
Contributor

@cjgillot cjgillot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay @compiler-errors.
When we have Fn<A> with a concrete type A, we should probably report that a tuple is expected. The diagnostic improvement for generic A is great though.

@@ -0,0 +1,8 @@
#![feature(unboxed_closures)]

fn a<F: Fn<usize>>(f: F) {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we just report that a tuple is expected and bail out?

Copy link
Member Author

@compiler-errors compiler-errors Aug 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well making this a hard error in #99943, so I don't want to just introduce a special case error logic here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, reporting that a tuple is expected and bailing out is not gonna work when you have a generic Fn<T> where T is a type param.

_ => vec![ArgKind::empty()],
_ => {
not_tupled = true;
vec![ArgKind::empty()]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we keep a single ArgKind::empty(), like 1-tuples, instead of an empty vec?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No particular reason, I can fix that I guess.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I know why. This code also handles Generator<T> which takes a generic argument that isn't a tupled set of arguments.

@compiler-errors
Copy link
Member Author

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 10, 2022
@compiler-errors
Copy link
Member Author

I actually don't know if I have anything to change here. See replied comments.

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 14, 2022
@cjgillot
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented Aug 15, 2022

📌 Commit 9e52d22 has been approved by cjgillot

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 15, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Aug 15, 2022
…fn-trait-error, r=cjgillot

Fix nonsense non-tupled `Fn` trait error

Given this code:

```rust
#![feature(unboxed_closures)]

fn a<F: Fn<usize>>(f: F) {}

fn main() {
    a(|_: usize| {});
}
```

We currently emit this error:
```
error[E0631]: type mismatch in closure arguments
 --> src/main.rs:6:5
  |
6 |     a(|_: usize| {});
  |     ^ ---------- found signature of `fn(usize) -> _`
  |     |
  |     expected signature of `fn(usize) -> _`
  |
note: required by a bound in `a`
 --> src/main.rs:3:9
  |
3 | fn a<F: Fn<usize>>(f: F) {}
  |         ^^^^^^^^^ required by this bound in `a`

For more information about this error, try `rustc --explain E0631`.
error: could not compile `playground` due to previous error
```
Notably, it says the same thing for "expected" and "found"!

Fix the output so that we instead emit:
```
error[E0308]: mismatched types
 --> /home/gh-compiler-errors/test.rs:6:5
  |
6 |     a(|_: usize| {});
  |     ^ types differ
  |
  = note: expected trait `Fn<usize>`
             found trait `Fn<(usize,)>`
note: required by a bound in `a`
 --> /home/gh-compiler-errors/test.rs:3:9
  |
3 | fn a<F: Fn<usize>>(f: F) {}
  |         ^^^^^^^^^ required by this bound in `a`

error: aborting due to previous error
```

The error could still use some work, namely the "mismatched types" part, but I'm leaving it a bit rough since the only way you'd ever get this error is when you're messing with `#![feature(unboxed_closures)]`.

Simply making sure we actually print out the difference in trait-refs is good enough for me. I could probably factor in some additional improvements if those are desired.
@matthiaskrgr
Copy link
Member

@bors r-

     Checking rustc_session v0.0.0 (/checkout/compiler/rustc_session)
    Checking rustc_attr v0.0.0 (/checkout/compiler/rustc_attr)
    Checking rustc_query_system v0.0.0 (/checkout/compiler/rustc_query_system)
    Checking rustc_parse v0.0.0 (/checkout/compiler/rustc_parse)
    Checking rustc_middle v0.0.0 (/checkout/compiler/rustc_middle)
    Checking rustc_ast_passes v0.0.0 (/checkout/compiler/rustc_ast_passes)
    Checking rustc_expand v0.0.0 (/checkout/compiler/rustc_expand)
    Checking rustc_builtin_macros v0.0.0 (/checkout/compiler/rustc_builtin_macros)
error: passing `TypeError<'_>` by reference
  --> compiler/rustc_middle/src/ty/error.rs:78:29
   |
78 |     pub fn involves_regions(&self) -> bool {
   |                             ^^^^^ help: try passing by value: `TypeError<'_>`
   |
   = note: `-D rustc::pass-by-value` implied by `-D warnings`

error: could not compile `rustc_middle` due to previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `rustc_middle` due to previous error
Build completed unsuccessfully in 0:02:05

#100593 (comment)

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 15, 2022
@compiler-errors compiler-errors force-pushed the nonsense-un-tupled-fn-trait-error branch from 9e52d22 to 1c084f1 Compare August 16, 2022 02:43
@compiler-errors
Copy link
Member Author

@bors r=cjgillot

@bors
Copy link
Collaborator

bors commented Aug 16, 2022

📌 Commit 1c084f1 has been approved by cjgillot

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 16, 2022
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 16, 2022
Rollup of 6 pull requests

Successful merges:

 - rust-lang#99942 (Fix nonsense non-tupled `Fn` trait error)
 - rust-lang#100609 (Extend invalid floating point literal suffix suggestion)
 - rust-lang#100610 (Ast and parser tweaks)
 - rust-lang#100613 (compiletest: fix typo in runtest.rs)
 - rust-lang#100616 (:arrow_up: rust-analyzer)
 - rust-lang#100622 (Support 128-bit atomics on all aarch64 targets)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 070de4b into rust-lang:master Aug 16, 2022
@rustbot rustbot added this to the 1.65.0 milestone Aug 16, 2022
@compiler-errors compiler-errors deleted the nonsense-un-tupled-fn-trait-error branch August 11, 2023 20:11
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants