Skip to content

Fix emit issue regarding null/undefined in type annotations #11653

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

Merged
merged 5 commits into from
Oct 16, 2016
Merged

Conversation

rbuckton
Copy link
Contributor

When we compute and aggregate transform flags for a node, we were not detecting null or undefined as a type. As a result, the TypeScript transformation did not remove the type annotation for several nodes.

This change fixes the detection logic to correct the emit.

Fixes #11295

// CC: @mhegazy, @vladima

@@ -287,7 +287,7 @@ namespace ts {

case SyntaxKind.Constructor:
// TypeScript constructors are transformed in `visitClassDeclaration`.
Copy link
Contributor

Choose a reason for hiding this comment

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

is comment above still relevant?

if (node.questionToken
|| node.type
|| subtreeFlags & TransformFlags.ContainsDecorators
|| isThisIdentifier(name)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

can you add a test to check this condition?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The only new functionality is the test for node.type, which is covered by transformsElideNullUndefinedType

emitExpressionList(node, node.arguments, ListFormat.CallExpressionArguments);
}

function emitNewExpression(node: NewExpression) {
write("new ");
emitExpression(node.expression);
emitTypeArguments(node, node.typeArguments);
Copy link
Contributor

Choose a reason for hiding this comment

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

I can see why this is necessary, but do we have cases today when we need to emit type arguments or type annotations - asking because It will be nice to test this functionality

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Primarily it helped me catch other possible future errors.

@vladima
Copy link
Contributor

vladima commented Oct 15, 2016

👍


class C<T> {
m0(): null { return null; }
m1(): undefined { return undefined; }
Copy link
Contributor

Choose a reason for hiding this comment

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

can you also add tests for null and undefined in type position for parameters for methods, arrow functions, function expressions, and setters.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's what transformsElideNullUndefinedType does.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, misread your comment. I'll add tests for a few more scenarios.

@rbuckton rbuckton merged commit 65b1cf6 into master Oct 16, 2016
@rbuckton rbuckton deleted the fix11295 branch October 16, 2016 01:22
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Incorrect emits with function return type declarations
4 participants