Add missing Array and TypedArray prototype properties to environment

[0xedward]

Although ProbingMutator can probably find these properties, I thought it might be a good idea to give CodeGenMutator a chance to also generate code with the following properties:

• https://262.ecma-international.org/14.0/#sec-array.prototype.findlast

• https://262.ecma-international.org/14.0/#sec-array.prototype.findlastindex

• https://262.ecma-international.org/14.0/#sec-array.prototype.toreversed

• https://262.ecma-international.org/14.0/#sec-array.prototype.tosorted

• https://262.ecma-international.org/14.0/#sec-array.prototype.tospliced

• https://262.ecma-international.org/14.0/#sec-array.prototype.with

• https://262.ecma-international.org/14.0/#sec-%typedarray%.prototype.at

• https://262.ecma-international.org/14.0/#sec-%typedarray%.prototype.findindex

• https://262.ecma-international.org/14.0/#sec-%typedarray%.prototype.findlastindex

• https://262.ecma-international.org/14.0/#sec-%typedarray%.prototype.toreversed

• https://262.ecma-international.org/14.0/#sec-%typedarray%.prototype.tosorted

[saelo]

Thanks a lot! Just one comment. Maybe just drop the first commit of this chain?

[0xedward]

Thanks for the review, Samuel! Just to make sure - do you mean this commit, 25efa6e?

If so, I made those changes since it seems like the index parameter for Array.prototype.at accepts any type, which will be coerced to integer for the operation. I thought specifying .anything for the index parameter would result in a larger set of possible inputs for fuzzing than having index typed to only accept integers.

I'm happy to make the change :), but I wanted to double check before dropping the commit and also changing the type information for TypedArray.prototype.at in d4e15eb.

[saelo]

Ah sorry, I realize my review comment hadn't been released, my bad...

Yeah we should document this approach better. I guess a rule of thumbs would be that if the documentation says something like "parameter will be converted to X" than we want type X in our signature. JavaScript is loosely typed so will usually try to convert whatever it gets to the desired type, but for the majority of possible values, that type conversion will be fairly meaningless (e.g. result in NaN) so we don't want to have a ton of those samples. The generative engine (which is the only thing using these signatures) should try to generate correct and meaningful code, and the mutators will take care of e.g. flipping inputs to call functions with unexpected/different values.

[saelo]

I think we'd want to keep .integer here. You're correct, and we could pass any type here, but here we generally try to capture "meaningful" signatures and not just "valid" ones. So for at we'd usually want to pass an integer. If we pass any other value, the chance of it getting converted to NaN (and then I guess to index 0) is very high, so we wouldn't really be generating meaningful code here.
The mutators (in particular, the InputMutator) will take care of changing the input types, and if that's interesting (e.g. increases coverage) we'll still keep it and mutate it further.

[0xedward]

Ah sorry, I realize my review comment hadn't been released, my bad...

No problem, I can relate - I've been burned many times by the draft comment feature lol

JavaScript is loosely typed so will usually try to convert whatever it gets to the desired type, but for the majority of possible values, that type conversion will be fairly meaningless (e.g. result in NaN) so we don't want to have a ton of those samples.

The mutators (in particular, the InputMutator) will take care of changing the input types, and if that's interesting (e.g. increases coverage) we'll still keep it and mutate it further.

Oh I see, that makes sense that we want to generate meaningful inputs otherwise the search space might be too large, and then leave it up to other mutators to mutate the index parameter.

Thanks for taking the time to share the rationale behind why it's better to have a more narrow type here :)

I guess a rule of thumbs would be that if the documentation says something like "parameter will be converted to X" than we want type X in our signature.

I'll keep that in mind for future PRs

[saelo]

I think the first parameter should also be a .integer here since it should be an index IIUC

[0xedward]

Oh right, I think it should be .integer. Sorry I missed that earlier. I also missed that TypedArrays have a with method too, so I added that method's type information in the latest change

[saelo]

Awesome, thanks a lot!