Skip to content

Implement type inference for binary operators #390

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

Closed
6 tasks done
flodiebold opened this issue Dec 31, 2018 · 6 comments
Closed
6 tasks done

Implement type inference for binary operators #390

flodiebold opened this issue Dec 31, 2018 · 6 comments
Labels
E-has-instructions Issue has some instructions and pointers to code to get started E-medium good first issue

Comments

@flodiebold
Copy link
Member

flodiebold commented Dec 31, 2018

We need to infer the result types of binary operations, like a + b or a && b. In general, this will involve the following steps:

  • we probably want to wait for Introduce hir::Expr #386 to have hir::Expr::BinOp
  • add a test in ra_hir/src/ty/tests.rs for the binary operation
  • in infer_expr in ty.rs, add the code to infer the type of both operands and then calculate the result type.

One complication is that many operators are overloadable via traits (e.g. Add). To implement these correctly, we would have to be able to do associated type projections (i.e. calculate <T1 as Add<T2>>::Output). Since we're still quite a bit away from doing that, we might hard-code the result types for the primitive operations at least (and maybe it makes sense to guess that the output type is the same as the input type, but that could result in wrong inferences).

Specifically, we've got these groups of binary operations:

  • short-circuiting bool operations && and ||: These aren't overloadable and always have result type bool, so the inference is easy
  • comparison / equality: ==, < etc.: These are overloadable, but the result type is still always bool, so it's still easy 😄
  • assignment: =. This isn't overloadable, and the return type is always () (Ty::unit()). The right side needs to be coercible to the left; we don't have coercion yet, but we can already pass down the type of the left side as the expectation for the right side.
  • operation + assignment: +=, *= etc.. Overloadable, but result type is still always ().
  • arithmetical and bitwise operations: +, -, |, & etc.. These are overloadable with arbitrary result types, so we can't handle this in general without trait resolution, but we could still handle primitive types.
  • ranges .. and ..=: Not overloadable, but we need to find the various Range structs to construct the type.

I'd suggest taking these on one bullet point at a time 😄

@flodiebold flodiebold added E-medium E-has-instructions Issue has some instructions and pointers to code to get started good first issue labels Dec 31, 2018
@marcusklaas
Copy link
Contributor

I'm working on type inference for binary operations on primitive numbers now.

@flodiebold
Copy link
Member Author

@marcusklaas I've got the refactoring for #386 coming up, which changes a lot of code in type inference... So you're going to get a lot of conflicts if you start now :) I'll rebase and push my branch when #440 is merged, so maybe it'd be a good idea to wait for that.

@marcusklaas
Copy link
Contributor

Sounds good, I'll fix #440 and then wait for your code. Thanks for the heads-up :-)

bors bot added a commit that referenced this issue Jan 6, 2019
440: Implement type inference for boolean operators r=flodiebold a=marcusklaas

Tried implementing the easiest part of #390. Hope this is somewhat close to what the intent of the issue was. Found it surprisingly easy to find my way around the repository - it's well organized!

Very grateful for any pointers.

Co-authored-by: Marcus Klaas de Vries <[email protected]>
@flodiebold
Copy link
Member Author

Ok, the PR is #446.

bors bot added a commit that referenced this issue Jan 7, 2019
451: More type inference for more binary expressions r=flodiebold a=marcusklaas

Implements more of #390. Just works for primitive (numeric) types for now.

Found an issue where `let x: Ty = expr;` doesn't actually propagate the type information unless `Ty` is primitive and numeric. I'll open an issue for this.

Co-authored-by: Marcus Klaas de Vries <[email protected]>
@simonvandel
Copy link
Contributor

What is missing before this can be closed?

@DJMcNab
Copy link
Contributor

DJMcNab commented Feb 10, 2019

Searching for lang items and trait resolution :P. The former probably also requires a better api for handling attributes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-has-instructions Issue has some instructions and pointers to code to get started E-medium good first issue
Projects
None yet
Development

No branches or pull requests

4 participants