-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Normalize type references before relating them #35266
Conversation
@typescript-bot test this |
Heya @ahejlsberg, I've started to run the perf test suite on this PR at c73affd. You can monitor the build here. It should now contribute to this PR's status checks. Update: The results are in! |
Heya @ahejlsberg, I've started to run the extended test suite on this PR at c73affd. You can monitor the build here. It should now contribute to this PR's status checks. |
Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at c73affd. You can monitor the build here. It should now contribute to this PR's status checks. |
Heya @ahejlsberg, I've started to run the parallelized community code test suite on this PR at c73affd. You can monitor the build here. It should now contribute to this PR's status checks. |
@ahejlsberg Here they are:Comparison Report - master..35266
System
Hosts
Scenarios
|
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
@@ -14240,6 +14240,14 @@ namespace ts { | |||
return getObjectFlags(source) & ObjectFlags.JsxAttributes && !isUnhyphenatedJsxName(sourceProp.escapedName); | |||
} | |||
|
|||
function getNormalizedType(type: Type, writing: boolean): Type { |
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.
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.
We should be able to just move the loop into getNormalizedType
.
@@ -60,7 +60,7 @@ tests/cases/conformance/types/typeRelationships/recursiveTypes/recursiveTypeRefe | |||
|
|||
const b20: Box2 = 42; // Error | |||
~~~ | |||
!!! error TS2322: Type '42' is not assignable to type 'Box2'. | |||
!!! error TS2322: Type '42' is not assignable to type 'Box<number | Box2>'. |
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.
😦 Is it possible we want to keep the pre-normalized form around for error reporting? Since it might have a nicer alias for us to use?
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 looked at doing that, but I'm not sure it really is all that valuable. We still display the alias in all other situations, it's only when we're elaborating into the type that we now display structure one level earlier that we would before. I think the few places it affects are just as well served with the change in this PR (which, BTW, is what we used to always do).
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 know, but we acknowledged that these errors were better - a nice side effect of the recursive alias change. it would be nice if we could keep them.
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.
Ok, changed the code to preserve the original type and use it in error reporting if it has an alias.
RWC tests have a few error baseline changes that I think are fine. Community tests suite changes are preexisting conditions. DT tests suites are clean. No changes in performance. Overall, I think this one is good to do. |
@typescript-bot test this |
Heya @ahejlsberg, I've started to run the perf test suite on this PR at 88d0315. You can monitor the build here. It should now contribute to this PR's status checks. Update: The results are in! |
Heya @ahejlsberg, I've started to run the parallelized Definitely Typed test suite on this PR at 88d0315. You can monitor the build here. It should now contribute to this PR's status checks. |
Heya @ahejlsberg, I've started to run the extended test suite on this PR at 88d0315. You can monitor the build here. It should now contribute to this PR's status checks. |
Heya @ahejlsberg, I've started to run the parallelized community code test suite on this PR at 88d0315. You can monitor the build here. It should now contribute to this PR's status checks. |
@ahejlsberg Here they are:Comparison Report - master..35266
System
Hosts
Scenarios
|
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
Looking at RWC, it looks like tuple aliases still aren't preserved in errors - is there an elaboration codepath the most recent change missed? (The elaboration in property relations, maybe?) |
Actually, we're preserving type aliases in more situations than we did previously. |
This PR changes
isRelatedTo
to normalize type references before relating them. This in particular means that deferred type references are be turned into equivalent non-deferred type references before being compared, which reduces the amount of work we do and fixes an issue related to variance measurement of aliased deferred type references.Fixes #33872.