The proposal is now on Stage 2.

See https://tc39.es/proposal-change-array-by-copy/

Added jit-test tests in change-array-by-copy.js

Add a build flag and shell flag for enabling change-array-by-copy methods.
The flags currently have no effect.

See https://tc39.es/proposal-change-array-by-copy/

Add self-hosted implementations for the new methods for TypedArrays.

Added jit-test tests in typed-array-change-by-copy.js

Depends on D126146

Add a self-hosting intrinsic for Object.is(); this is useful for
self-hosted TypedArray code in a future patch.

See https://tc39.es/proposal-change-array-by-copy/

 Add self-hosted implementations for the new methods for TypedArrays.

 Added jit-test tests in typed-array-change-by-copy.js

Depends on D127907

Backed out for causing spidermonkey build bustages on unscopables.js.

Push with failures

Failure log

Backout link

This reftests also failed on unscopables.js
Linux 18.04 x64 WebRender opt reftest failure log
Linux 18.04 x64 WebRender debug reftest failure log
Linux 18.04 x64 WebRender asan opt reftest failure log
OS X 10.15 WebRender opt reftest failure log
OS X 10.15 WebRender debug reftest failure log

I updated D127201 and D126146 to address the test failure and re-requested review.

https://hg.mozilla.org/mozilla-central/rev/118e645725d0
https://hg.mozilla.org/mozilla-central/rev/baf92822b1bf
https://hg.mozilla.org/mozilla-central/rev/dc52f8437ba0

This is getting backed out. Tim: I apologize. I'm truly baffled as to what has happened here.

Bug 1735775 was opened for an error in argument parsing. I'm not entirely clear what's up with that. More concerning however was failures that occurred in a Beta simulation that had nothing to do with your code. For example, ./mach jit-test basic/bug642206.js fails while trying to issue a JSMSG_OBJECT_REQUIRED_ARG error.

I've looked at it for a bit, and I can't make heads-or-tails of this at all, hence the backout.

What I know:

1. I can reproduce the failure if I do a local beta simulation update, (./mach try release -v 95.0b1 --tasks release-sim --migration central-to-beta --no-push && hg commit -m "Beta Changes") then build with ac_add_options --enable-update-channel=beta in my MOZCONFIG.
2. If I don't do the beta simulation update, but simply build with ac_add_options --enable-update-channel=beta, the failure does not reproduce.

I'm going to ni? Arai, as they might be able to shed some light on what's going on here. I've definitely missed something.

This is the link to the failing push: https://treeherder.mozilla.org/jobs?repo=try&revision=9f2264768078d6923a9c4e255a14686e99edf43d&selectedTaskRun=MpvAJkJpTw6wyzuIyAcnjQ.0

Backed out 3 changesets (Bug 1729563) as req by mgaudet (for causing Bug 1735775).
Backout link

will comment on phabricator revisons

Updated patches on phab to address requested changes, re-requested review.

Backed out for causing python failures.

Backout link: https://hg.mozilla.org/integration/autoland/rev/c5a7a3551be560818544440fb95d96ecd0f69df1

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=4376dd49267231ff4302b5a3c60027d59f94d760&selectedTaskRun=H-YjyTHFRUSNrifHBSuVOA.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=355704193&repo=autoland&lineNumber=780

Urk. I saw that failure in my verifying try push, and wrote it off as an intermittent infrastructure issue, as I was pretty sure we hadn't touched any python in this patch stack.

However, moz.build and moz.configure are python. I'm not entirely sure why this didn't fail on previous landing, perhaps new checking?

As near as I can tell, it's complaining about the fact that

# Enable change-array-by-copy
# ===================================================
@depends(milestone.is_nightly)
def use_change_array_by_copy(is_nightly):
    return False

doesn't actually depend on nightly...

I'm very sorry this patch stack has had such a hard time Tim.

Is there a reason why mach lint doesn't run the lint pass that failed in this case ( /builds/worker/checkouts/gecko/python/mozbuild/mozbuild/test/configure/lint.py )?

https://hg.mozilla.org/mozilla-central/rev/1994f6df5380
https://hg.mozilla.org/mozilla-central/rev/a1e3c3757169
https://hg.mozilla.org/mozilla-central/rev/95d6b5368d6f

Now this is at stage 3 the docs team have been looking at whether this is worth documenting.

BUT, there are a couple of issues.

1. It doesn't seem to work. I set javascript.options.experimental.enable_change_array_by_copy to true and then ran the code

   var sequence = [1, 2, 3];
   let reversedSequence = sequence.withReversed();
   

   I get an "is not a function" error on current FF (102) and nightly, and FF95.
2. The current ES3 modifies the names of these methods to toXxxx from withXxxx in https://github.com/tc39/proposal-change-array-by-copy/pull/50 - are we tracking that.
3. No one else seems to have documented it - ie. no obvious Chrome/Safari interest.

Is this too early to document? Why would this not work as above?

This one is a little different than others, as you need to build a version of the browser that has the code in it (see arai's comment here: https://phabricator.services.mozilla.com/D127201?id=496118#inline-706270). There may have been a reason why we wanted to be more cautious with this proposals than with others. If I recall correctly, we were concerned about the number of array methods being added and the potential of a performance regression.

To test this, you would need to create a custom build with ./mach build --enable-change-array-by-copy iiuc.

With regards to if this is ready -- The method names were already all updated. There are still some small issues being addressed at the upcoming plenary next week. Upcoming work: A potential issue will be verifying if the naming works -- as we frequently have collisions with userland libraries when adding new builtin methods.

We might want to discuss the strategy for stage 3 documentation. you can ping me on matrix and I can share some thoughts about this.