Line number on issues is not helpful

[Fl4m3Ph03n1x]

Background

I am now trying Gradual type checking, as a consequence I am giving this library a shot.

So, on my first ever code snippet, I started with a pure function:

defmodule TipCalculator do

  @spec getTipPercentage(List[String.t()]) :: non_neg_integer
  def getTipPercentage(names) do
    names_size = length(names)

    cond do
      names_size > 5 -> 20
      names_size > 0 -> 10
      true -> 0
    end
  end
end

Now, the keen eye will see I have List[String.t] instead of [String.t] in line 3.

Problem

However, Gradient seems to have a different opinion:

===> Analyzing applications...
===> Compiling gradualizer
src/gradualizer.erl:45:2: Warning: opaque type top() is underspecified and therefore meaningless

src/typechecker.erl:3234:1: Warning: function type_check_cons_in/4 is unused
src/typechecker.erl:3247:1: Warning: function type_check_cons_union/4 is unused
src/typechecker.erl:4612:1: Warning: function verbose/3 is unused
src/typechecker.erl:4870:1: Warning: function gen_partition/3 is unused
src/typechecker.erl:4872:1: Warning: function paux/3 is unused

==> gradient
Compiling 14 files (.ex)
Generated gradient app
==> grokking_fp
Compiling 1 file (.ex)
warning: code block contains unused literal "\n" (remove the literal or assign it to _ to avoid warnings)
  lib/tip_calculator.ex: TipCalculator

Generated grokking_fp app
Typechecking files...
lib/tip_calculator.ex: Undefined remote type Access:get/2 on line 0

Namely, the line number is off:

• lib/tip_calculator.ex: Undefined remote type Access:get/2 on line 0

To me, this is not a very descriptive error message. I am expecting an unknown_type kinf of error.

Comparing with dialyzer

lib/tip_calculator.ex:3:unknown_type
Unknown type: Access.get/2.

As you can see, with dialyzer the line number is correct, which was a great help to find the issue.
With Gradient, line 0 really threw me off.

Furthermore Unknown type was easier to understand than Undefined remote type. I don't even know what a remote type is to be honest.

Please let me know what you guys think.

[erszcz]

Hi @Fl4m3Ph03n1x!

Thanks for the report! The missing line number seems to be related to #12 that @Premwoik is already working on. Let's see if that's it.

Furthermore Unknown type was easier to understand than Undefined remote type. I don't even know what a remote type is to be honest.

Thanks for the input, it's appreciated. I'm not sure we'll change this vocabulary just yet, but feedback is always welcome. As an explanation - a remote type is a type that's not local to the currently checked module. In this case, it means that Gradient is looking for type Access.get/2 outside of module TipCalculator, but cannot find it.

Thanks again 👍

[Fl4m3Ph03n1x]

As an explanation - a remote type is a type that's not local to the currently checked module. In this case, it means that Gradient is looking for type Access.get/2 outside of module TipCalculator, but cannot find it.

This human readable explanation was quite helpful. Would it make sense to add something like this to the message?

[Premwoik]

@erszcz As far as I remember the problem with this missing line, in this case, was that Gradualizer cleans the information about the line in the returned error. But I will check it :)

[erszcz]

@Fl4m3Ph03n1x

Would it make sense to add something like this to the message?

Makes sense 👍

@Premwoik Ahhh, so we'd have to fix that upstream 🤔 Thanks for the info.

[Premwoik]

@erszcz I think it's because of this step:
https://github.com/josefs/Gradualizer/blob/87bb404113f3c9ef43715f0fcda8df6d408683e1/src/typelib.erl#L119

remove_pos({remote_type, _, [Mod, Name, Params]}) ->
    Params1 = lists:map(fun remove_pos/1, Params),
    {remote_type, erl_anno:new(0), [Mod, Name, Params1]};