The specialization for the destructor of `AK::Optional` is ambiguous
when `T` is neither TriviallyDestructible nor Destructible.
The fix adds an additional check for `Destructible` when generating the
destructor of `AK::Optional`, since it calls the destructor of `T`, and
therefore already required `T` to be `Destructible` anyway.
Attempting this resulted in an error because the `m_pointer` field does
not exist on `Optional<T>`. Creating a shared `ptr()` function and
adding the necessairy overloads solves this issue.
The order of precedence with the `*` operator sometimes makes it a bit
harder to detect whether or not the result is actually used. Let's fail
compilation if anyone tries to discard the result.
MSG_NOSIGNAL is a no-op for Windows, so we can define it to 0.
At the same *time*, none of the CLOCK_* macros are defined on
Windows, as clock_gettime does not exist. Put AK_OS_WINDOWS in the
same category of the BSDs for the COARSE versions of those macros.
Co-authored-by: Andrew Kaster <akaster@serenityos.org>
Monotonic uses QueryPerformanceCounter, while realtime uses
GetSystemTimeAsFileTime. These should approximate clock_gettime
fairly accurately. The QPC implementation only grabs microseconds,
but if we have actual use cases for nanos, we can bump that up.
Co-authored-by: Andrew Kaster <akaster@serenityos.org>
These don't have to worry about the input not being valid UTF-8 and
so can be infallible (and can even return self if no changes needed.)
We use this instead of Infra::to_ascii_{upper,lower}_case in LibWeb.
`STDERR_FILENO` is pretty common but not part of the standard. On
Windows, in order to get a file number, one must use `_fileno` to
convert the `FILE *` to a file number. Adopt this pattern similar
to the Android path which uses platform specific operations.
We had numerous NiH-based implementations of audio formats and metadata
that we now no longer need because we either don't make use of the code,
or we replaced its implementation by FFmpeg.
First, this isn't actually helpful, as we no longer store 32-bit values
in JsonValue. They are stored as 64-bit values anyways.
But more imporatantly, there was a bug here when trying to coerce an i64
to an i32. All negative values were cast to an i32, without checking if
the value is below NumericLimits<i32>::min.
You can now build with STYLE_INVALIDATION_DEBUG and get a debug stream
of reasons why style invalidations are happening and where.
I've rewritten this code many times, so instead of throwing it away once
again, I figured we should at least have it behind a flag.
This change should move us forward toward emoji support, as we are no
longer limited by our own OpenType implementation, which was failing
to parse the TrueType Collection format used to store emoji fonts
(at least on macOS).
Some callers (LibJS) will want to control the size of the output buffer,
to decode up to a maximum length. They will also want to receive partial
results in the case of an error. This patch adds a method to provide
those capabilities, and makes the existing implementation use it.
Also give the Swift.String init routines an explict label when
constructing from AK String types, as this caused issues in a later
commit to have them both with `_ data`.
At the same time, simplify CMakeLists magic for libraries that want to
include Swift code in the library. The Lib-less name of the library is
now always the module name for the library with any Swift additions,
extensions, etc. All vfs overlays now live in a common location to make
finding them easier from CMake functions. A new pattern is needed for
the Lib-less modules to re-export their Cxx counterparts.
When using a configuration without a swift compiler, we need to no-op
the swift annotations. Other, cleverer solutions beyond the has include
all fell flat in the face of the clang modules implementation used by
swift to parse-once use-everywhere each module.
This requires pulling in some of the STL, but the result is that our
iterator is now STL Approved ™️ and our containers can be
auto-conformed to Swift protocols.
Otherwise, the following code would not compile:
constexpr Array<int, 3> array { 4, 5, 6 };
Vector<int> vector { 4, 5, 6 };
if (array == vector.span()) { }
We do such comparisons in tests quite a bit. But it currently doesn't
become an issue because of the way EXPECT_EQ copies its input parameters
to non-const locals. In a future patch, that copying will be removed,
and the compiler would otherwise complain about not finding a suitable
comparison operator.
The script pulls in a dependency on the `yaml` python package. Instead
of updating all the docs and CI jobs to account for this, let's guard
calling the script behind our experimental flag instead.
