The previous behavior of mapping a missing value to the "inherit"
state is incompatible. Now, a missing value maps to the "true" state,
which is the expected behavior.
Apparently, some code points fit both categories, for example U+0345
(COMBINING GREEK YPOGEGRAMMENI). Handle this fact when determining if
a code point is a final code point in a string.
There's a fair amount of boilerplate when e.g. adding a new UCD file to
parse or a new enumeration to generate. Reduce the overhead by adding
helper lambdas. Also adds a couple missing spec links with UCD field
information.
Note that unlike the main property list, each code point has only one
word break property. Code points that do not have a word break property
are to be assigned the property "Other".
This reverts commit cfc9ee6f16.
This change was wrong: The parent *does* lose hover when the mouse
cursor enters a child widget. Hover is not hierarchical, there is only a
hovered window and a hovered widget within that window.
This fixes an issue with GUI::TabWidget buttons appearing hovered
despite the mouse cursor not being over the buttons.
This reverts commit a5a32fbcce.
This change was wrong: it's fine for a child widget to receive an enter
event despite its parent never getting one. Only the widget directly
under the mouse cursor is considered hovered for enter/leave purposes.
There's no point in using a keyring file we just downloaded from the
same file mirror to verify the authenticity of the binutils tarball.
If someone were to compromise the file mirror they could just as easily
replace the keyring file and we'd happily tell the user that their copy
of binutils is genuine.
AnonymousVMObject::set_volatile() assumes that nobody ever calls it on
non-purgeable objects, so let's make sure we don't do that.
Also return EINVAL instead of EPERM for non-anonymous VM objects so the
error codes match.
Previously it was possible to leak the file descriptor if we error out
after allocating the first descriptor. Now we perform both fd
allocations back to back so we can handle the potential error when
processing the second fd allocation.
The way the Process::FileDescriptions::allocate() API works today means
that two callers who allocate back to back without associating a
FileDescription with the allocated FD, will receive the same FD and thus
one will stomp over the other.
Naively tracking which FileDescriptions are allocated and moving onto
the next would introduce other bugs however, as now if you "allocate"
a fd and then return early further down the control flow of the syscall
you would leak that fd.
This change modifies this behavior by tracking which descriptions are
allocated and then having an RAII type to "deallocate" the fd if the
association is not setup the end of it's scope.
