...by replacing it with a ctor that takes the buffer instead, and
handling the allocation failure in ArrayBuffer::create(size_t) by
throwing a RangeError as specified by the spec.
Instead of having a single limit here, which we had to increase once to
work with ASAN enabled, check whether HAS_ADDRESS_SANITIZER is defined
and use 32 KiB, and 16 KiB otherwise (which is what we used previously).
This idea is shamelessly stolen from V8:
https://github.com/v8/v8/blob/b2b44af/src/execution/isolate.cc#L1381-L1387
Pior to this change when the user added text after having saved the file
the Text Editor wouldn't enable the modified flag, unless this new text
was a new line.
This happened because the UndoStack was merging the Command added by
the new text with the old text one, and when is_current_modified()
was called, the m_stack_index would not have been incremented, and
it would return false.
In this change was added a condition to verify if the modified tag is
active, and the merge is only done if the document is already modified.
We were incorrectly assuming that the mapped .text segment for an ELF
image was always at the base of the image mapping. Now that we have
.rodata mappings as well, it's possible for one of them to come before
the .text.
It relies on a mapper function to convert each T& to a JS::Value. This
allows us to avoid awkward Vector<T> to MarkedValueList conversion at
the call site.
Without this, the bounding rect for the text as generated by TextLayout
can go beyond the bounds of the user-supplied drawing rect and cause the
text to overlap because of the line_rect.intersect(rect) a few lines
below.
We were accidentally calling TextDirection::get_text_direction with a
String instead of a UtfView, which meant each byte was treated as a
codepoint, resulting in incorrect identification of text direction.
The UnicodeLocale generator will need to parse canonicalized locale
strings, and will require using these methods. However, the generator
cannot depend on LibUnicode because Locale.cpp within LibUnicode already
depends on the generated file. Instead, defining the methods that the
generator needs inline allows the generator to use them without linking
against LibUnicode.
There are a few places in the system where this could be useful,
such as PixelPaint and the MandelBrot demo. It seems general enough
that it is probably useful to have it as a system-wide cursor rather
than loading it manually each time.
This can be used immediately in PixelPaint (separate commit), but
I am adding this as a system-wide cursor since it may also be useful
for other applications that want to use it.
Previously there was no way to draw rectangles with any specific
thickness, like we can do with ellises, for instance. This method
is just a simple wrapper around `draw_line()` several times. At
least for now, we don't need to do anything sophisticated since
this will only be used by PixelPaint.`
Our existing implementation did not check the element type of the other
pointer in the constructors and move assignment operators. This meant
that some operations that would require explicit casting on raw pointers
were done implicitly, such as:
- downcasting a base class to a derived class (e.g. `Kernel::Inode` =>
`Kernel::ProcFSDirectoryInode` in Kernel/ProcFS.cpp),
- casting to an unrelated type (e.g. `Promise<bool>` => `Promise<Empty>`
in LibIMAP/Client.cpp)
This, of course, allows gross violations of the type system, and makes
the need to type-check less obvious before downcasting. Luckily, while
adding the `static_ptr_cast`s, only two truly incorrect usages were
found; in the other instances, our casts just needed to be made
explicit.
And also try_create<T> => try_make_ref_counted<T>.
A global "create" was a bit much. The new name matches make<T> better,
which we've used for making single-owner objects since forever.
Prior this change, clicking on a slider with set jump_to_cursor() flag
didn't exactly match the knob to the mouse position, and therefore
the slider values were a bit off in the corners.
The calculation used the whole widget size to set new values, which
isn't correct as the track slider has margins on both ends.
I noticed this while seeking in the Sound Player.
This allows you to ask the color to recommend either white/black
as a contrasting text color if you were using the color as the
background. This uses the previously added luminosity() method.
