Repository navigation
Look through labeled rest elements when deferring recursive tuple types - #65314
Open
Shivashis Adhikari (shivashis-adhikari) wants to merge 3 commits into
Open
Shivashis Adhikari (shivashis-adhikari) wants to merge 3 commits into
Shivashis Adhikari (shivashis-adhikari) wants to merge 3 commits into
Conversation
The baselines show the current behavior: a labeled rest element such as '...rest: T[]' makes a recursive type alias report TS2456, while the same tuple without the label is accepted.
mayResolveTypeAlias decides whether a tuple type that may reference a type alias is deferred, which lets a type alias refer to itself through a tuple. An unlabeled rest element '...T[]' was checked by looking at T, but a labeled rest element '...name: T[]' is a NamedTupleMember, and that case only looked at the array type T[], for which the function returns false. The tuple was then resolved eagerly and reported a circular reference. A NamedTupleMember with a '...' token is now checked the same way as a RestType.
The labeled tuple types are now accepted like their unlabeled forms, and the invalid assignments to them report TS2322 instead of being unchecked.
|
Shivashis Adhikari (@shivashis-adhikari) please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
This branch has not been deployed
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.
Fixes #63584
Adding a label to a rest element made a recursive tuple type fail:
Cause
mayResolveTypeAliasdecides whether a tuple type is deferred, and deferral is what lets a type alias refer to itself through a tuple. For an unlabeled rest element...T[](aRestType) it checks the element typeT. A labeled rest element...rest: T[]is aNamedTupleMember, and that case passed the array typeT[]tomayResolveTypeAlias, which returns false for array types. The tuple was then resolved eagerly and hit the cycle. Because the alias then resolved toany, values assigned to it were no longer checked either.Fix
A
NamedTupleMemberwith a...token now goes through the same check as aRestType. The check moved into a small helper so both cases share itTests
recursiveTupleTypeLabeledRestElement.tscovers a labeled rest element on its own, after and before other labeled elements, with a parenthesized element type, in a union of tuples (the example from the issue), in a generic alias, and in a JSDoc@typedef. It also assigns valid and invalid values to each type, so the baselines show the types are checked again.The first commit adds the test with the current baselines which show the false TS2456 errors. The second commit is the fix, and the third updates the baselines.
Labeled and unlabeled rest elements already behaved the same for
...[T],...T[][]and...readonly T[]. This change does not affect those, and no existing baselines change.npx hereby validate --allpasses.AI disclosure: I've used Claude Code to help me with this. I have reviewed it and will respond to review feedback myself.