When using the kernel console, there's no such concept of title at all.
Also, this makes vim to crash the kernel due to dereferencing a null
pointer, so let's remove this as this is clearly not needed when using
the kernel virtual console.
Usually operations that mirror AOs from the Infra spec are simply part
of the underlying data structures in AK directly, but these don't seem
generally useful enough to add them as ByteBuffer methods.
Replacement conditions for `requires_argument` have been chosen based
on what would be most convenient for implementing an eventual optional
argument mode.
This fixes a misconception in our current `ArgsParser` implementation.
If `requires_argument` is false, it doesn't mean that the argument is
optional (i.e. "not required"). It means that there is no argument at
all.
Regexes for is_method and is_header_name did not escape the "-"
and unintentionally allowed for "," to be part of a
method/header name, not following the spec.
This commit escapes the "-" character to follow the spec.
In the main spec, [[UseGrouping]] can be true or false. In V3, it may be
one of:
auto: Respect the per-locale preference for grouping.
always: Ignore per-locale preference for grouping and always insert
the grouping separator (note: true is now an alias for always).
min2: Ignore per-locale preference for grouping and only insert the
grouping separator if the primary group has at least 2 digits.
false: Ignore per-locale preference for grouping and never insert
the grouping separator.
This contains minimal changes to parse newly added and modified options
from the Intl.NumberFormat V3 proposal, while maintaining main spec
behavior in Intl.NumberFormat.prototype.format. The parsed options are
reflected only in Intl.NumberFormat.prototype.resolvedOptions and the js
REPL.
Due to a missing `return` statement, we were creating two anonymous
wrapper blocks around each piece of inline content inside a flex
container.
This had no visual impact, since they ended up with 0x0 dimensions,
but we were wasting a fair bit of time running layout on them.
This takes care of two FIXMEs and fixes an issue on Google Docs where
we'd mix boxes from different documents in the same layout tree.
(This happened because shadow trees remained attached to their old
document when their host was adopted.)
While null StringViews are just as bad, these prevent the removal of
StringView(char const*) as that constructor accepts a nullptr.
No functional changes.
This prevents us from needing a sv suffix, and potentially reduces the
need to run generic code for a single character (as contains,
starts_with, ends_with etc. for a char will be just a length and
equality check).
No functional changes.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
Error::from_string_literal now takes direct char const*s, while
Error::from_string_view does what Error::from_string_literal used to do:
taking StringViews. This change will remove the need to insert `sv`
after error strings when returning string literal errors once
StringView(char const*) is removed.
No functional changes.
This commit moves the length calculations out to be directly on the
StringView users. This is an important step towards the goal of removing
StringView(char const*), as it moves the responsibility of calculating
the size of the string to the user of the StringView (which will prevent
naive uses causing OOB access).
These convenience templates allow the following to be written as before:
TRY(Core::System::pledge("promises..."));
TRY(Core::System::pledge("promises...", "execpromises..."));
TRY(Core::System::unveil("path", "permissions"));
TRY(Core::System::unveil(nullptr, nullptr));
Other uses must now append sv to any literal string passed to pledge and
unveil.
These were accidental (or leftover) uses of String::characters() to
construct StringViews through its StringView(char const*) constructor.
Since this constructor is due to be removed, this will no longer work.
Plus this prevents strlen from being run on these strings unnecessarily.
These are mostly minor mistakes I've encountered while working on the
removal of StringView(char const*). The usage of builder.put_string over
Format<FormatString>::format is preferrable as it will avoid the
indirection altogether when there's no formatting to be done. Similarly,
there is no need to do format(builder, "{}", number) when
builder.put_u64(number) works equally well.
Additionally a few Strings where only constant strings were used are
replaced with StringViews.
