Refactor and improve type checking. #28481

mikebenfield · 2024-12-19T00:37:33Z

No description provided.

compiler/ast/src/types/tuple.rs

tests/expectations/compiler/records/same_name_diff_type_fail.out

tests/expectations/compiler/core/algorithms/integers/pedersen128/pedersen128_hash_to_i128.out

d0cd · 2024-12-19T16:09:15Z

tests/expectations/compiler/core/algorithms/integers/pedersen128/pedersen128_hash_to_i32.out

+Error [ETYC0372003]: Expected type `an integer of less than 128 bits or a bool` but type `Foo` was found
+    --> compiler-test:41:47
+     |
+  41 |         let q: i32 = Pedersen128::hash_to_i32(Foo { a: 1u32, b: 1u32, });


~~This should work right, because the size of Foo will be less than 128 bits.~~ This particular instance actually may be too large, but some structs may fit. May be an entirely new feature.

Actually I'm not sure any structs will fit. There's a lot of overhead in the bitwise representation of structs. For each member, its name is encoded as a field. I don't think any struct will be encoded as less than 280 bits.

Identifiers are length-prefixed so for small enough structs, you'd be able to get them to fit.

#[test] fn test_size_in_bits() { let plaintext = Plaintext::<CurrentNetwork>::from_str("{ x: 1u8 }").unwrap(); let size_in_bits = plaintext.to_bits_le().len(); assert_eq!(size_in_bits, 76); }

A simpler approach could be to allow structs and arrays, but issue a compiler warning that their may be a runtime failure if the struct or array is too big.
Possibly work for a different PR.

I see. In that case maybe yeah I'll leave it to a runtime error.

d0cd · 2024-12-19T16:44:58Z

tests/expectations/compiler/core/algorithms/integers/pedersen128/pedersen128_hash_to_i64.out

+Error [ETYC0372003]: Expected type `an integer of less than 128 bits or a bool` but type `Foo` was found
+    --> compiler-test:41:47
+     |
+  41 |         let q: i64 = Pedersen128::hash_to_i64(Foo { a: 1u32, b: 1u32, });


In this case, Foo exceeds the size of a u64, so it should not be allowed.

I don't follow. It already is being disallowed, isn't it?

Oops, meant it as a follow on thought for the previous comment.
That structs and arrays should in general be allowed, but this one is clearly oversized.

tests/expectations/compiler/core/algorithms/pedersen_fail.out

tests/tests/compiler/futures/async_before_call_fail.leo

errors/src/errors/type_checker/type_checker_error.rs

compiler/passes/src/type_checking/checker.rs

d0cd · 2024-12-19T18:59:01Z

compiler/passes/src/type_checking/checker.rs

-            }
-        }
-    }
-


Should check_eq_types be renamed to assert_eq_types for consistency?
Also could you help me remove the dangling print I left behind in assert_eq_types 😅

I actually plan on removing this function in one of the followup PRs.

compiler/passes/src/type_checking/checker.rs

compiler/parser/src/parser/type_.rs

compiler/passes/src/type_checking/check_expressions.rs

Superfluous contants like `ADDRESS_TYPE` in checker.rs are removed, along with some of the `assert_*_type` methods. TypeChecker's implementation of ExpressionVisitor has `Output = Type` rather than `Output = Some(Type)`, and its methods return `Type::Err` on errors rather than None. Many functions in that implementation have a simpler implementation with fewer levels of nesting. Introduced new errors for TypeCheckerError: `type_should_be2` is a replacement for `type_should_be` with a better message. Also various `_mismatch` errors for operators with incorrectly typed operands. Introduce `equal_user` for comparing whether two types are equal as seen by the user - only difference between the older eq_flat is it takes into account current program name when comparing composite types Display CompositeType with program name if present. Parse CompositeType without program name if it's not present. Catch type errors previously not caught: * transition call after async function call (this should eventually be allowed, but it will require changes to codegen) * Abs operand type * Binary operation operand type * Comparing record types with the same name but different programs * Ternary conditional operands not being the same type (Some of these errors were caught before only in the case that their visitor received an expected type as addtional input.)

mikebenfield requested a review from d0cd December 19, 2024 00:37