The following warnings do not occur anywhere in the codebase and so
enabling them is effectivly free:
* `-Wcast-align`
* `-Wduplicated-cond`
* `-Wformat=2`
* `-Wlogical-op`
* `-Wmisleading-indentation`
* `-Wunused`
These are taken as a strict subset of the list in #5487.
This required changing the load_sync API to take a LoadRequest instead
of just a URL. Since HTMLScriptElement was the only (non-test) user of
this API, it didn't seem useful to instead add an overload of load_sync
for this.
Instead of all interested parties needing to write out the code to get
the cookie value for a load request, add a static helper to do it in
one location.
This has the nice side effect of giving us a decent error message for
something like undefined.foo() - another useless "ToObject on null or
undefined" gone. :^)
Also turn the various ternary operators into two separate if branches,
they don't really share that much.
The previous filter would filter out queued checks as well, which would
result in erroneous build success notifications going out if github
started the discord notifications workflow before all other workflows.
Semaphores with values greater than one didn't work because whoever
called sem_wait() first held the semaphore's mutex until a matching
sem_post() call.
Other callers then wouldn't be able to acquire the semaphore even
if the semaphore's value was still greater than zero at that point.
Fixes#6325
The JavaScript on the HTML Spec site that caused the crash is:
window.location.hash.substr(1)
Of course, window.location.hash can be the empty string. The spec allows
for calling substr(1) on an empty string, but our partial implementation
wasn't handling it properly.
As defined by the specification (and used by the website i am testing):
interface mixin CanvasDrawPath {
undefined fill(optional CanvasFillRule fillRule = "nonzero");
}
Since we first check the winding number and only then update it, fills
for "Rectangle-like" (made up of 2 parallel segments) paths would draw
nothing when filled by NonZero winding rules. (Fix by alimpfard)
According to @Baitinq the original port crashed with audio enabled.
I suspect that this was because the SDL2 headers didn't match between
the host and target system. Now that we properly use target's headers
this is no longer an issue so I enabled audio:
https://www.youtube.com/watch?v=ZTFvrcpZjY8
I was trying to port openttd which I ultimately gave up on because
too much of the C++ standard library's functionality is missing at this
point. The libicu library was a dependency for that.
In its current state the libicu port is not thread-safe because of
missing functionality in the C++ standard library (mainly std::mutex,
std::condition_variable, etc.).
This is useful for ports which depend on running tools on the host system.
In this case we can build the port twice - once for the host and once for
the target system.
