Skip to content

add support for nonnull jsdoc #36219

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

Closed
wants to merge 2 commits into from
Closed

Conversation

Kingwl
Copy link
Contributor

@Kingwl Kingwl commented Jan 16, 2020

Fixes #23405
Fixes #23217

@@ -21712,7 +21712,8 @@ namespace ts {
case SyntaxKind.ParenthesizedExpression: {
// Like in `checkParenthesizedExpression`, an `/** @type {xyz} */` comment before a parenthesized expression acts as a type cast.
const tag = isInJSFile(parent) ? getJSDocTypeTag(parent) : undefined;
return tag ? getTypeFromTypeNode(tag.typeExpression.type) : getContextualType(<ParenthesizedExpression>parent, contextFlags);
const type = tag ? getTypeFromTypeNode(tag.typeExpression.type) : getContextualType(<ParenthesizedExpression>parent, contextFlags);
return type && getJSDocNonNullTag(node) ? getNonNullableType(type) : type;
Copy link
Contributor

Choose a reason for hiding this comment

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

getJSDocNonNullTag should be limited to JS files

}
return checkExpression(node.expression, checkMode);
const type = tag ? checkAssertionWorker(tag, tag.typeExpression.type, node.expression, checkMode) : checkExpression(node.expression, checkMode);
return getJSDocNonNullTag(node) ? getNonNullableType(type) : type;
Copy link
Contributor

Choose a reason for hiding this comment

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

getJSDocNonNullTag should be limited to JS files

@@ -483,6 +483,7 @@ namespace ts {
JSDocTemplateTag,
JSDocTypedefTag,
JSDocPropertyTag,
JSDocNonNullTag,
Copy link
Contributor

Choose a reason for hiding this comment

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

LastJSDocNode and LastJSDocTagNode need to be adjusted

@@ -1622,6 +1626,10 @@ namespace ts {
return node.kind === SyntaxKind.JSDocTypeTag;
}

export function jsJSDocNonNullTag(node: Node): node is JSDocNonNullTag {
Copy link
Contributor

Choose a reason for hiding this comment

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

typo: js -> is

@@ -32376,7 +32375,7 @@ namespace ts {
if (getModifierFlags(member) & ModifierFlags.Ambient) {
continue;
}
if (isInstancePropertyWithoutInitializer(member)) {
if (isInstancePropertyWithoutInitializer(member) && !isNonNullPropertyWithJSDoc(member)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

is this the equivalent of a "definite assignment assertion" on properties?
If so, does this need to be expanded to variables as well?

@DanielRosenwasser
Copy link
Member

The way this works is kind of unfortunate because I don't think you can mix/match these with optional chaining the way we're changing in TypeScript 3.8. (@rbuckton)

So you can't easily convert to strictNullChecks by switching

a?.b.c

to

(/** @nonnull */ (a?.b)).c

@rbuckton
Copy link
Member

We could instead look for it in the trailing comments of a node:

a?.b/** @nonnull */.c

@ajafff
Copy link
Contributor

ajafff commented Jan 18, 2020

@DanielRosenwasser why would you ever want to use a nonnull assertion in an optional chain? There's another issue discussing whether to make that an error.
I just want to know if this is a valid use case that needs to be considered here

@DanielRosenwasser
Copy link
Member

@ajaff if you have a?.b.c, b might be undefined and you might not want to propagate that value out with another optional chain because you're asserting that it should be there - it's an error condition if it's not. So you might want to write a?.b!.c.

@ajafff
Copy link
Contributor

ajafff commented Jan 18, 2020

@DanielRosenwasser so you mean "Optional Chaining with Non-Null Assertions" that was discussed in #36138? Now I understand what you mean.


We could instead look for it in the trailing comments of a node

AFAICT that would require parsing JSDoc for every expression. In addition this requires the JSDoc parser to use the trailing comments (and store them in a separate place).
And on top of that, the checker needs to look for JSDoc on every expression when computing contextual types or actual types.

@Kingwl Kingwl closed this Jan 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants