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

Binary operator checking #92

Closed
kaleidawave opened this issue Nov 27, 2023 · 0 comments · Fixed by #186
Closed

Binary operator checking #92

kaleidawave opened this issue Nov 27, 2023 · 0 comments · Fixed by #186
Labels
blocking These issues are blocking the checker being used in projects checking Issues around checking enhancement New feature or request good-second-issue Moderately difficult issue
Milestone

Comments

@kaleidawave
Copy link
Owner

Current the functions to doing binary operations don't check the types of either side. First a bit of background:

There are two functions for binary operators, they are split between

  • Mathematical and bitwise operations. Both sides have to be checked as there is no short circuiting behavior
  • Logical operators. These can have logical operators (and in the future the RHS can be narrowed for && operations)

in and instanceof operators are handled specially on Environment

There is a also a current option strict_casts (it should probably be renamed to no_implicit_casts) in TypeCheckOptions. When this is true should not allow operations like "hi" + 2.

These two functions are currently set up to return a Result. However both the logic for checking the sides and the diagnostic has not been implemented. For example

pub fn evaluate_mathematical_operation(
lhs: TypeId,
operator: MathematicalAndBitwise,
rhs: TypeId,
types: &mut TypeStore,
strict_casts: bool,
) -> Result<TypeId, ()> {
fn attempt_constant_math_operator(
lhs: TypeId,

There are several things to carefully consider here

  • Still want to enable Symbol.toPrimative behaviour with hints and such (that will require these functions to have all the context to be able to do a call_type
    • This should disallow Object.toPrimative fall through as this result are not useful
@kaleidawave kaleidawave added enhancement New feature or request good-second-issue Moderately difficult issue checking Issues around checking labels Nov 27, 2023
@kaleidawave kaleidawave added this to the 0.1.0 milestone Nov 27, 2023
@kaleidawave kaleidawave added the blocking These issues are blocking the checker being used in projects label Jun 20, 2024
kaleidawave added a commit that referenced this issue Aug 26, 2024
- Basic operator checking (fixes #92)
- Inequality checks with ranges
- Identity checks from disjoint with `NaN`
- Disjoint with `Not` works (using subtyping)
- Proper checking that allows string + number?
- `infer T` in type annotation slice gets treated as `infer T extends string` (and also for generic arguments)
- Add `Number.isNaN` checks
- Change `GreaterThan` and `LessThan` to `InclusiveRange` and `ExclusiveRange`
- Add operations to ranges with new `FloatRange` type
- Changes `~`, `!` and `-` prefix operators to be in terms of `x ^ 0xFFFF_FFFF`, `x ? false : true` and `0 - x`. Removes `Constructor::UnaryOperation`
- Fixes to narrowing for `if (a)` where a is `string | falsy etc` and also to optional chaining
- Moves `a + b` is string or number to `result` field on `Constructor::BinaryOperator { result }` 
- Refactor of type helpers
- Type parameter extends checking on arguments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocking These issues are blocking the checker being used in projects checking Issues around checking enhancement New feature or request good-second-issue Moderately difficult issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant