ArgsParser will now automatically look for an environment variable
'ARGSPARSER_EMIT_MARKDOWN', and if it is set to exactly the string "1"
(i.e. mere presence or values like "ON" or "yes" are not enough), then
ArgsParser will emit a Markdown-formatted help message, instead of the
regular help message designed for consumption through a terminal.
This also improves Commonmark coverage, e.g. it fixes tests
HTML_blocks_ex179_2894..2906 and Lists_ex308_5439..5457.
In other words, we go from 271 out of 652 to 273 out of 652.
This changes Web::Bindings::throw_dom_exception_if_needed() to return a
JS::ThrowCompletionOr instead of an Optional. This allows callers to
wrap the invocation with a TRY() macro instead of making a follow-up
call to should_return_empty(). Further, this removes all invocations to
vm.exception() in the generated bindings.
This allows supporting websites to use a light or dark theme to match
our desktop theme, without being limited to palette colors. This can be
overridden with the `WebContentServer::set_preferred_color_scheme()` IPC
call.
This explicitly states whether a given theme is a dark theme, so that
applications not using the system palette colors can still attempt to
match the overall theme.
This also required converting URLSearchParams::for_each and the callback
function it invokes to ThrowCompletionOr. With this, the ReturnType enum
used by WrapperGenerator is removed as all callers would be using
ReturnType::Completion.
DateTime::create() and subsequently DateTime::set_time() uses mktime()
internally to ensure out-of-range input values still result in a valid
date (Jan 32 -> Feb 1 etc.).
This however also means that the input is treated as local time, and
then shifted to UTC accordingly for the returned time_t - it is however
already in UTC in this case! The temporary solution is simply to set the
"TZ" environment variable to "UTC" and back after create(). The proper
solution is probably to have better timezone support in Core::DateTime.
This should only affect Lagom, as serenity itself has no timezone
support yet and always assumes UTC.
Just like in the previous commit, the day value of Core::DateTime is
one-based, not zero based.
Noticed while implementing a new Temporal function, this likely would've
been caught earlier if we'd also use it for the Date API (we don't).
Just like month, the day value here is one-based. This resulted in the
following situation, which is obviously unexpected:
Core::DateTime::create(1970); // 1970-01-00 -> 1969-12-31
When we receive HTTP payloads, we have to ensure that the number of
bytes read is *at most* the value specified in the Content-Length
header.
However, we did not use the correct value when calculating the truncated
size of the last payload. `m_buffered_size` does not store the total
number of bytes received, but rather the number of bytes that haven't
been read from us.
This means that if some data has already been read from us,
`m_buffered_size` is smaller than `m_received_size`. Because of this, we
ended up resizing the `payload` ByteBuffer to a larger size than its
contents. This garbage data was then read by consumers, producing this
warning when executing scripts:
> Extension byte 0xdc in 1 position after first byte 0xdc doesn't make
> sense.
