This moves some stuff around to make LibGUI depend on LibSyntax instead
of the other way around, as not every application that wishes to do
syntax highlighting is necessarily a LibGUI (or even a GUI) application.
The features provided by these classes should be used eventually, but so
far we've been maintaining these classes for over 2 years without any
actual use. We can restore them when it comes time to actually use them.
Both `Database` and `Heap` were allowed to be opened twice. Prevent
this, and change SQLServer to only open databases that are not already
opened.
This fixes a Ladybird crash where opening the application twice would
erroneously duplicate free heap block indices.
The free block list now gets populated on opening a database file.
Ideally we persist this list inside the heap itself, but for now this
prevents excessive heap growth.
Previously, only the first block in a chain of blocks would be
overwritten while all subsequent blocks would be appended to the heap.
Now we make sure to reuse all existing blocks in the chain.
This is a clear sign that they want to use a UnixDateTime instead.
This also adds support for placing durations and date times into SQL
databases via their millisecond offset to UTC.
Previously, statements containing malformed exists expressions such as:
`INSERT INTO t(a) VALUES (SELECT 1)`;
could cause the parser to crash. The parser will now return an error
message instead.
Previously, `Heap` would store serialized data in blocks of 1024 bytes
regardless of the actual length. Data longer than 1024 bytes was
silently truncated causing database corruption.
This changes the heap storage to prefix every block with two new fields:
the total data size in bytes, and the next block to retrieve if the data
is longer than what can be stored inside a single block. By chaining
blocks together, we can store arbitrary amounts of data without needing
to change anything of the logic in the rest of LibSQL.
As part of these changes, the "free list" is also removed from the heap
awaiting an actual implementation: it was never used.
Note that this bumps the database version from 3 to 4, and as such
invalidates (deletes) any database opened with LibSQL that is not
version 4.
We are performing a lot of checks on pointers that are performed again
immediately afterwards because of a dereference. This removes the
redundant `VERIFY`s and simplifies a couple others.
When debugging in Xcode, the waitpid() for the initial forked process
would always return EINTR or ECHILD. Work around this by blocking all
signals until we're ready to wait for the initial child.
Rather than creating a TextStyle struct, and then copying its fields
over to a TextAttributes, let's just create a TextAttributes to start
with. This also simplifies the syntax highlighting code by letting us
define underlines along with the other text styling.
Similar to POSIX read, the basic read and write functions of AK::Stream
do not have a lower limit of how much data they read or write (apart
from "none at all").
Rename the functions to "read some [data]" and "write some [data]" (with
"data" being omitted, since everything here is reading and writing data)
to make them sufficiently distinct from the functions that ensure to
use the entire buffer (which should be the go-to function for most
usages).
No functional changes, just a lot of new FIXMEs.
This class had slightly confusing semantics and the added weirdness
doesn't seem worth it just so we can say "." instead of "->" when
iterating over a vector of NNRPs.
This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
SQLClient exists as a wrapper around SQL IPC to provide a bit friendlier
interface for clients to deal with. Though right now, it mostly forwards
values as-is from IPC to the clients. This makes it a bit verbose to add
values to IPC responses, as we then have to add it to the callbacks used
by all clients. It's also a bit confusing seeing a sea of "auto" as the
parameter types for these callbacks.
This patch moves these response values to named structures instead. This
will allow adding values without needing to simultaneously update all
clients. We can then separately handle the new values in interested
clients only.
