Repository navigation
Fix TS2367 false positive when comparing generic constructor types with concrete constructors - #64865
Closed
RXVEN-1907 (RXVEN-1907) wants to merge 1 commit into
Closed
RXVEN-1907 (RXVEN-1907) wants to merge 1 commit into
RXVEN-1907 (RXVEN-1907) wants to merge 1 commit into
Conversation
…th concrete constructors Signed-off-by: RXVEN-1907 <viswajeet2502@gmail.com>
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
Static review identified no blocking issues in the narrowly guarded fallback or regression baselines; tests were not run during this review.
No open issues 🎉
What changed in this PR
Fixes #27910 by allowing valid comparisons between generic constructor types and concrete constructors in the native TypeScript checker.
Changes:
- Adds a comparable-relation fallback for unconstrained target type parameters.
- Adds regression coverage for constructor comparisons while preserving errors for unrelated type parameters.
| File | Description |
|---|---|
tsc/internal/checker/relater.go |
Adds the guarded comparability fallback. |
tsc/testdata/tests/cases/compiler/comparableRelationTypeParameterTarget.ts |
Tests valid constructor and invalid unrelated-parameter comparisons. |
tsc/testdata/baselines/reference/compiler/comparableRelationTypeParameterTarget.types |
Records expected types. |
tsc/testdata/baselines/reference/compiler/comparableRelationTypeParameterTarget.symbols |
Records expected symbols. |
tsc/testdata/baselines/reference/compiler/comparableRelationTypeParameterTarget.errors.txt |
Records the remaining expected TS2367 diagnostic. |
Review effort: Balanced
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
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.
When comparing a generic constructor type against a concrete constructor, the checker reports TS2367 even though the comparison is valid:
func(Child)in the linked issue acceptsChildasConstructor<T>, soconstructor === Childcan legitimately be true. Reproduced on current main (7.1.0-dev) and on typescript@7.0.2:if (constructor === Child)fails with "the types 'Constructor' and 'typeof Child' have no overlap".The comparable relation already treats a type parameter appearing as the source as comparable through its constraint, but when a free type parameter appears as the target of a comparison (here:
Base<T>.Item: Tinside the constructor's return type), a non-type-parameter source is reported as having no overlap. That asymmetry only becomes visible when the type parameter is nested inside a property or a construct signature return type, because there the top-level equality check never retries in the other direction.This change adds the mirrored fallback: under the comparable relation, when the target is an unconstrained type parameter (its constraint is unknown), a non-type-parameter source is also checked against
unknown, so it is treated as potentially overlapping. Type parameters with an object constraint keep their current strict behavior, so the existing TS2352/TS2367 expectations ingenericTypeAssertions4/5andunknownControlFloware unchanged.I added
tests/cases/compiler/comparableRelationTypeParameterTarget.tswith its generated baseline, and ran the fullgo test ./...suite undertsc/locally with no failures.Disclosure: this PR was prepared with AI assistance and reviewed by me.
Fixes #27910