-
Notifications
You must be signed in to change notification settings - Fork 5
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
Reworked the sub-type relationship infrastructure #58
base: main
Are you sure you want to change the base?
Conversation
…ns/operators, more test cases for assignability
… order to reuse and to customize them
… in the type graph, exploit them for advanced assignability checks (WIP)
…ced assignability result+success(+problem)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All in all just a bit coding style and a bit knowledge transfer -Typescript-wise. I still do not get the purpose of the 300+-changes file which I commented as latest. I hope you will find these comments helpful :). Thanks for your work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this work @JohannesMeierSE. I am pretty happy to get rid of analyzeIsSubTypeOf and analyzeIsSuperTypeOf. The rest looks fine to me too, where I had something to add, I placed a comment. Let's discuss the first two "aspects for review" in the meeting. I do not have a ready made solution at hand.
…ld use loops to define multiple relationships at once
…onsTypeInferenceRule, improved comments
Thanks @insafuhrmann and @Lotes for your helpful reviews! I just pushed the corresponding improvements (and resolved the corresponding discussions here), but some discussions are still open. I suggest to continue them in our next joint meeting. |
@Lotes @insafuhrmann I just pushed the last improvements according to our discussions today. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have found a small thing about values vs. types.
Otherwise, LGTM :-).
|
||
|
||
describe('Test multiple matches for overloaded operators and ensures that the best match is chosen', () => { | ||
test('2 + 3 => both are integers', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overloading can also be on type level. Like the assignments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if it looks nice, the values play no role here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, that the actual values are not relevant (we could test "123 + 456" instead without any differences).
But here I want to test the type inference, in particular, whether the "best overload" is found during the type inference.
(Note that FunctionType is nearly unchanged, while there are lots of changes in the function-*-inference.ts
files)
Testing type inference is easier with actual values, therefore, I prefer to keep these "easy-to-read" test cases. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can live with it :-) As I said, it looks nice, nevertheless.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine for me as well.
This PR contributes:
analyzeIsSubTypeOf
andanalyzeIsSuperTypeOf
anymoreSubTypeProblem
andSubTypeSuccess
interfaces, combined astype SubTypeResult = SubTypeSuccess | SubTypeProblem
typir
inpackages/typir/src/test/predefined-language-nodes.ts
(they are strongly inspired from our joint work @insafuhrmann)Aspects for the review:
subProblems
for failed checks of sub-type and assignability? As an example, a user is interested, why two structually typed classes are not sub-types.GraphAlgorithms
ingraph-algorithms.ts
more type-safe?conversion.test.ts
contains a test case to check for cycles in conversion rules: Could you check, whether is reflects the kind of test cases you looked for you?