Implement type inferences from guard expressions #239
Conversation
Potential improvements for future: 1. Better handle `and` operator in guards: current implementation picks one and discards the other 2. Better handle `or` operator in guards: current implementation discards both sides. We can represent them as union types. In real use cases, this should happen rarely, so I'll leave it like this for now Closes elixir-lsp#204
Goose97
force-pushed
the
feature/type-inferences-from-guard
branch
from
952f837
to
3fad3c5
Compare
|
|
||
| test "list guards" do | ||
| assert %VarInfo{name: :x, type: :list} = var_with_guards("is_list(x)") | ||
| assert %VarInfo{name: :x, type: :list} = var_with_guards("hd(x) == 1") |
There was a problem hiding this comment.
Would it be easy to get {:list, :integer} here? We'd need to parse {:==, _, _} expression
There was a problem hiding this comment.
I'm not sure if we should do this. List can have different type values, so situations like this can provide misleading type information:
list = [1, :atom, "binary"]
hd(list) == 1
# infer type of list as {:list, :integer} -> incorrect
There was a problem hiding this comment.
I made the assumption elsewhere just to simplify things. The type system here is used mostly for completions and I never aimed for perfectly expressing every type possible
There was a problem hiding this comment.
Thanks for explaining this. Fixed in fe7b2be
|
|
||
| test "tuple guards" do | ||
| assert %VarInfo{name: :x, type: :tuple} = var_with_guards("is_tuple(x)") | ||
| assert %VarInfo{name: :x, type: :tuple} = var_with_guards("tuple_size(x) == 1") |
There was a problem hiding this comment.
Similarly with list example above it would be nice to get {:tuple, 1, [nil]} here.
There was a problem hiding this comment.
Fixed in fe7b2be
For unknown type tuple (i.e. when tuple_size(x) == 2), the type will be:
{:tuple, <size>, []}
|
Nice work @Goose97 and sorry for the delay with review. Can you address the comments? |
Goose97
force-pushed
the
feature/type-inferences-from-guard
branch
from
de4e73d
to
ea32947
Compare
Goose97
force-pushed
the
feature/type-inferences-from-guard
branch
from
7287a49
to
11428b9
Compare
Goose97
force-pushed
the
feature/type-inferences-from-guard
branch
from
e266041
to
5ef6393
Compare
|
Sorry for the delay. I've complete forgot about this PR 🙇 The logic get pretty long so I extracted it into another module 6b4c0d0 |
|
Awesome @Goose97 |
Potential improvements for future:
andoperator in guards: current implementation picks one and discards the otheroroperator in guards: current implementation discards both sides. We can represent them as union types. In real use cases, this should happen rarely, so I'll leave it like this for nowCloses #204