feat: restrict uzumaki to variable declarations #80

[KevinMB0220]

📌 Summary

Close #80

This PR introduces stricter validation for the Uzumaki (@) operator within the type checker, ensuring it is only used in valid contexts and properly reported when misused.

✨ Changes

Type Checker

• Added a new error variant UzumakiMisuse to clearly report invalid usage of the Uzumaki operator.
• Enforced Uzumaki usage exclusively within variable declarations.
• The type checker now emits an error when @ is used outside of Statement::VariableDefinition.

Tests

• Updated existing Uzumaki-related tests to reflect the new restrictions.
• Added negative test cases to validate that misuse of the Uzumaki operator is correctly detected and reported.

✅ Compliance

This PR fully complies with:

• Project contribution guidelines
• Code style requirements (formatted with cargo fmt)
• The functional requirements defined in Issue uzumaki can only be used in variable declaration statements #80

🧪 Verification

All tests pass successfully, and the new validation logic behaves as expected for both valid and invalid Uzumaki usage.

---

Good

• Clear error reporting for invalid Uzumaki usage
• Stronger semantic guarantees in the type checker

Bad

• None identified

[KevinMB0220]

@0xGeorgii can you review and aprove the workflows

[Copilot]

Pull request overview

This PR restricts the Uzumaki (@) operator to only be valid within variable declaration statements, preventing its misuse in assignments, return statements, and general expressions.

Changes:

• Added UzumakiMisuse error variant to report invalid Uzumaki operator usage
• Modified type checker to emit errors when @ appears outside variable declarations
• Updated and added tests to validate the new restrictions

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
core/type-checker/src/errors.rs	Added new UzumakiMisuse error variant with appropriate error message and location tracking
core/type-checker/src/type_checker.rs	Replaced Uzumaki type inference logic in assignments, returns, and expressions with error reporting
tests/src/type_checker/type_checker.rs	Updated existing test and added three new negative test cases validating error reporting for misuse

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The error message uses backticks around 'uzumaki' which may not render well in all contexts. Consider removing the backticks or using a more descriptive term like 'the uzumaki operator (@)' for clarity.

Suggested change

	#[error("{location}: `uzumaki` can only be used in variable declaration statements")]
	#[error("{location}: the uzumaki operator (@) can only be used in variable declaration statements")]

[Copilot]

The error message string is duplicated across three test cases (lines 1057, 1072, 1087). Consider extracting this as a constant to improve maintainability and ensure consistency if the message changes.

[0xGeorgii]

@KevinMB0220 Thanks for the contribution. I think that because this check is scope-bounded and not actually a type-check, rather a semantic check, it makes sense to create a new core crate semantic-analysis so the high-level data flow should be like:

parse -> type check -> semantic check -> codegen ...

And there is actually a placeholder function for invoking this new crate:

https://github.com/Inferara/inference/blob/main/core/inference/src/lib.rs#L330

[KevinMB0220]

@KevinMB0220 Thanks for the contribution. I think that because this check is scope-bounded and not actually a type-check, rather a semantic check, it makes sense to create a new core crate semantic-analysis so the high-level data flow should be like:

parse -> type check -> semantic check -> codegen ...

And there is actually a placeholder function for invoking this new crate:

https://github.com/Inferara/inference/blob/main/core/inference/src/lib.rs#L330

Ok I work to fix

[KevinMB0220]

@KevinMB0220 Thanks for the contribution. I think that because this check is scope-bounded and not actually a type-check, rather a semantic check, it makes sense to create a new core crate semantic-analysis so the high-level data flow should be like:

parse -> type check -> semantic check -> codegen ...

And there is actually a placeholder function for invoking this new crate:

https://github.com/Inferara/inference/blob/main/core/inference/src/lib.rs#L330

Ok I work to fix

[KevinMB0220]

@0xGeorgii can you review the issue?