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)
| ^~~~~
```
- 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.
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.
Previously, set_needs_display() was passed an empty rectangle in
ImageStyleValue::resource_did_load(). This led to the browser not
doing a repaint when the image loaded.
Fixes#14435
If the for loop's body is not block terminated, we will generate a Jump
to the end block which will block terminate the body. Then, we ended
the lexical variable scope if needed. However, since the body is now
block terminated, the "LeaveLexicalEnvironment" instruction that is
generated by end_variable_scope is now dropped on the floor.
This fixes this by moving it to the beginning of the end block.
Previously we only did this if the body block was not terminated.
If it was, all future codegen would happen in this block terminated
body block until another switch occurred, dropping all generated
instructions in this time on the floor.
Before this commit the close tab button, which is meant to only
show when more than one tab is open, would be present on the tab
of a new project opened after the first project.
This was due to m_all_editor_tab_widgets not being cleared when closing
the first project. This is now cleared when close_current_project() is
called.
