Use type inference

[davidanthoff]

Say we have

foo(a::Int) = a * 2

bar(a::String) = a * "asdf"

And then we write a function:

function test(x::String)
    y = bar(x)
    z = foo(y)
    return z
end

Then it would be nice if the linter complained (with an error, not a warning) that the line z = foo(y) is wrong because there is no method foo for a String.

We might have to introduce a new config value a la "assume no type piracy and some other reasonable assumptions like no dynamic creation of functions", but at that point we should be able to say with confidence that test as written has a bug. In some sense we would introduce a "TypeScript-like mode" where if you follow some rules, you get much more static type checking.

Here is the tricky thing, though: we would have to run return_types or something like that on the functions that are used inside test. But of course that doesn't work because we don't want those functions to exist in the LS process...

I see two ways out: 1) we recreate return_types to be able to operate on our own data structures, 2) we go back to keeping the symbol server alive, with a full communication channel between the LS and the symserver, and we run return_types in the symserver process. This is also anything but trivial, for example we would have continually update the definitions of functions that are edited inside the symserver process (a bit like Revise.jl, but based on the in-memory representation of files that the LS holds).

I'm bringing this up now because considerations re something like this might affect how we think about indexing in the cloud etc.

In general, though, I think we should use the information that something like return_types provides. I know that the general rule is that one shouldn't rely on its return value in normal code, but I think for a linter the situation is different: return_types will never return something that is wrong, it might just return something that is "wider" than is really the case. But that is fine, in those cases the linter probably just wouldn't be able to identify a problem. But if what return_values gives us does allow us to pin point a type bug, we might as well use it and show it to the user.