Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use guards when determining types of variables #204

Closed
lukaszsamson opened this issue Mar 7, 2023 · 0 comments · Fixed by #239
Closed

Use guards when determining types of variables #204

lukaszsamson opened this issue Mar 7, 2023 · 0 comments · Fixed by #239

Comments

@lukaszsamson
Copy link
Collaborator

Especially is_struct(term, name) and is_map_key(map, key) might be useful as those can be used for completions. Other ones if we extend type support

Goose97 added a commit to Goose97/elixir_sense that referenced this issue Jul 15, 2023
Potential improvement 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 added a commit to Goose97/elixir_sense that referenced this issue Jul 15, 2023
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
lukaszsamson pushed a commit that referenced this issue Nov 27, 2023
* Implement type inferences from guard expressions

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 #204

* Make type more specific

* Support map_size guard

* Fix incorrect fixture code

* Merge or guards into union type

* Use intersection type

* More refine type for list and tuple

* Split guard type infer logic into separate module

* Add moduledoc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant