add tests for base64 proposal

[bakkot]

Proposal repo.

It's only stage 2, so I'm marking this as a draft for now. I'm hoping to ask for stage 3 at the coming meeting, and that requires "sufficient" test262 tests (but they don't require approval by maintainers, so this review of this PR need to be rushed). Proposal is stage 3, this is ready for review/landing.

[bakkot]

The lint failure is silly - the new "uint8array-base64" feature presumably implies the existence of TypedArrays, so I don't think the "TypedArray" feature should need to be included.

I could do so anyway if it's too much trouble to fix the linter, I guess.

[linusg]

Something I noticed while reviewing the spec text for this is that bypassing ECMA-402's GetOption AO (which includes a ToString) and doing the validation manually using is not a String causes string objects to be rejected as option values - while I personally disagree with this choice I think it should be tested either way.

[bakkot]

Sure, I can add tests for that, though in any real implementation I would expect that to be covered by option-coercion tests, which confirm that ToString is not called.

(This behavior is very much intentional.)

[ljharb]

@bakkot features are often handled by an exclude list, not an include list, so a runner could exclude typed arrays and not know to exclude this one. it'd be good to add it in explicitly to the test files.

[bakkot]

Marked as ready for review since the proposal is now stage 3.

[ljharb]

Added (or verified) all the tests in this PR to my polyfill, which exposed a few minor bugs. LGTM!

[bakkot]

I've addressed comments and hopefully pleased the linter.

@ljharb I see you force-pushed to my branch but I have no idea what changes that included. I'm hoping it's just a rebase but I'm not reading a 10k line diff. I force-pushed over your changes, whatever they were.

[ljharb]

@bakkot oh, i just clicked the "rebase branch" button in the PR; i didn't change anything. fine to force push over.

[bakkot]

If you do "update with merge commit" instead of "update with rebase" it'll create a merge commit, which allows git pull --rebase, which is much friendlier. Since the PR will get squashed before merging to main anyway the merge commit will go away eventually.

[ljharb]

Merge commits are anathema, even on a PR, so that's not a good idea - git pull --rebase should work fine with a rebased branch.

[bakkot]

Sorry, --ff-only, maybe? One of them doesn't work with rebases, I'm pretty sure.

Anyway, the merge commits at least make it easy to tell that it's just an update of the branch, whereas that's not obvious when doing a rebase. Something to discuss elsewhere, though.

[anba]

Ideas for additional coverage:

• Whitespace between and after the padding character =, e.g. Uint8Array.fromBase64("Zg= =") and Uint8Array.fromBase64("Zg= = ").
• Uint8Array.prototype.setFrom{Base64,Hex} doesn't modify the typed array when the input string is invalid.
• Typed array is backed by a SharedArrayBuffer.
• lastChunkHandling option is present, but set to undefined, e.g. the options object is {lastChunkHandling: undefined}.
• lastChunkHandling option is an invalid string value, e.g. the options object is {lastChunkHandling: "bad"}.
• alphabet option is present, but set to undefined, e.g. the options object is {alphabet: undefined}.
• alphabet and lastChunkHandling options are read in the correct order.
• Extra bits with three element trailing chunk and strict chunk handling, e.g. Uint8Array.fromBase64("ZZZ=", {lastChunkHandling: "strict"}). (The two element chunk case is already covered.)