Fit type check

[abco20]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @abco20, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly advances the BT-DSL compiler's type checking capabilities by introducing a sophisticated type inference system. It enables variables to have their types inferred from usage, supports wildcard types in declarations, and enforces strict integer literal bounds. The changes aim to reduce boilerplate in type declarations while maintaining strong type safety, ensuring that the compiler can intelligently deduce types and report conflicts early in the development cycle.

Highlights

• New 'Unknown' Type: Introduced a new Unknown type to represent inference placeholders, allowing for more flexible type inference, especially for nullable wildcards.
• Enhanced Type Inference System: Implemented a robust type inference system for variables, including mechanisms for constraining variable types, unifying inference equivalence classes (using a Union-Find structure), and resolving common supertypes from multiple constraints.
• Integer Literal Bounds Checking: Added validation to ensure integer literals fit within their expected integer types, preventing numeric overflow errors during type checking.
• Expanded Array Type Assignability: Improved assignability rules for array types, allowing for proper type checking between static arrays of the same size and dynamic arrays with assignable element types.
• Comprehensive Test Coverage: Added extensive unit tests covering various complex inference scenarios, including numeric overflow, wildcard types in arrays/vectors, local variable inference from usage, function argument inference, multiple constraints, transitive inference, inference from out parameters, inference from branches, and common supertype resolution.
• Updated Documentation: The documentation has been updated with a new section detailing the rules for 'Common Supertype Resolution' within the type inference system.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a significant enhancement to the type checker by implementing a full type inference system for local variables, using a union-find algorithm. It also adds checks to ensure integer literals fit within their expected types. The changes are extensive and well-structured, and the addition of a comprehensive test suite for the new inference logic is excellent. I've found one critical issue in the type unification logic that could lead to incorrect type inference or erroneous errors. My detailed feedback is in the review comments.

[gemini-code-assist]

This block for unifying mixed integer and float types has a couple of issues:

1. The _concrete_ boolean variables are not correctly identifying concrete (non-literal) types. For example, a_concrete_int is assigned a->is_integer(), which is true for both concrete integer types and IntegerLiteral. This causes the check on line 115 to incorrectly reject valid unifications, such as between a float32 and an IntegerLiteral.

2. The early returns on lines 119-120 are incorrect. For example, when unifying {float} and int32, the code returns {float}. The result should be a concrete float type (e.g., float64), which common_numeric_type would correctly determine. These early returns prevent the correct unification logic from being reached.

Here is a suggested fix that corrects the concrete type checks and removes the buggy early returns, allowing common_numeric_type to handle all valid mixed-family unifications.

      const bool a_concrete_int = a->is_integer() && a->kind != TypeKind::IntegerLiteral;
      const bool b_concrete_int = b->is_integer() && b->kind != TypeKind::IntegerLiteral;
      const bool a_concrete_flt = a->is_float() && a->kind != TypeKind::FloatLiteral;
      const bool b_concrete_flt = b->is_float() && b->kind != TypeKind::FloatLiteral;

      if ((a_concrete_int && b_concrete_flt) || (a_concrete_flt && b_concrete_int)) {
        return types.error_type();
      }
      // Fall through to common_numeric_type for mixed-family unification involving literals.