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

Print reasons for subtyping mismatches #167

Open
kaleidawave opened this issue Jun 20, 2024 · 0 comments
Open

Print reasons for subtyping mismatches #167

kaleidawave opened this issue Jun 20, 2024 · 0 comments
Labels
checking Issues around checking enhancement New feature or request good-second-issue Moderately difficult issue

Comments

@kaleidawave
Copy link
Owner

When doing subtyping (initial declaration, assigning, passing argument as parameter, return type etc) the returned result is a SubTypeResult. The subtyping logic (in types/subtyping.rs) currently collects some of the reasons for mismatches when doing the checking and stores this as a NonEqualityReason.

However this reason is thrown away in many places and does not make it to diagnostics. This can be shown by running rg "SubTypeResult::IsNotSubType\(_".

It would be better to pass this via a field to many of the diagnostics. For example here

DoesNotMeetConstraint {
variable_type: TypeStringRepresentation,
variable_site: SpanWithSource,
value_type: TypeStringRepresentation,
value_site: SpanWithSource,
},

There should be something like mismatch: MismatchExplanation. This can be turned into a user readable explanation of why the type error happened. This can be surfaced via adding labels in the Diagnostic::PositionWithAdditionalLabels.

The TypeStringRepresentation enum was designed to cover this, but I don't think it quite fits into this structure.

@kaleidawave kaleidawave added enhancement New feature or request good-second-issue Moderately difficult issue checking Issues around checking labels Jun 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
checking Issues around checking enhancement New feature or request good-second-issue Moderately difficult issue
Projects
None yet
Development

No branches or pull requests

1 participant