Add imported modules values suggestions for unknown variables.
When a variable is not in the current scope, an `Error::UnknownVariable`
is triggered. However the only suggestions were for variables in the
scope with a similar name computed by the "did you mean" algorithm. With
this commit, we also suggest public and internal values (such as
constants, functions or type variant constructor) in imported modules
with the same name.
For example with the following code:
```gleam
import gleam/io
pub fn main() -> Nil {
println("Hello, World!")
}
```
The suggestions are:
```
┌─ /path/to/project/src/project.gleam:4:3
│
4 │ println("Hello, World!")
│ ^^^^^^^
The name `println` is not in scope here.
Consider using one of these variables:
io.println
```
However because we are only checking the name and the arity, we could
have wrong suggestions, as in this case:
```gleam
import gleam/float
import gleam/int
pub fn main() -> Nil {
to_string(3)
}
```
Here, it is clear that we want suggestions on a function named
`to_string` and accepting one parameter of type `Int`, but this is not
the case:
```
┌─ /path/to/project/src/project.gleam:5:3
│
5 │ to_string(3)
│ ^^^^^^^^^
The name `to_string` is not in scope here.
Consider using one of these implementations:
float.to_string
int.to_string
```
In this case, even if the arity is correct, the type of arguments can
mismatch, resulting in incorrect suggestions.
Suggestions also works on pipelines but there are subtleties. Function
calls are considered to be always of arity `arguments.len() + 1`.
In this code, the arity of `to_string` function is considered to be 1.
```gleam
1 |> to_string
```
And in this code, the arity of `to_string` function is considered to
be 2:
```gleam
1 |> to_string(2)
```
This is hard to make something better without analyzing the return
type because function call in pipeline can be desugared into two
possibilities. For example, take this code:
```gleam
1 |> add(2)
```
It can be desugared in these two forms:
```gleam
add(1, 2)
add(2)(1)
```
As it stands, this is not possible to make better suggestions without
adding more analysis on the return type.
Add better unreachable code warnings when a panic is before a use
expression.
With previous changes, a test was broken when a panic was right before a
use expression. The test was like that:
```gleam
pub fn wibble(_) { 1 }
pub fn main() {
panic
use <- wibble
1
}
```
This was the case because, before these changes, `UntypedExpr::Var`
has not special call path in `do_infer_call` function. `infer` and
`infer_or_error` was called has expected and a warning was emitted by
`warn_for_unreachable_code` in case of a previous panic expression.
Actually, `UntypedExpr::FieldAccess` has a special call path in
`do_infer_call` and compiler does not warned about a program like that:
```gleam
// Define pub fn wibble(_) { 1 }
import mylib/mymod
pub fn main() {
panic
use <- mymod.wibble
1
}
```
With this change, use expression are always warned after a panic
expression.
For this change, we add to renamed all functions in `ModuleInterface`
from `get_public_*` functions to `get_importable_*` because we wanted
to suggests internal value only from modules of the same package,
otherwise we should suggest only public values. Before this change, all
`get_public_*` functions was returning `importable` values which are
internal and public.
Because the naming was not the best one for these functions, we have
renamed them to `get_importable_*` which seems more appropriate.
nandi.uk