Having all spec comments verbatim on their own line with no additions
made by us will make it easier to automate comparing said comments to
their current spec counterparts.
While adding spec comments to PerformEval, I noticed we were missing
multiple steps.
Namely, these were:
- Checking if the host will allow us to compile the string
(allowing LibWeb to perform CSP for eval)
- The parser's initial state depending on the environment around us
on direct eval:
- Allowing new.target via eval in functions
- Allowing super calls and super properties via eval in classes
- Disallowing the use of the arguments object in class field
initializers at eval's parse time
- Setting ScriptOrModule of eval's execution context
The spec allows us to apply the additional parsing steps in any order.
The method I have gone with is passing in a struct to the parser's
constructor, which overrides the parser's initial state to (dis)allow
the things stated above from the get-go.
The spec notes that this AO is unused by ECMA-262, but is provided for
ECMAScript hosts. Move the definition to a common location to allow
test-js to also use it.
This is an editorial change in the Intl spec. See:
087995c233d29c
This also adds a missing spec link for the sanctioned units and fixes a
broken spec link for IsSanctionedSingleUnitIdentifier. In LibUnicode,
the NumberFormat generator is updated to use the constexpr helper to
retrieve sanctioned units.
This is an editorial change in the Temporal spec.
See: c5b645d
This means we now have to pass a global object and construct a BigInt
object just for the assertion, but oh well. We might want to have an
assertion macro that's optimized away in release builds at a later
point, however.
This removes a bunch of silly wrapping and unwrapping of Crypto
SignedBigInteger values in JS BigInt objects, which isn't even intended
by the spec - it just wants us to take an integer value, not a BigInt
specifically. Nice opportunity to remove a couple of allocations. :^)
This helps make the overall codebase consistent. `class_name()` in
`Kernel` is always `StringView`, but not elsewhere.
Additionally, this results in the `strlen` (which needs to be done
when printing or other operations) always being computed at
compile-time.
Day and month name constants are defined in numerous places. This
pulls them together into a single place and eliminates the
duplication. It also ensures they are `constexpr`.
`static const` variables can be computed and initialized at run-time
during initialization or the first time a function is called. Change
them to `static constexpr` to ensure they are computed at
compile-time.
This allows some removal of `strlen` because the length of the
`StringView` can be used which is pre-computed at compile-time.
It makes no sense to require passing a global object and doing a stack
space check in some cases where running out of stack is highly unlikely,
we can't recover from errors, and currently ignore the result anyway.
This is most commonly in constructors and when setting things up, rather
than regular function calls.
