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

Check default parameter value type #132

Merged

Conversation

CharlesTaylor7
Copy link
Contributor

@CharlesTaylor7 CharlesTaylor7 commented Apr 13, 2024

Part 2 of #112
Default parameter type checking.

@kaleidawave kaleidawave merged commit 24e35b9 into kaleidawave:main Apr 14, 2024
8 checks passed
@kaleidawave kaleidawave added bug Something isn't working checking Issues around checking subtyping Related to comparing two types labels Apr 14, 2024
@kaleidawave
Copy link
Owner

Another great PR. Specification test is great and diagnostic great 👍. Up to 202!

Just added two quick commits on top

  • Firstly the merge conflict in diagnostics.rs from the first PR.
  • Secondly I swapped the ASTNode::get_position call for A::expression_position for getting the position of where to emit the type checking error. This is because the type checking API is meant to be agnostic from a parser implementation (so in the future any other project can reuse the checking APIs without them to being specific to the ezno-parser parser I built). A::expression_position comes from ASTImplementation which works in under any AST definitions that implement it. For the ezno-parser AST definition it does use ASTNode::get_position. That fixes why the CI error on the extras tests as the only place you can refer to ezno-parser in the checker is under the synthesis directory (which mostly connects APIs to the AST definitions). Little bit complex, need to document the ASTImplementation trait and that whole system better!

@CharlesTaylor7 CharlesTaylor7 deleted the 112-check-default-argument branch April 14, 2024 18:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working checking Issues around checking subtyping Related to comparing two types
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants