Move existing Temporal tests from tc39/proposal-temporal

[ptomato]

As discussed in #3002, this moves all the in-progress Temporal tests from tc39/proposal-temporal into here, so that it's more accessible to implementors. Further development is intended to happen here, as these tests will be removed from tc39/proposal-temporal (though they will still be executed using a git submodule).

[rwaldron]

@ptomato just a heads up that including console.warn in your polyfill code means we can't run the tests in hosts like jsc or v8.

[rwaldron]

@ptomato I removed the console.warns from the polyfill and ran all of these against that in JSC. The following tests fail in both strict and default execution. Can you either fix the failures or provide clarity (ie. known failure for whatever reason)? Thanks!

FAIL test/built-ins/Temporal/Calendar/prototype/fields/long-input.js
  Expected no error, got RangeError: invalid field name garbage 1  

FAIL test/built-ins/Temporal/Duration/compare/calendar-dateadd-called-with-options-undefined.js
  dateAdd shouldn't be called with options Expected SameValue(«[object Object]», «undefined») to be true

FAIL test/built-ins/Temporal/Duration/compare/relativeto-string-datetime.js
  date-time + IANA annotation is a zoned relativeTo Expected SameValue(«-1», «0») to be true

FAIL test/built-ins/Temporal/Duration/prototype/round/calendar-dateadd-called-with-options-undefined.js
  dateAdd shouldn't be called with options Expected SameValue(«[object Object]», «undefined») to be true

FAIL test/built-ins/Temporal/Duration/prototype/total/calendar-dateadd-called-with-options-undefined.js
  dateAdd shouldn't be called with options Expected SameValue(«[object Object]», «undefined») to be true

FAIL test/built-ins/Temporal/ZonedDateTime/prototype/since/calendar-dateadd-called-with-options-undefined.js
  dateAdd shouldn't be called with options Expected SameValue(«[object Object]», «undefined») to be true

FAIL test/built-ins/Temporal/ZonedDateTime/prototype/toLocaleString/options-conflict.js
  Expected no error, got TypeError: dateStyle and timeStyle may not be used with other DateTimeFormat options

FAIL test/built-ins/Temporal/ZonedDateTime/prototype/until/calendar-dateadd-called-with-options-undefined.js
  Expected no error, got RangeError: mixed-sign values not allowed as duration fields

[jugglinmike]

@rwaldron Philip would know better, but I believe the project's build262 script creates a version that's more suitable for use here.

[ptomato]

@rwaldron Thanks for the quick review!

For the console.warn, the way we run the tests against the polyfill is TEST262=1 npm run build to build a script.js without the console.warn, and then use that as the prelude in test262-harness. (I think you could also run it the same way you've been doing, but set globalThis.__test262__ = true before importing the polyfill.)

Here's what's going on with each of those failures:

• test/built-ins/Temporal/Calendar/prototype/fields/long-input.js: this test wasn't in this PR, it was already in the tree, and Sync test of Temporal.Calendar.p*.fields to 1750 #3188 should fix the failure.
• */calendar-dateadd-called-with-options-undefined.js: My bad, these shouldn't have been included yet. They were in-tree in proposal-temporal but ignored until Be consistent in whether calendar operations using default options are called with undefined or Object.create(null) proposal-temporal#1685 can be presented to TC39 for consensus. I'll remove these.
• test/built-ins/Temporal/ZonedDateTime/prototype/toLocaleString/options-conflict.js: I'm not sure what's going on with this one. It works for me running the tests with Node 16.10 (and support for dateStyle/timeStyle is fairly new in v8, I believe). I'll try to investigate what's going on with JSC and get back to you.

[ptomato]

@rwaldron I've removed the tests that were skipped in the proposal repo now. That leaves two failures; one addressed by the existing PR.

The other I've tracked down to a difference in JSC and v8:
v8 (via Node 16.10):

> new Intl.DateTimeFormat('en', {dateStyle:'short'}).resolvedOptions().year
undefined

JSC (as of a recent WebKit build):

> new Intl.DateTimeFormat('en', {dateStyle:'short'}).resolvedOptions().year
"2-digit"

It looks like JSC is not correctly implementing step 5.d of Intl.DateTimeFormat.prototype.resolvedOptions, which is causing a problem with the polyfill, but I believe this remaining test is correct as-is.

[rwaldron]

@ptomato thank you—that satisfies my review! Marking R+, with the understanding that we have a lot of work to do ahead of us, and getting this in sooner is the pragmatic thing to do 👍

[rwaldron]

The CI failure is unrelated to these changes.

[ptomato]

@rwaldron Thanks for the quick review, the help to get this in quickly is much appreciated. I think the next steps for me and @Ms2ger will be to continue to port coverage over from the proposal's legacy test suite (files such as https://github.com/tc39/proposal-temporal/blob/main/polyfill/test/instant.mjs) and then continue with the checklist in #3002.

If you have questions later about any of these tests, or find something that you wish you'd caught in the review, let me know and I will try to help. I realize this form of PR wasn't ideal for you.

I've reported the JSC bug as https://bugs.webkit.org/show_bug.cgi?id=231041