Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Conditional types #21316

Merged
merged 44 commits into from
Feb 3, 2018
Merged

Conditional types #21316

Changes from 1 commit
Commits
Show all changes
44 commits
Select commit Hold shift + click to select a range
57ca768
Initial implementation of conditional type operator
ahejlsberg Dec 5, 2017
063eed1
Add type relationships and distribute over union types
ahejlsberg Dec 8, 2017
ec2bdfd
Add 'T extends U' type operator
ahejlsberg Dec 12, 2017
43e195d
Clean up isGenericXXXType functions
ahejlsberg Dec 12, 2017
61225cc
Introduce TypeFlags.Instatiable
ahejlsberg Dec 13, 2017
9f74a7a
Rename TypeVariable to InstantiableType
ahejlsberg Dec 13, 2017
20434fa
Inference for conditional and extends type operators
ahejlsberg Dec 13, 2017
ddc631c
Fix typo
ahejlsberg Dec 13, 2017
000f121
Improve conditional type constraint checking
ahejlsberg Dec 13, 2017
27b945b
Handle constraints for distributive conditional types
ahejlsberg Dec 16, 2017
f59e2e6
Accept new baselines
ahejlsberg Dec 17, 2017
14590f1
Move JsxAttributes and MarkerType from TypeFlags to ObjectFlags
ahejlsberg Dec 18, 2017
100e4f6
Accept new baselines
ahejlsberg Dec 18, 2017
c5fd2f1
Parse xxx? as JSDoc type when not followed by token that starts type
ahejlsberg Dec 19, 2017
341c397
Accept new baselines
ahejlsberg Dec 19, 2017
3f4911f
Fix linting error
ahejlsberg Dec 20, 2017
abc8110
Merge branch 'master' into conditionalTypes
ahejlsberg Jan 3, 2018
bb23bb2
Propagate both TypeFlags and ObjectFlags in getSpreadType
ahejlsberg Jan 3, 2018
c10a552
Eagerly evaluate S extends T when S is definitely or definitely not a…
ahejlsberg Jan 14, 2018
53b1572
Revert to extends check being part of conditional type
ahejlsberg Jan 15, 2018
5094f76
Remove 'T extends U' type constructor
ahejlsberg Jan 15, 2018
925da86
Accept new baselines
ahejlsberg Jan 15, 2018
e8d1740
Introduce substitution types to use for constrained type parameters
ahejlsberg Jan 15, 2018
15baf0e
Accept new baselines
ahejlsberg Jan 15, 2018
9598acd
Properly handle 'any' and 'never' as conditional check type
ahejlsberg Jan 15, 2018
e96ec8c
Erase substitution types in type references and type alias instantiat…
ahejlsberg Jan 16, 2018
d52fa71
Optimize the sameMap function
ahejlsberg Jan 16, 2018
4ec6fdd
Merge branch 'master' into conditionalTypes
ahejlsberg Jan 17, 2018
fd0dd6e
Separate code path for conditional type instantiation
ahejlsberg Jan 18, 2018
c360c24
Fix parsing
ahejlsberg Jan 19, 2018
0e73240
Disallow conditional type following 'extends'
ahejlsberg Jan 19, 2018
5204fd5
Add T is related to { [P in xxx]: T[P] } type relationship
ahejlsberg Jan 20, 2018
eb314d0
Add tests
ahejlsberg Jan 20, 2018
cdd50d4
Accept new baselines
ahejlsberg Jan 20, 2018
fc7d1c3
Revise comments
ahejlsberg Jan 20, 2018
f19959a
Cache substitution types and remove erasure that was too eager
ahejlsberg Jan 20, 2018
b869290
Remove unnecessary caching of substitution types
ahejlsberg Jan 21, 2018
4c7ec3c
Shared code path for getConditionalType and instantiateConditionalType
ahejlsberg Jan 21, 2018
b42c6b1
Only conditional types that check naked type parameter distribute ove…
ahejlsberg Jan 24, 2018
8e337b5
Fix bug in resolveMappedTypeMembers
ahejlsberg Jan 24, 2018
4f2b5f3
Merge branch 'master' into conditionalTypes
ahejlsberg Jan 30, 2018
f990e4e
Merge branch 'master' into conditionalTypes
ahejlsberg Jan 30, 2018
01516c8
Update to use TypeFlags.Instantiable in instantiateSymbol
ahejlsberg Jan 30, 2018
d4dc67a
Merge branch 'master' into conditionalTypes
ahejlsberg Feb 3, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Parse xxx? as JSDoc type when not followed by token that starts type
  • Loading branch information
@ahejlsberg
ahejlsberg committed Dec 19, 2017
commit c5fd2f14f38d669f604f8cb40af8f3e0d747c600
9 changes: 7 additions & 2 deletions src/compiler/parser.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1477,6 +1477,11 @@ namespace ts {
return isStartOfExpression();
}

function nextTokenIsStartOfType() {
nextToken();
return isStartOfType();
}

// True if positioned at a list terminator
function isListTerminator(kind: ParsingContext): boolean {
if (token() === SyntaxKind.EndOfFileToken) {
Expand Down Expand Up @@ -2767,8 +2772,8 @@ namespace ts {
type = createJSDocPostfixType(SyntaxKind.JSDocNonNullableType, type);
break;
case SyntaxKind.QuestionToken:
// only parse postfix ? inside jsdoc, otherwise it is a conditional type
if (!(contextFlags & NodeFlags.JSDoc)) {
// If not in JSDoc and next token is start of a type we have a conditional type
if (!(contextFlags & NodeFlags.JSDoc) && lookAhead(nextTokenIsStartOfType)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to support conditional types in JSDoc for // @ts-check support?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might consider that, but I'm not sure to what extent we want to permit JSDoc that is only understood type TypeScript.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already support mapped and index types in jsdoc, right? Unless there's parse ambiguity, we should probably just continue exposing all type syntaxes in jsdoc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, we want to support all Typescript types in JSDoc. The ideal is for eager Typescript users to be able to put Typescript types into jsdoc if they are stuck with vanilla javascript for some reason.

However, I think there is a conflict between the ?-suffix of jsdoc and the ? of the conditional. For example, S extends JSDocType? ? never : any has both, but the parser will be unable to tell whether the first ? is a suffix or part of the conditional syntax.

I could be wrong, though! It’s really difficult to guess how the parser will behave without testing it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can always make the jsdoc postfix ? have a no-whitespace requirement and make the conditional ? have required whitespace in jsdoc to disambiguate, should it be ambiguous, yeah?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or we can do speculative parsing to see whether we can parse it as a ConditionalType (e.g. try to parse a true branch) and then fall back to postfix-?

return type;
}
type = createJSDocPostfixType(SyntaxKind.JSDocNullableType, type);
Expand Down