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
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.
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.
newlib has an extra character slot at the beginning to enable some
macro tricks that cause a warning when someone passes a type that's not
"int" into a ctype function. Our deviation from this causes issues for
LLVM.
Previously we were hand-writing all the Zlib and raw Deflated data
structures here, but now PNGs will be compressed using ZlibCompressor
which will actually try to compress something! :^)
Note that we don't do any filtering that should help compress data even
more, but even now the results are pretty good:
- screenshots of my Serenity desktop are take now about 55 KiB, where
previously it was 3 MiB.
- re-encoding NASA photo of the Earth[1] to PNG shows a 2x improvement
(34.3 MiB -> 16.5 MiB).
[1]: https://commons.wikimedia.org/wiki/File:The_Blue_Marble_(remastered).jpg
When swapping both values to perform the actual calculation, we need to
consider that `A + B == B + A`, but `A - B != B - A`, so turn it into
`-B + A`.
Co-Authored-By: Sam Atkins <atkinssj@serenityos.org>
These functions were changed to synchronous in #13870 but
the async_ versions were still being called. This led to
frequent crashes when loading local files in Browser.
The new min_content_size value is to be set by the subclasses, it is
then used to determine if the scrollbars should be shown after a
resize, but before the content size will be calculated by the following
layout pass.
This function is intended to propagate layout changes upwards in the
widget hierarchy. Widgets that can know what to do with this
information without causing a full layout invalidation (i.e. just
because one of their child widgets changed layout/size, doesn't
necessairily mean that they have to change their layout/size) can
override this and prevent a full relayout and redraw.
The default size for label is always a compromise, no matter what value
is chosen, some layouts will require local manual overrides.
Having the preferred size be opportunistic_grow in both directions seems
like it's currently the option that works without modification in most
cases.
This commit adds some finagling and shrinking of the corner bitmap
to handle drawing shadows on elements where the shadow radius >
half the width or height of the element. Previously things would
go horribly wrong when this happend.
There could still be some edge cases, but things seem to be working
fairly well now.
.jpg){kind=link}