Before this change, we were going through the chain of base classes for
each IDL interface object and having them set the prototype to their
prototype.
Instead of doing that, reorder things so that we set the right prototype
immediately in Foo::initialize(), and then don't bother in all the base
class overrides.
This knocks off a ~1% profile item on Speedometer 3.
The fast path of to_i32() can be neatly inlined everywhere, and we still
have to_i32_slow_case() for non-trivial conversions.
For to_u32(), it really can just be implemented as a static cast to i32!
Add support for AES-KW for key wrapping/unwrapping. Very similar
implementation to other AES modes.
Added generic tests for symmetric import and specific AES-KW ones.
Adds ~400 test passes on WPT. Now we do better than Firefox in
`WebCryptoAPI/wrapKey_unwrapKey`!
This implements the last WebCryptoAPI methods `wrapKey` and `unwrapKey`.
Most of the functionality is already there because they rely on
`encrypt` and `decrypt`. The only test failures are for `AES-GCM` which
is not implemented yet.
I dug through the code and the WebCryptoAPI spec to figure out the
reason for `... mixed case parameters` WPT tests and figured out that
our implementation was slightly wrong.
By being closer to the spec we can now pass those tests and also remove
a bunch of duplicated code.
Context: https://github.com/LadybirdBrowser/ladybird/pull/2598#discussion_r1859263798
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
None of the algorithms actually set the `extractable` internal slot in
their implementations, and looking at `SubtleCrypto::import_key()` it
seems likely that a step is missing here.
The main motivation behind this is to remove JS specifics of the Realm
from the implementation of the Heap.
As a side effect of this change, this is a bit nicer to read than the
previous approach, and in my opinion, also makes it a little more clear
that this method is specific to a JavaScript Realm.
