maxmustermann/pulumi
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Transform the delete operator

Browse source 
This change does a rudimentary mapping of the delete operator.  I say
"rudimentary" because it's not entirely correct, ECMAScript-wise: delete
actually removes a property entirely from an object, whereas this change
simply transforms `delete <expr>` into `<expr> = null`.  Deciding what to
do with `delete` will be handled when we tackle the overall "unsupported
operators" bug, marapongo/mu#50, later on.  For `delete` specifically,
it's not clear we will want to allow deletion of properties on strongly
typed instances, however for untyped objects we can probably do this, and
then detect errors when downcasting to types requiring those properties.
This commit is contained in:
joeduffy 2017-01-12 15:06:50 -08:00
parent 5374a2e3fa
commit 49d0c2613a
1 changed files with 19 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
tools/mujs/lib/compiler/transform.ts
View file

@ -1223,7 +1223,7 @@ export class Transformer {
case ts.SyntaxKind.EqualsEqualsEqualsToken:
case ts.SyntaxKind.ExclamationEqualsEqualsToken:
log.out(3).info(
`ECMAScript operator ${ts.SyntaxKind[node.operatorToken.kind]} not supported; ` +
`ECMAScript operator '${ts.SyntaxKind[node.operatorToken.kind]}' not supported; ` +
`until marapongo/mu#50 is implemented, be careful about subtle behavioral differences`
);
break;
@ -1287,7 +1287,24 @@ export class Transformer {
}
private transformDeleteExpression(node: ts.DeleteExpression): ast.Expression {
return notYetImplemented(node);
if (log.v(3)) {
log.out(3).info(
`ECMAScript operator 'delete' not supported; ` +
`until marapongo/mu#50 is implemented, be careful about subtle behavioral differences`
);
}
// TODO[marapongo/mu#50]: we need to decide how to map `delete` into a runtime MuIL operator. It's possible
// this can leverage some dynamic trickery to delete an entry from a map. But for strong typing reasons,
// this is dubious (at best); for now, we will simply `null` the target out, however, this will cause
// problems down the road once we properly support nullable types.
return this.withLocation(node, <ast.BinaryOperatorExpression>{
kind: ast.binaryOperatorExpressionKind,
left: this.transformExpression(node.expression),
operator: "=",
right: <ast.NullLiteral>{
kind: ast.nullLiteralKind,
},
});
}
private transformElementAccessExpression(node: ts.ElementAccessExpression): ast.LoadExpression {