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

Improve type mismatch w/ function signatures #99862

Merged
merged 2 commits into from
Jul 30, 2022

Conversation

WaffleLapkin
Copy link
Member

This PR makes use of note: expected/found (instead of labeling types in labels) in type mismatch with function signatures. Pros: it's easier to compare the signatures, cons: the error is a little more verbose now.

This is especially nice when

  • The signatures differ in a small subset of parameters (same parameters are elided)
  • The difference is in details, for example isize vs usize (there is a better chance that the types align)

Also this PR fixes the inconsistency in variable names in the edited code (expected and found).

A zulip thread from which this pr started: [link].

An example diagnostic:

this pr nightly
error[E0631]: type mismatch in function arguments
  --> ./t.rs:4:12
   |
4  |     expect(&f);
   |     ------ ^^ expected due to this
   |     |
   |     required by a bound introduced by this call
...
10 | fn f(_: isize, _: u8, _: Vec<u32>) {}
   | ---------------------------------- found signature defined here
   |
   = note: expected function signature `fn(usize, _, Vec<u64>) -> _`
              found function signature `fn(isize, _, Vec<u32>) -> _`
note: required because of the requirements on the impl of `Trait` for `fn(isize, u8, Vec<u32>) {f}`
  --> ./t.rs:8:9
   |
8  | impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}
   |         ^^^^^     ^
   = note: required for the cast from `fn(isize, u8, Vec<u32>) {f}` to the object type `dyn Trait`
error[E0631]: type mismatch in function arguments
  --> ./t.rs:4:12
   |
4  |     expect(&f);
   |     ------ ^^ expected signature of `fn(usize, u8, Vec<u64>) -> _`
   |     |
   |     required by a bound introduced by this call
...
10 | fn f(_: isize, _: u8, _: Vec<u32>) {}
   | ---------------------------------- found signature of `fn(isize, u8, Vec<u32>) -> _`
   |
note: required because of the requirements on the impl of `Trait` for `fn(isize, u8, Vec<u32>) {f}`
  --> ./t.rs:8:9
   |
8  | impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}
   |         ^^^^^     ^
   = note: required for the cast to the object type `dyn Trait`
code

fn main() {
    fn expect(_: &dyn Trait) {}

    expect(&f);
}

trait Trait {}
impl<F> Trait for F where F: Fn(usize, u8, Vec<u64>) -> u8 {}

fn f(_: isize, _: u8, _: Vec<u32>) {}

r? @compiler-errors

This also fixes the argument names in `report_closure_arg_mismatch`
(confusing expected/found)
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 28, 2022
@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jul 28, 2022
Copy link
Member Author

@WaffleLapkin WaffleLapkin left a comment

Choose a reason for hiding this comment

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

As usual I'm not sure about the wording, but other than that I think this is an improvement :")

Comment on lines +12 to 13
//~| NOTE: in this expansion of desugaring of `impl Trait`
//~| NOTE: in this expansion of desugaring of `impl Trait`
Copy link
Member Author

Choose a reason for hiding this comment

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

Not sure what's up with these notes, they don't even render in console...

@compiler-errors
Copy link
Member

compiler-errors commented Jul 28, 2022

@WaffleLapkin actually I do prefer mentioning "expected closure signature", since otherwise people may think we're comparing fn ptrs. Sorry for the back and forth 😿

r=me after reverting back to 7da578b

@bors delegate+

@bors
Copy link
Contributor

bors commented Jul 28, 2022

✌️ @WaffleLapkin can now approve this pull request

@WaffleLapkin
Copy link
Member Author

@bors r=compiler-errors

@bors
Copy link
Contributor

bors commented Jul 28, 2022

📌 Commit 7da578b has been approved by compiler-errors

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 Jul 28, 2022
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 30, 2022
Rollup of 5 pull requests

Successful merges:

 - rust-lang#99311 (change maybe_body_owned_by to take local def id)
 - rust-lang#99862 (Improve type mismatch w/ function signatures)
 - rust-lang#99895 (don't call type ascription "cast")
 - rust-lang#99900 (remove some manual hash stable impls)
 - rust-lang#99903 (Add diagnostic when using public instead of pub)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit eb378d2 into rust-lang:master Jul 30, 2022
@rustbot rustbot added this to the 1.64.0 milestone Jul 30, 2022
@WaffleLapkin WaffleLapkin deleted the type_mismatch_fix branch July 31, 2022 11:00
flip1995 pushed a commit to flip1995/rust that referenced this pull request Aug 11, 2022
Rollup of 5 pull requests

Successful merges:

 - rust-lang#99311 (change maybe_body_owned_by to take local def id)
 - rust-lang#99862 (Improve type mismatch w/ function signatures)
 - rust-lang#99895 (don't call type ascription "cast")
 - rust-lang#99900 (remove some manual hash stable impls)
 - rust-lang#99903 (Add diagnostic when using public instead of pub)

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
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.

5 participants