Add generic type coercion utility functions

[thejoshwolfe]

Add extremely thorough tests for the ? ToInteger(position) type coercion in String.prototype.indexOf. This is done mostly through generic code.

See #1197

I wanted to submit a PR just to get early feedback on my approach here.

[leobalter]

I like this, I left a few comments but we should be good to land this soon.

I'm currently on PTO so please be patient until I'm back in the next week. Someone else might be able to land this as well.

[leobalter]

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?

[leobalter]

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);
});

[thejoshwolfe]

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.)

[leobalter]

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.

[thejoshwolfe]

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.

[littledan]

@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.

[rwaldron]

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?

[littledan]

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.

[thejoshwolfe]

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

[thejoshwolfe]

@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.

[thejoshwolfe]

I threw in a test for the first parameter of String.prototype.indexOf and added some generic functions for testing coercion ToString. I'm pretty happy with how little effort it took to implement that.

If this is deemed to be too much creep in one PR, it's pretty easy to chop that commit off into its own PR. But I think for the sake of the generic utility functions, it's a good demonstration of the flexibility to have different entry points both making use of testCoercibleToPrimitiveWithMethod, for example.

I could add more entry points as well, such as ToIndex and ToLength, which will be useful for BigInt testing. Should we do those later or in this PR?

[thejoshwolfe]

I will also be on PTO for the next few business days.

[leobalter]

I like this harness. Would you like to write some unit tests for the new API?

cc @rwaldron any thoughts?

[thejoshwolfe]

Would you like to write some unit tests for the new API?

Yes! I didn't know unit tests were even a thing. Looks like they go in test/harness/. I'll add some to this PR.

[leobalter]

I didn't say anything before to allow an easier prototyping, but we maintain unit tests for the harness api as well.

[rwaldron]

This is now included in #1221