Implements compilation of the delete operator

[TobiasWienand]

This branches enables compilation of the delete operator. Some thoughts I think are worth mentioning

1)

With this change, approximately 300 new seeds from test/mjsunit and the SpiderMonkey JIT test files will become compilable. If Fuzzilli treats the delete operation as a standard unary operator, delete might be applied to non-object properties, such as simple variables (var). If I understand correctly, semantic correctness will not be significantly impacted because delete does not cause a crash when called on unintended targets. For example, if applied to var, let, or parameters, it simply returns false and has no effect.

2)

It can happen that an object has a key that is a number. In that case DeleteElement will be called, even though it is not an array.
Example:

const obj = { 1: 'value' };
delete obj[1];

Similarly, we can delete elements from an array based on a computed index - in that case DeleteComputedProperty is called, not DeleteElement.

Example

const arr = [1, 2, 3];
delete arr[Math.floor(Math.random() * arr.length)];

Is that a problem? IIUC, the main difference between DeleteElement and Delete(Computed)Property In FuzzIL is only syntactical, not semantical.

[saelo]

Nice! Overall looks good already, with a few suggestions

[saelo]

I think this could use a comment. I guess you are effectively turning

delete a?.b;

into

try { delete a.b; } catch {}

?
I think that makes sense, but a short comment might be nice :)

[TobiasWienand]

Here is an example of before and after:

Before

const nestedObj = { a: { b: 2 } };
delete nestedObj.a?.c;

After

const o1 = {
    "b": 2,
};
const o2 = {
    "a": o1,
};
o2.a?.c;
const t6 = o2.a;
delete t6?.c;

So, no try catch enveloping which is nice in my opinion :)

[saelo]

Looks good! Though were does the o2.a?.c; line come from? Is that maybe a bug in our lifting, or is that property access also there in the IL?

[TobiasWienand]

Ah yes, good catch! This happened because

let argument = try compileExpression(unaryExpression.argument)
was called, even though argument was not used in the delete case. This is fixed now. I will be looking more carefully at the FuzzIL translation in the future!

[saelo]

Regarding you comments:

1. So IIUC we currently cannot compile something like delete a because that's not a MemberExpression? It's probably not super important, but maybe it's easy enough to fix. We could either add a DeleteName instruction, or, probably even simpler, just compile delete a to a delete this.a (which IIUC is effectively what it's doing). WDYT?

2. I think this all works correctly the way you describe/implemented it. delete x[1] should always be a DeleteElement and delete x[foo] should always be a DeleteComputedProperty, regardless of what the object or the computed property name is.

[TobiasWienand]

Regarding 1), I initially had this in the code, but then I found out that an implicit global variable does not become a property of this in all engines. For example, in Node.js, it becomes a property of global. I am not sure how this is handled in other JS engines, so I avoided it. Also, another problem would be to distinguish between implicit global variables and let, var, etc. The data structure that is processed by Compiler.swift only says that it is an identifier and what name it has.

I did a quick check of how many files in test/mjsunit/* have delete but are not compilable. We are talking about 28 files, and therefore they are in position 12 on the priority list. So perhaps it is best not to invest time in this right now and come back to it later.

[saelo]

Maybe also add a test for something like

try {
    delete null.a;
} catch(e) {
    console.log(e.message);
}
console.log(delete null?.a);

[TobiasWienand]

This is compilable. However, this would cause DeleteProperty to be called, even though null is not an object. In Compiler.swift, I believe it is currently not possible to check here if obj is truly an object. We could either

• Try preventing this in parser.js, although there are possibly more edge cases than just this
• Ignore it and add a TODO
• Introduce a new DeleteAny JSOperation

What would you prefer?

[saelo]

Looks good! Though were does the o2.a?.c; line come from? Is that maybe a bug in our lifting, or is that property access also there in the IL?

[saelo]

Cool, just a question and one more suggestion. And sounds good, let's not bother with delete a stuff for now :)