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
Allow narrowing {}
originating in unknown
using instanceof
#51014
Conversation
src/compiler/checker.ts
Outdated
@@ -25721,7 +25721,9 @@ namespace ts { | |||
const nonConstructorTypeInUnion = find((rightType as UnionType).types, (t) => !isConstructorType(t)); | |||
if (!nonConstructorTypeInUnion) return type; | |||
} | |||
|
|||
if (assumeTrue && declaredType === unknownType && isEmptyAnonymousObjectType(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.
Perhaps this condition should be relaxed somehow or maybe it should be pushed further down the road to getNarrowedType
. This is the version that I'm most confident with though ;p
The added check is roughly based on the check recently introduced here: https://github.com/microsoft/TypeScript/pull/50610/files#diff-d9ab6589e714c71e657f601cf30ff51dfc607fc98419bf72e04f6b0fa92cc4b8R25153
|
||
// repro #51007 | ||
function isHTMLTable(table: unknown): boolean { | ||
return !!table && table instanceof Object && 'html' in table; |
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 think the test here should actually test for an access of table.html
in some capacity - e.g.
function tryGetHtmlPropFromTable(table: unknown) {
if (!!table && table instanceof Object && 'html' in table && table.html instanceof Object) {
return table.html;
}
return undefined;
}
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.
hm, what would it change here? the reported error was that in
couldn't be used at all in this situation - we could add more "assertions" here than what was originally reported but I'm not sure what this particular snippet would bring to the table here. What kind of nuance am I missing? 😅
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 original test is fine; having another test that actually tries to narrow and use the newly-tested property corresponds to something closer to real-world usage.
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, I've pushed out the proposed test case - please take a look if this is what you had in mind here.
# Conflicts: # src/compiler/checker.ts
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 what I think is the correct fix in #51631.
if (assumeTrue && declaredType === unknownType && isEmptyAnonymousObjectType(type)) { | ||
return targetType; | ||
} | ||
|
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 problem with conditioning this on the declared type is that it doesn't work when the empty anonymous object type originates in some other type. For example:
function f<T>(x: T & {}) {
return x instanceof Object && 'a' in x; // Error, but shouldn't be
}
Closing as superseded by #51631 |
fixes #51007