We were forgetting where we put the userspace thread stacks, so added a
member called Thread::m_userspace_thread_stack to keep track of it.
Then, in ~Thread(), we now deallocate the userspace, kernel and signal
stacks (if present.)
Out of curiosity, the "init_stage2" process doesn't have a kernel stack
which I found surprising. :^)
There was a bug in the "prepend_vector_object" test but it was masked
by us not printing failures. (The bug was that we were adding three
elements to the "objects" vector and then checking that another
vector called "more_objects" indeed had three elements. Oops!)
This is a complement to append() that works by constructing the new
element in-place via placement new and forwarded constructor arguments.
The STL calls this emplace_back() which looks ugly, so I'm inventing
a nice word for it instead. :^)
Furthermore, fread() has already handled EOF, so there's no need to do
it again. If we read a character, return it, otherwise return EOF.
Note that EOF means "EOF or error" here.
There's some confusion between the write syscall and CIODevice::write()
here. The internal write() returns a boolean, and has already whined
in case the syscall failed, so we don't need to do that again.
I originally thought I'd have to implement text clipping in Painter for
this, but it seems like I can get away without doing that today. :^)
Fixes#390.
FileManager used to open up with the root directory loaded by default.
Now it will try to load either 1) the first argument specified on the
command line, 2) the user's home directory, or 3) the root directory.
Fixes#389
In the event where you want to find the index of a deeply-nested path
with a GFileSystemModel that hasn't yet traversed most of that path, it
is possible for a false negative failure to occur. This failure is
caused by the GFileSystemModel incorrectly bailing out of the search
when it hits the first unseen path segment that is not at the very end
of the path.
This patch fixes this problem by reifying the intermediate nodes during
that search and traversal process.
It doesn't seem sane to try to iterate over a HashTable while it's in
the middle of being cleared. Since this might cause strange problems,
this patch adds an assertion if an iterator is constructed during
clear() or rehash() of a HashTable.
A lot of things happen in response to window destruction, and some of
them may call into the window's WSClientConnection and ask it to look
through its window list.
If we're right in the middle of tearing down the window list, it's not
a great idea to start iterating over it.
Fixes#386.
An operation often has two pieces of underlying information:
* the data returned as a result from that operation
* an error that occurred while retrieving that data
Merely returning the data is not good enough. Result<> allows exposing
both the data, and the underlying error, and forces (via clang's
consumable attribute) you to check for the error before you try to
access the data.
Put simply, Error<> is a way of forcing error handling onto an API user.
Given a function like:
bool might_work();
The following code might have been written previously:
might_work(); // but what if it didn't?
The easy way to work around this is of course to [[nodiscard]] might_work.
But this doesn't work for more complex cases like, for instance, a
hypothetical read() function which might return one of _many_ errors
(typically signalled with an int, let's say).
int might_read();
In such a case, the result is often _read_, but not properly handled. Like:
return buffer.substr(0, might_read()); // but what if might_read returned an error?
This is where Error<> comes in:
typedef Error<int, 0> ReadError;
ReadError might_read();
auto res = might_read();
if (might_read.failed()) {
switch (res.value()) {
case EBADF:
...
}
}
Error<> uses clang's consumable attributes to force failed() to be
checked on an Error instance. If it's not checked, then you get smacked.
