Improve some OTP type specs about gradualizer HOT 11 CLOSED

I encourage you to make a pull request with the specs you want to improve in OTP. Preferrably one per OTP application.
I think we will accept most of them without problem. For example hd([A]) -> A is something we have thought of as an improvement anyway.

from gradualizer.

I consider this issue Done. Note that it contains "some" in the title.

This means that we have reached the goals for a beta version, so let's take 0.1.0! Shall we? (Before we make any new major changes...)

from gradualizer.

The long-term solution would be to update these in OTP with more specific types such as hd([A]) -> A. It would not impossible to get such a PR accepted, I think.

from gradualizer.

@zuiderkwast, I agree. We should absolutely try to fix the types on OTP. The plan I outlined above is the short- to medium term solution.

from gradualizer.

Where comes the otp code/types into Gradualizer?

from gradualizer.

@jachto, the Gradualizer doesn't have any special mechanism for importing types from OTP. The file gradualizer_db handles the lookup of types in other modules, and if you want to dig into the details you can start with the function import_module/2.

from gradualizer.

Thanks for the encouragement, @KennethL! It's good to know that you're open to improving the specs. We'll make sure to submit pull request in due course.

from gradualizer.

Hello! I think I have similar problems with standard Elixir libraries. Let's say I have a function

  @spec foo :: non_neg_integer()
  def foo do
    [:bar, :buz]
    |> Enum.count
  end

Then Gradualizer will say

The expression [bar,buz] on line 0 does not have type t()

Where actually t() is Enumerable.t() which is term(). What will be the best solution here? To create ./priv/elixir_spec_fix.erl? Or maybe we should develop mechanism to override types locally in context of project where Gradualizer is executed for type checks?

from gradualizer.

hi @tim2CF
I think in the current example it should be a Gradualizer issue (why the list [:bar, :baz] is not a subtype of term())

But in general good point about overriding specs. Technically it should be no problem to override an Elixir standard lib spec even in otp_spec_fix.erl, although need to use Erlang syntax, eg

-spec 'Elixir.Enum':map('Elixir.Enumerable':t(), fun((any()) -> T) ) :: [T].

(Would be nice to have separation and store Elixir overrides in a separate module, even maybe in Elixir syntax)
It is also a good idea to allow user-specific spec files in the same format, this can be an additional (rebar3/mix) plugin option.

from gradualizer.

I wouldn't be opposed to a 0.1.0 version. But I think it's important to point out that polymorphism doesn't work yet.

from gradualizer.

Sounds good! Let's finish up stuff in #43, e.g. describing what works and what not.

from gradualizer.