Optionally infer types of literals and other constructs

[zuiderkwast]

A new option infer is added. (--infer and --no-infer for the CLI.)

With this option enabled, types of literals, list cons, list comprehensions,
tuples and bit syntax expression are propagated in addition to the types
from the specs of functions.

[zuiderkwast]

Perhaps options can be used to evaluate different approaches?

With this enabled, we can catch the type error in the example in #26 (comment)

f() ->
  V = [1, 2],
  g(V).

-spec g(integer()) -> any().
g(Int) -> Int + 1.

A similar option could be used to control how short-circuit expressions are handled...

[Zalastax]

Neat!

What's your suggestion regarding testing? As you said, some code will fail/pass type checking depending on this option's value. Two new subdirectories?

[zuiderkwast]

I don't know @Zalastax. I think unit tests using code in strings, as in the typechecker_tests suite, is better than the should_fail/pass ones.

[Zalastax]

I don't agree that strings are better - they lack syntax highlighting.
Type checkers are a prime case for golden testing and I was happy to see that it's already what's being used. Golden testing is easier to reason about since every test case is completely static (less logic in test = good). We should only resort to unit tests with custom logic when it's absolutely necessary.

[RumataEstor]

Maybe put configuration options inside the source files in an attribute or as a special comment?

[zuiderkwast]

Maybe put configuration options inside the source files in an attribute or as a special comment?

You mean -gradualizer_opts([infer]). or something like that? It would be possible... But that would be a separate task to add that. One thing at a time IMO.

[gomoripeti]

great job @zuiderkwast, Im very positive about this option :) (hope I will have time to review sooner or later)

regarding testing I think the should_pass/fail are nice as smoke tests but a bit limited (for example you cannot test if there are 1 or more errors in a should_fail module). the typechecker_tests-style tests need less context, can reach edge cases easier, or eg can also test specific errors (when gradualizer will support returning error terms)

regarding module attributes, I think in real use the option should be per project (eg in rebar.config) and not per module - but for testing a module attribute can be a nice idea.

[josefs]

I don't have time to do a proper review right now, but I really like the idea here, @zuiderkwast!

If I understand correctly, you don't propagate the type of lambdas and maps. I think they should probably be added, though it would be fine if that was a separate commit. In my mind the --infer flag should infer the type of every value constructor.

[zuiderkwast]

Good point that maps and funs should be inferred as well. Let's add that later!