-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Replace missingType
with undefinedType
in the IndexedAccessTypeNode
's type
#52016
Conversation
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.
Looks like a good fix for the observed bug, but it might be have undesired effects for other indexTypes.
@@ -16856,6 +16856,8 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker { | |||
const propType = getTypeOfSymbol(prop); | |||
return accessExpression && getAssignmentTargetKind(accessExpression) !== AssignmentKind.Definite ? | |||
getFlowTypeOfReference(accessExpression, propType) : | |||
accessNode && isIndexedAccessTypeNode(accessNode) ? | |||
mapType(propType, type => type === missingType ? undefinedType : 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.
this is a good fix for the problem encountered here, and probably for most cases when referencing a single property, but I think it might have undesired effects for cases where the indexType is a union of property names, especially something like keyof T
.
Am I wrong? Does it still make sense to turn missing into undefined there too? @weswigham I'd like your advice on this.
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.
But even in such cases - we just end up distributing~ the indexType over objectType. Essentially it's the same as T['a'] | T['b'] | ...
. So the open question is - is there any case for which indexed access type should "transfer" the optionality~ into the target type? The only operation that should do it, that I know of, involved homomorphic mapped types - and in this case, indexed access types are not involved directly.
src/compiler/checker.ts
Outdated
return accessExpression && getAssignmentTargetKind(accessExpression) !== AssignmentKind.Definite ? | ||
getFlowTypeOfReference(accessExpression, propType) : |
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.
now that this has multiple entries, can you format it cond-style? Like so:
return cond1 ? cons2
: cond2 ? cons2
: default;
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.
done #prettierwhereareyou 😉
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.
This looks pretty reasonable to me, but @RyanCavanaugh should probably sign off, since he's probably got the most complete mental model for how missingType
is supposed to work.
It looks like you've sent a pull request to update our 'lib' files. These files aren't meant to be edited by hand, as they consist of last-known good states of the compiler and are generated from 'src/lib' or possibly our lib generator. Unless this is necessary, consider closing the pull request and sending a separate PR to update 'src/lib' or https://github.com/microsoft/TypeScript-DOM-lib-generator |
Sorry, the bot is off the rails. We've asked the team owning it to investigate. |
@typescript-bot test this |
Heya @RyanCavanaugh, I've started to run the perf test suite on this PR at ea832bf. You can monitor the build here. Update: The results are in! |
Heya @RyanCavanaugh, I've started to run the diff-based top-repos suite on this PR at ea832bf. You can monitor the build here. Update: The results are in! |
Heya @RyanCavanaugh, I've started to run the diff-based user code test suite on this PR at ea832bf. You can monitor the build here. Update: The results are in! |
Heya @RyanCavanaugh, I've started to run the parallelized Definitely Typed test suite on this PR at ea832bf. You can monitor the build here. |
Heya @RyanCavanaugh, I've started to run the diff-based top-repos suite (tsserver) on this PR at ea832bf. You can monitor the build here. Update: The results are in! |
Heya @RyanCavanaugh, I've started to run the extended test suite on this PR at ea832bf. You can monitor the build here. |
Heya @RyanCavanaugh, I've started to run the diff-based user code test suite (tsserver) on this PR at ea832bf. You can monitor the build here. Update: The results are in! |
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.
The code seems fine to me; if the test results come back clean we can merge this
@RyanCavanaugh Here are the results of running the user test suite comparing Everything looks good! |
@RyanCavanaugh Here are the results of running the user test suite comparing Everything looks good! |
Heya @RyanCavanaugh, I've run the RWC suite on this PR - assuming you're on the TS core team, you can view the resulting diff here. |
@RyanCavanaugh Here they are:
CompilerComparison Report - main..52016
System
Hosts
Scenarios
TSServerComparison Report - main..52016
System
Hosts
Scenarios
StartupComparison Report - main..52016
System
Hosts
Scenarios
Developer Information: |
@RyanCavanaugh Here are the results of running the top-repos suite comparing Everything looks good! |
@RyanCavanaugh Here are the results of running the top-repos suite comparing Everything looks good! |
fixes #51953
cc @sandersn