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

Fix nonsense non-tupled Fn trait error #99942

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
Collaborator

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
Contributor

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
Contributor

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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