Fix initialisation of type parameter jkinds from annotations#2840
Merged
Fix initialisation of type parameter jkinds from annotations#2840
Conversation
lpw25
approved these changes
Aug 12, 2024
Collaborator
lpw25
left a comment
There was a problem hiding this comment.
This is sound and improves a lot of error messages.
537ba07 to
78513c6
Compare
ITO444
pushed a commit
to ITO444/flambda-backend
that referenced
this pull request
Aug 13, 2024
lukemaurer
pushed a commit
to lukemaurer/flambda-backend
that referenced
this pull request
Oct 23, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A simple fix for jkind assignment for type variables, which cleans up many error messages and is necessary for higher jkinds to work later down the line.
When type parameters are encountered within
Typetexp.transl_type_var, their jkind is initialised anew, even when an annotation is available. This PR looks up whether a parameter of the same name had an annotation and uses that instead.This is fine as the type variable itself is still initialised as distinct, but we know the jkinds will be consistent across all instances.