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)
| ^~~~~
```
This PR includes information that highlights the importance of
updating Xcode on MacOS. I ran into problems building serenity
on MacOS because I had Xcode installed but not updated in a while.
This triggered seemingly unrelated errors that were easily solved
by updating Xcode.
To prevent a race condition in case we received the ARP response in the
window between creating and initializing the Thread Blocker and the
actual blocking, we were checking if the IP address was updated in the
ARP table just before starting to block.
Unfortunately, the condition was partially flipped, which meant that if
the table was updated with the IP address we would still end up
blocking, at which point we would never end unblocking again, which
would result in LookupServer locking up as well.
Update to the latest version of the upstream dos2unix, 7.4.3.
Simplify the URL used to download the upstream PGP key for the
dos2unix package, by leveraging the already well-used version
variable.
- No underscores between word boundaries, i.e. `languageserver` and not
`language_server` for LibLanguageServer
- All lowercase, i.e. `coredump` and not `Coredump` for LibCoredump
If you attempt to inspect a non-visible dom node it will hit
various assertions as things like style have not been computed.
With this change attempting to inspect these nodes will simply
clear the style and box model tabs.
The implementation no longer matches the spec text, but I believe that's
a bug anyway. No point in allowing array lengths up to 2^53 - 1 when the
ArrayCreate AO rejects anything above 2^32 - 1.
Currently when allocating buffers for USB transfers, it is done
once for every transfer rather than once upon creation of the
USB device. This commit changes that by moving allocation of buffers
to the USB Pipe class where they can be reused.
Not being able to map the file chunk-by-chunk feels like a deficit of
MappedFile and/or LibArchive, so it's weird that `unzip` is enforcing
this size limit, and an especially arbitary one at that.
Since "replace one error message with another error message" is the best
possible outcome here, and making the user pass a useless flag in cases
where it may not even be needed is the worst, let's just remove that
file size limit.
However, the `FIXME` about mapping files partially is left in because
this is something that we definitely want to take a look at in the
future.
