SonarCloud flagged this "Code Smell", where we are accessing these
static methods as if they are instance methods. While it is technically
possible, it is very confusing to read when you realize they are static
functions.
It's very common to encounter single-character strings in JavaScript on
the web. We can make such strings significantly lighter by having a
1-character inline capacity on the Vectors.
The position is added to manually in the line terminator and Unicode
character cases. While it checks for EOF after doing so, the EOF check
used `!=` instead of `<`, meaning if the position went _over_ the
source length, it wouldn't think it was EOF and would cause read buffer
overflows.
For example, `0xea` followed by `0xfd` would cause this.
VM now has a string cache which tracks all live PrimitiveStrings and
reuses an existing one if possible. This drastically reduces the number
of GC-allocated strings in many real-word situations.
This is just factoring out step "9. Set O.[[Prototype]] to V." of
10.1.2 [[SetPrototypeOf]] into its own method so that we don't have to
use internal_set_prototype_of() for setting an object prototype in all
cases.
Instead of setting it to the default object prototype and then
immediately setting it again via internal_set_prototype_of, we can just
set it directly in the parent constructor call.
Until we're confident that RequestServer doesn't need this runtime debug
dump helper, it's much nicer if everyone has it built in, so they can
simply send a SIGINFO if they see it acting up.
There are a handful of FIXME's here, but this seems generally good.
Note that CSS *values* don't get serialized in a spec-compliant way
since we currently rely on StyleValue::to_string() which is ad-hoc.
A flex-basis of zero doesn't actually mean that the preferred size of
the particular Box is 0. It means that the Box should take the least
amount of space possible while still accomodating the content inside.
We catch and circumvent this now right when the flex-basis property gets
read for the FlexFormattingContext.
This isn't mentioned anywhere in the seemingly relevant portions of the
spec, however thanks to this answer https://stackoverflow.com/a/47579078
(which is not entirely correct about width either) lead to the behavior
that is wanted and used by other Browsers.
While not complete by any means, we are now compatible with the [level 3
spec](https://www.w3.org/TR/css3-mediaqueries/#syntax) and some parts of
[level 4.](https://www.w3.org/TR/mediaqueries-4#mq-syntax)
Compatibility with level 4+ requires:
- Implementing the range syntax: `(800px <= width <= 1200px)`
- Parsing `<general-enclosed>`, which represents syntax that is not yet
used but they may use in the future.
Parsing media queries sometimes requires significant back-tracking, so
`reconsume_current_input_token()` was not good enough.
`rewind_to_position()` lets you reconsume an erbitrary number of tokens
to return to an earlier point in the stream, which you previously saved
from `TokenStream::position()`.
This now matches the spec, and fixes the situation where if it was given
a TokenStream of StyleComponentValueRules, it would drop any Blocks on
the floor instead of adding them to the result StyleRule.
This is a list of MediaQuery objects. Not to be confused with
`MediaQueryList`, which is concerned with firing events when a media
query's match-state changes.
If an element has a relative specified length on the cross axis, but in
the lineage there are no parents that have any fixed cross size, this
would have resulted in a 0 cross size.
We now catch that and check whether the relative length would result in
an actual definite length if resolved.
