Skip to content
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

Add generic type coercion utility functions #1200

Closed
wants to merge 4 commits into from
Closed
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
254 changes: 254 additions & 0 deletions harness/typeCoercion.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,254 @@
// Copyright (C) 2017 Josh Wolfe. All rights reserved.
// This code is governed by the BSD license found in the LICENSE file.
/*---
description: |
Functions to help generate test cases for testing type coercion abstract
operations like ToNumber.
---*/

function getValuesCoercibleToIntegerZero() {
var result = [];

var primitiveValues = [
// ToNumber
null,
false,
0,
"0",

// ToInteger: NaN -> +0
undefined,
NaN,
"",
"foo",
"true",

// ToInteger: floor(abs(number))
0.9,
-0,
-0.9,
"0.9",
"-0",
"-0.9",
];
Copy link
Member

Choose a reason for hiding this comment

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

I don't quite understand the phrasing here. A particular test which uses this function will then use the values for a particular parameter, which is cast in a particular way. Wouldn't it make more sense to have distinct functions for getting values that coerce to zero via ToInteger, via ToLength, etc? Seems like this function implements the ToInteger one (should that figure into the name?); for ToLength, for example, you could also include -10, and for ToNumber, you would remove many of these.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Does the latest commit clarify the situation or make it more obscure? 2bcee86


// ToPrimitive
primitiveValues.forEach(function(zero) {
result.push(zero);
result = result.concat(getPrimitiveWrappers(zero, "number"));
});

// Non-primitive values that coerce to 0:
// toString() returns a string that parses to NaN.
result = result.concat([
{},
[],
]);

return result;
}

function getValuesCoercibleToIntegerOne() {
var result = [];

var primitiveValues = [
// ToNumber
true,
1,
"1",

// ToInteger: floor(abs(number))
1.9,
"1.9",
];

// ToPrimitive
primitiveValues.forEach(function(value) {
result.push(value);
result = result.concat(getPrimitiveWrappers(value, "number"));
});

// Non-primitive values that coerce to 1:
// toString() returns a string that parses to 1.
result = result.concat([
[1],
["1"],
]);

return result;
}

function getValuesCoercibleToIntegerFromInteger(nominalInteger) {
assert(Number.isInteger(nominalInteger));
var result = [];

var primitiveValues = [ nominalInteger ];

// ToInteger: floor(abs(number))
if (nominalInteger >= 0) {
primitiveValues.push(nominalInteger + 0.9);
}
if (nominalInteger <= 0) {
primitiveValues.push(nominalInteger - 0.9);
}

// ToNumber: String -> Number
primitiveValues = primitiveValues.concat(primitiveValues.map(function(number) { return number.toString(); }));

// ToPrimitive
primitiveValues.forEach(function(value) {
result.push(value);
result = result.concat(getPrimitiveWrappers(value, "number"));
});

// Non-primitive values that coerce to the nominal integer:
// toString() returns a string that parsers to a primitive value.
result = result.concat(primitiveValues.map(function(number) { return [number]; }));

return result;
}

function getPrimitiveWrappers(primitiveValue, hint) {
assert(hint === "number" || hint === "string");
var result = [];

if (primitiveValue != null) {
// null and undefined result in {} rather than a proper wrapper,
// so skip this case for those values.
result.push(Object(primitiveValue));
}

result = result.concat(getValuesCoercibleToPrimitiveWithMethod(hint, function() {
return primitiveValue;
}));
return result;
}

function getValuesCoercibleToPrimitiveWithMethod(hint, method) {
var methodNames;
if (hint === "number") {
methodNames = ["valueOf", "toString"];
} else {
methodNames = ["toString", "valueOf"];
}
return [
// precedence order
{
[Symbol.toPrimitive]: method,
Copy link
Member

Choose a reason for hiding this comment

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

So, we have a need - and a plan - to flag files using ES6+ features, but how do we do this using a harness file? Maybe using the features flag here in this file for Symbol.toPrimitive? cc @rwaldron

We don't have this requirement for harness files, but it would be nice to add an info tag with the ToInteger and ToNumber operations. This can be done in a follow up for sure.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Some ideas:

  1. Just blaze ahead without flagging the features. This is done in this PR for Symbol.toPrimitive and in harness/testAtomics.js
  2. Try to have the JavaScript behave differently if features are available at runtime. This is what I did with BigInt in this PR.
  3. Harness files declare feature dependencies, and those feature dependencies are implicitly brought in by any test that includes the harness file.

Copy link
Member

Choose a reason for hiding this comment

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

@leobalter I think the feature flags for ES6 features are most useful when adding the feature to the test suite initially. At this point, Symbol.toPrimitive is implemented in most engines, and it's difficult to add ever in the future in transpilers, so I'm not sure it's the highest-priority feature flag to get perfectly right.

Copy link
Contributor

Choose a reason for hiding this comment

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

Just blaze ahead without flagging the features.

This is problematic for consumers of test262 that want to target their test runs while developing specific features.

Harness files declare feature dependencies, and those feature dependencies are implicitly brought in by any test that includes the harness file.

This is problematic for consumers of test262 that expect all test files to have the full meta information available in the test file itself.


Try to have the JavaScript behave differently if features are available at runtime. This is what I did with BigInt in this PR.

Can you elaborate on this?

[methodNames[0]]: function() { throw new Test262Error(); },
[methodNames[1]]: function() { throw new Test262Error(); },
}, {
[methodNames[0]]: method,
[methodNames[1]]: function() { throw new Test262Error(); },
}, {
[methodNames[1]]: method,
},

// GetMethod: if func is undefined or null, return undefined.
{
[Symbol.toPrimitive]: undefined,
[methodNames[0]]: method,
[methodNames[1]]: method,
}, {
[Symbol.toPrimitive]: null,
[methodNames[0]]: method,
[methodNames[1]]: method,
},

// if methodNames[0] is not callable, fallback to methodNames[1]
{
[methodNames[0]]: null,
[methodNames[1]]: method,
}, {
[methodNames[0]]: 1,
[methodNames[1]]: method,
}, {
[methodNames[0]]: {},
[methodNames[1]]: method,
},

// if methodNames[0] returns an object, fallback to methodNames[1]
{
[methodNames[0]]: function() { return {}; },
[methodNames[1]]: method,
}, {
[methodNames[0]]: function() { return Object(1); },
[methodNames[1]]: method,
},
];
}

function getValuesNotCoercibleToInteger() {
// ToInteger only throws from ToNumber.
return getValuesNotCoercibleToNumber();
}
function getValuesNotCoercibleToNumber() {
var result = [];

// ToNumber: Symbol -> TypeError
var primitiveValues = [
Symbol("1"),
];
if (typeof BigInt !== "undefined") {
Copy link
Contributor Author

@thejoshwolfe thejoshwolfe Aug 29, 2017

Choose a reason for hiding this comment

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

@rwaldron this is what I mean by checking if the feature is enabled at runtime. Something similar could be done for typeof Symbol !== "undefined" and even typeof Symbol.toPrimitive !== "undefined" perhaps. And in the event they are undefined, then skip the parts of the test that use the features.

// ToNumber: BigInt -> TypeError
primitiveValues.push(BigInt(0));
}
primitiveValues.forEach(function(value) {
result.push({error:TypeError, value:value});
getPrimitiveWrappers(value, "number").forEach(function(value) {
result.push({error:TypeError, value:value});
});
});

// ToPrimitive
result = result.concat(getValuesNotCoercibleToPrimitive("number"));

return result;
}

function getValuesNotCoercibleToPrimitive(hint) {
function MyError() {}

var result = [];

var methodNames;
if (hint === "number") {
methodNames = ["valueOf", "toString"];
} else {
methodNames = ["toString", "valueOf"];
}

// ToPrimitive: input[@@toPrimitive] is not callable (and non-null)
result.push({error:TypeError, value:{[Symbol.toPrimitive]: 1}});
result.push({error:TypeError, value:{[Symbol.toPrimitive]: {}}});

// ToPrimitive: input[@@toPrimitive] returns object
result.push({error:TypeError, value:{[Symbol.toPrimitive]: function() { return Object(1); }}});
result.push({error:TypeError, value:{[Symbol.toPrimitive]: function() { return {}; }}});

// ToPrimitive: input[@@toPrimitive] throws
result.push({error:MyError, value:{[Symbol.toPrimitive]: function() { throw new MyError(); }}});

// OrdinaryToPrimitive: method throws
result = result.concat(getValuesCoercibleToPrimitiveWithMethod(hint, function() {
throw new MyError();
}).map(function(value) {
return {error:MyError, value:value};
}));

// OrdinaryToPrimitive: both methods are unsuitable
var unsuitableMethods = [
// not callable:
null,
1,
{},
// returns object:
function() { return Object(1); },
function() { return {}; },
];
unsuitableMethods.forEach(function(method) {
result.push({error:TypeError, value:{valueOf:method, toString:method}});
});

return result;
}
30 changes: 30 additions & 0 deletions test/built-ins/String/prototype/indexOf/position-tointeger.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
// Copyright (C) 2017 Josh Wolfe. All rights reserved.
// This code is governed by the BSD license found in the LICENSE file.
/*---
esid: sec-string.prototype.indexof
description: String.prototype.indexOf type coercion for position parameter
info: >
String.prototype.indexOf ( searchString [ , position ] )

4. Let pos be ? ToInteger(position).

includes: [typeCoercion.js]
---*/

getValuesCoercibleToIntegerZero().forEach(function(zero) {
assert.sameValue("aaaa".indexOf("aa", zero), 0, "with value " + zero);
});
Copy link
Member

Choose a reason for hiding this comment

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

this is interesting. I like it when I read this code and this PR is an evidence I was wrong and not sure this would work.

It also seems like getValuesCoercibleToIntegerZero, getValuesCoercibleToIntegerOne, and getValuesNotCoercibleToInteger can become static arrays. There's no need to call them or produce anything. This would also reduce the complexity for unit tests of the own harness. The names can also be simple as ToIntegerZero, ToIntegerOne, and ToIntegerNotCoercible.

What do you think?

Copy link
Member

Choose a reason for hiding this comment

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

As an alternative, calling getValuesCoercibleToIntegerZero() could replace the own forEach call.

i.e.:

valuesCoercibleToIntegerZero(function(zero) {
  assert.sameValue("aaaa".indexOf("aa", zero), 0, "with value " + zero);
});

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I like the idea of passing in a callback instead of using forEach. One problem I had while developing these tests is when there was a failure (due to me misreading the spec), it was difficult to determine which test case was causing the problem. It makes a lot of sense to design the test cases so that stack traces are as useful as possible. It was pretty amusing to try to debug print values like {valueOf() { throw new MyError(); }}, because every attempt at stringification would throw. Useful stack traces seem like a much more practical solution to the problem than stringifying the object.

I'm a huge fan of long and clear variable names, but I know I'm an outlier in that regard. One concern here is that the functions are exposed at global scope, so I want their full purpose to be in the variable name. I'm also a bit concerned with publishing the helper functions I wrote in the harness file. So perhaps a solution could be exposing an exports object where the name of the object gives context. Perhaps something like CoercionUtils.ToIntegerZero. (Now that I write that, I see it's just as long as the original name. Maybe this isn't the best idea.)


getValuesCoercibleToIntegerOne().forEach(function(one) {
assert.sameValue("aaaa".indexOf("aa", one), 1, "with value " + one);
});

getValuesCoercibleToIntegerFromInteger(2).forEach(function(two) {
assert.sameValue("aaaa".indexOf("aa", two), 2, "with value " + two);
});

getValuesNotCoercibleToInteger().forEach(function(pair) {
var error = pair.error;
var value = pair.value;
assert.throws(error, function() { "".indexOf("", value); });
});