-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Overload resolution failure should explain for each candidate why it does not match. #9607
Comments

I would also suggest to change the source location displayed here to be the entire function definition header. |

I stumbled upon this issue while writing test cases with function types. The following compiles just fine (Edit: And binds to the square of function).
However, the following does not. The type error seems to be incorrect at first glance. Unlike @Marenz example, there is no type conversion happening so one would expect the first free function to be bound to the immutable.
|
@bshastry this is expected. What an expression resolves to should not depend on how the expression is used later on, at least in my opinion. |
Not sure I follow. Shouldn't |
Solidity follows the concept that in |
Sorry, I still don't understand :) How does the scope of
compiles but the following throws an error
In both cases |
Another case reported in #10220 by @barakman. contract Test {
uint256[] private arr;
function func(uint256 x, uint256 y) public {
arr.push(x, y);
}
} Up to 0.5.17 the compiler used to report this:
Starting with 0.6.0 the error message is much less informative:
|
@bshastry the compiler tries to resolve |
This came up again recently: #13812. The issue has a nice test case where the error messages look confusing at first glance and only after removing the overload it becomes clear why the candidates do not match. Also, two related issues: |
In the example below it is obvious we want to call the variant with the two extra parameters, but the error does not make it obvious why we can't call it (uint -> int conversion required). A better error message showing the different types would be great.
The text was updated successfully, but these errors were encountered: