There are actually a couple of issues here:
1. We are not properly perfect-forwarding the iterable to the Enumerator
member. We are using the class template as the constructor type, but
we would actually have to do something like this to achieve perfect
forwarding:
template <typname Iter = Iterable>
Enumerator(Iter&&)
2. The begin / end methods on Enumerator (although they return by const-
ref) are making copies during for-each loops. The compiler basically
generates this when we call enumerate:
for (auto it = Enumerator::begin(); it != Enumerator::end(); ++it)
The creation of `it` above actually creates a copy of the returned
Enumerator instance.
To avoid all of this, let's create an intermediate structure to act as
the enumerated iterator. This structure does not hold the iterable and
thus is fine to copy. We can then let the compiler handle forwarding
the iterable to the Enumerator.
Cherry-picked from:
0edcd19615
These take a numerator and denominator defining the unit in a fractions
of a second. Conversion is done in integers, meaning that these must
clamp when approaching numeric limits.
This will format Duration as seconds, with as much decimal precision as
necessary to fully represent its value. The alternate format specifier
can be used to make it print the units on the end, i.e. "1.23s".
We could never hit the #else branches for some of these methods, because
we already relied on having __builtin_*_overflow() readily available in
earlier methods.
multiplication_would_overflow() with three arguments was only used in a
test, so let's get rid of that as well.
Instead of repeatedly removing elements off the vector, this allows for
specifying all the removed indices at once, and does not perform any
extra reallocations or unnecessary moves.
Copy parse() method from LibCore::DateTime::parse(). Augment the method
to handle parsing from GMT time. Fix incorrect handling of year in '%D'
format specifier. Remove all format specifiers related to time zones.
Copy relevant tests and add additional ones.
This release comes with a fix for a bug where certain unicode emoji
characters encoded in UTF-16 were mistakenly parsed as integers. This
manifested in keys of an JS object being coerced into integers, i.e.
`{ "⤵️": 42 }` would become `{ "5": 42 }`.
Relevant upstream PR: https://github.com/fastfloat/fast_float/pull/325
We added this for String some time ago, so let's give Utf16String the
same optimization. Note that Utf16String was already handling its data
member potentially being null as of 5af99f4dd0.
For the web, we allow a wobbly UTF-16 encoding (i.e. lonely surrogates
are permitted). Only in a few exceptional cases do we strictly require
valid UTF-16. As such, our `validate(AllowLonelySurrogates::Yes)` calls
will always succeed. It's a wasted effort to ever make such a check.
This patch eliminates such invocations. The validation methods will now
only check for strict UTF-16, and are only invoked when needed.
We now define GenericLexer as a template to allow using it with UTF-16
strings. To keep existing users happy, the template is defined in the
Detail namespace. Then AK::GenericLexer is an alias for a char-based
view, and AK::Utf16GenericLexer is an alias for a char16-based view.
* Remove completely unused methods.
* Deduplicate methods that were overloaded with both StringView and
char const* parameters.
A future commit will templatize GenericLexer by char type. This patch
serves to make that a tiny bit easier.
Before now, you could compare a Utf16View to a StringView, but it would
only be valid if the StringView were ASCII. When porting code to UTF-16,
it will be handy to have a code point-aware implementation for non-ASCII
StringViews.
Originally I added this to use it in Utf16View::ends_with(), but the
final implementation ended up a lot simpler. I chose to keep this anyway
since it mirrors Span::starts_with().
