Error message needs more info: The type of the function _____, called on line ___ doesn't match the surrounding calling context.

[japhib]

This particular error message is insufficiently precise, which makes it hard to debug. It shows the type of the function that is trying to be called, but not what the args to the function are that causes this check to fail.

Example:

lib/gradient.ex: The type of the function :erlang.++(), called on line 194 doesn't match the surrounding calling context.
It has the following type
(nonempty_list(T1), list(T2) -> nonempty_list(T1 | T2))
(nonempty_list(T1), nonempty_improper_list(T2, T3) -> nonempty_improper_list(T1 | T2, T3))
(nonempty_list(T1), T2 -> nonempty_improper_list(T1, T2))
([], T -> T)

(This comes from gradualizer_fmt:format_type_error/2, the clause that looks like this: format_type_error({type_error, call_intersect, Anno, FunTy, Name}, Opts)).

Here is a better error message:

The variable on line 113 is expected to have type binary() but it has type integer() | float()

(This comes from gradualizer_fmt:format_expr_type_error/4.) Note that it says what the type actually is, integer() | float(), along with the expected type binary(), so it's much easier to see what the problem is.

How to reproduce?

There is probably a better way to do this. I'm not familiar enough with Gradualizer to provide an isolated test case. However, I've been running into this on my gradient PR here: esl/gradient#124 . Pull the branch specified there, which is https://github.com/japhib/gradient and branch umbrella-config , and run mix gradient on the project itself.

[erszcz]

Thanks for the report, @japhib! While the warning itself might actually need rewording and adding the types of the arguments, it also seems it's raised as a false positive in some cases. For reference, we're working on it in #485.

[japhib]

Great, thanks for the response!

[erszcz]

I briefly looked into changing the message itself. We don't have type info readily available to report for the args - that's part of the problem. We could infer it just for the sake of reporting, and that's a viable option for which I have some rough code in #491, but it still needs finishing. Once I do that, we can gauge if there's sufficient improvement to actually change the message.

[japhib]

Awesome 👍