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

Give better error messages when calling overloaded function with invalid types #672

Closed
JukkaL opened this issue May 14, 2015 · 4 comments
Closed

Comments

@JukkaL
Copy link
Collaborator

JukkaL commented May 14, 2015

Currently when calling an overloaded function, the error message is something like No overload variant of "foo" matches argument types. Instead, we should try to give a message like Argument 1 to "foo" has incompatible type "int"; expected "str" or "bytes", which is more informative. This may not be always possible, but we should be able to do it at least most of the time.

@JukkaL
Copy link
Collaborator Author

JukkaL commented May 23, 2017

Also, if we can't give a specific message, we could print out the full signature of the target overloaded function as a note after the message. This would make it easier to see why the call is rejected by mypy.

@ilevkivskyi
Copy link
Member

I think just listing argument types and the overloads in a note may be enough. Also protocol notes already contain relevant code for nice compact formatting of overloads.

@JukkaL
Copy link
Collaborator Author

JukkaL commented May 14, 2018

The implementation of protocol notes lives in report_protocol_problems in mypy.messages. Overload messages are generated in no_variant_matches_arguments in the same module.

@MentalMegalodon
Copy link
Contributor

I'm working on it.

Michael0x2a added a commit to Michael0x2a/mypy that referenced this issue Jun 29, 2018
Resolves python#672 and
supercedes python#5054.

Currently, if a user calls an overloaded function and mypy is unable to
find a match, mypy will display display a warning like 'No overload
variant of "func" matches argument types" with no additional context.

This pull request will list several matching variants in addition to
that message. If possible, mypy will attempt to show only overloads that
have a compatible number of arguments. The number of overloads shown is
always capped at a maximum of 2.

This pull request does *not* attempt to report a custom error when...

1. Union-math fails. Rationale: the pending PR will change how unions
   are handled dramatically enough to the point where any error handling
   here would be pointless.

2. Mypy is able to infer what signature the user most likely meant by
   looking at the erased types. Rationale: I attempted to implement this
   feature but was unable to make it consistently work without adding
   several ugly hacks around how mypy records errors so decided to defer
   implementing this feature.
Michael0x2a added a commit that referenced this issue Jul 6, 2018
List possible overload variants when none match

Resolves #672 and
supersedes #5054.

Currently, if a user calls an overloaded function and mypy is unable to
find a match, mypy will display display a warning like 'No overload
variant of "func" matches argument types" with no additional context.

This pull request will list several matching variants in addition to
that message. If possible, mypy will attempt to show only overloads that
have a compatible number of arguments. The total number of extra
lines of output printed is capped at 4 -- this means that the number
of overloads shown is typically capped to a max of either 2 or 3.

This pull request does *not* attempt to report a custom error when...

1. Union-math fails. Rationale: the pending PR will change how unions
   are handled dramatically enough to the point where any error handling
   here would be pointless.

2. Mypy is able to infer what signature the user most likely meant by
   looking at the erased types. Rationale: I attempted to implement this
   feature but was unable to make it consistently work without adding
   several ugly hacks around how mypy records errors so decided to defer
   implementing this feature.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants