glibc before 2.28 defines major() and minor() macros from sys/types.h.
This triggers a Lagom warning for old distros that use versions older
than that, such as Ubuntu 18.04. This fixes a break in the
compiler-explorer Lagom build, which is based off 18.04 docker
containers.
We had a really naive and simplistic implementation, which lead to
various issues where the optimiser incorrectly rewrote the regex to use
atomic groups; this commit fixes that.
This a simple RAII helper for the BorderRadiusCornerClipper it
samples under the corners on construction, then blits them back
on exiting the scope. This encapsulates a fairly common pattern.
Note: With this change the border-radius is clipped if ethier the
overflow-x or overflow-y is hidden (it is a little unclear what
happens if just one is set, but it seems like most browsers
treat one set + border-radius the same as if overflow: hidden
was set).
JsonArray.h does not #include the definition of JsonValue::serialize, as
it lives in JsonObject.h. The macOS Clang target handles symbol
visibility slightly differently (I couldn't figure out how exactly), so
no visible instantiation ended up being created for the function,
causing a link failure.
This test doesn't test AK::String, but LibC's sprintf instead, so it
does not belong in `Tests/AK`. This also means this test won't be ran on
Lagom using the host OS's printf implementation.
Fixes a deprecated declaration warning when compiling with macOS SDK 13.
The Mach-O file format does not have ELF's interposition rules, so this
flag does not make sense for macOS builds. While GCC silently accepts
the unsupported option, Clang issues a warning for it.
This commit makes it possible to build Lagom with LLVM from Homebrew.
The lazy resolution mechanism made it so that the variables were linked
together, causing unexpected behaviour:
true
x=$? # expected: x=0
false
echo $x # expected: 0, actual: 1
This aligns it with the spec again, it was clarified that the additional
range check before ArrayCreate is intentional:
https://github.com/tc39/proposal-change-array-by-copy/issues/94
Also cast the final variable to an u64 instead of size_t after we have
determined that it is safe to do so, as that's what Array::create()
takes now.
This doesn't matter per se as the value is immediately validated to be
in the 0 to 2^32 - 1 range, but it avoids having to cast a number that
potentially doesn't fit into a size_t into one at the call site. More
often than not, array-like lengths are only validated to be <= 2^52 - 1,
i.e. MAX_SAFE_INTEGER.
This is fully backwards compatible with existing code as a size_t always
fits into an u64, but an u64 might not always fit into a size_t.
This also allows constructing from other integral types like u64, which
would have been ambiguous before (at least on i686):
```
error: call of overloaded 'Value(u64&)' is ambiguous
note: candidate: 'JS::Value::Value(i32)'
175 | explicit Value(i32 value)
| ^~~~~
note: candidate: 'JS::Value::Value(unsigned int)'
164 | explicit Value(unsigned value)
| ^~~~~
note: candidate: 'JS::Value::Value(long unsigned int)'
153 | explicit Value(unsigned long value)
| ^~~~~
note: candidate: 'JS::Value::Value(double)'
141 | explicit Value(double value)
| ^~~~~
```
