This is a fallible version of add<T>(...) that returns ErrorOr<T>.
It can be used together with TRY() to handle allocation failures when
instantiating new Core::Objects.
An explicit move constructor is required to null-out the moved-from
directory descriptor. Otherwise, we would call closedir() twice when
using ErrorOr<DirIterator>::release_value().
With this change, System::foo() becomes Core::System::foo().
Since LibCore builds on other systems than SerenityOS, we now have to
make sure that wrappers work with just a standard C library underneath.
This isn't a complete conversion to ErrorOr<void>, but a good chunk.
The end goal here is to propagate buffer allocation failures to the
caller, and allow the use of TRY() with formatting functions.
Also add slightly richer parse errors now that we can include a string
literal with returned errors.
This will allow us to use TRY() when working with JSON data.
Previously, trailing whitespaces were not removed from values in
config files. This could cause errors with poorly formatted files.
This commit fixes this by trimming whitespaces from values in
ConfigFile::reparse().
Derivatives of Core::Object should be constructed through
ClassName::construct(), to avoid handling ref-counted objects with
refcount zero. Fixing the visibility means that misuses like this are
more difficult.
There is also make_ref_counted(), which does not call did_construct(),
so the method was not guaranteed to be run. Since there is only a single
user, and `WindowServer::Window` is a final class anyway (so there is no
need to separate the constructor and post-constructor phases), let's get
rid of this concept.
(The following commits reduce the opportunities to call
make_ref_counted, but still.)
ArgsParser will now automatically look for an environment variable
'ARGSPARSER_EMIT_MARKDOWN', and if it is set to exactly the string "1"
(i.e. mere presence or values like "ON" or "yes" are not enough), then
ArgsParser will emit a Markdown-formatted help message, instead of the
regular help message designed for consumption through a terminal.
Just like month, the day value here is one-based. This resulted in the
following situation, which is obviously unexpected:
Core::DateTime::create(1970); // 1970-01-00 -> 1969-12-31
