Returning a reference resulted in Mail's use of Promise causing a crash.
Also, awaiting an already-awaited promise is an odd thing to do anyway,
so let's just make it release the resolved/rejected value instead of
returning a reference to it.
Co-Authored-By: Valtteri Koskivuori <vkoskiv@gmail.com>
The Test262RunnerHandler class in test-test262 was made in order to
spawn a subprocess, connect to its input/output error pipes, and obtain
its return value.
Later on, a copy of this implementation was added to TestSed with
modifications, such as adding support for reading from the output pipes
as well.
Unify these two implementations into a new Core::Command class. This new
implementation is more closely modeled from the TestSed implementation
due to the extra functionality it implemented.
This allows us to get rid of another mime-type list in the codebase.
To do so, the `get_description_from_mime_type` function is introduced in
this patch.
We used to have two separate lists for mime-type detection, one for
detection based on the file extension, and the other one for detection
based on byte sniffing.
This list also contains a general description that will be of use in
`file.cpp`.
To create this list, I had to fill in some gaps as the two lists started
to diverge.
These three lines were added in commits 41d5531, 0f7a651 and 97aca8f all
the way back in June 2020, and went unnoticed until Lucas pointed this
out during my refactoring.
These too should be sorted alphabetically, as evidenced by the fact that
text/markdown was in there twice before this change. :^)
Also broke out tables of sufffixes and basenames we consider plaintext,
and sorted those alphabetically as well.
It makes far more sense to sort by the standard mime type strings,
rather than the ad-hoc variable names associated with each enumeration.
This way, the sort looks nicer, and also matches the corresponding
description enumerations in the file utility.
The previous iteration of this API was somewhat odd and rough in random
places, which degraded usability and made less than perfect sense.
This commit reworks the API to be a little closer to more
conventional promise APIs (a la javascript promises).
Also adds a test to ensure the class even works.
Much like the previous commit, this commit makes the
ArgParser::Arg::accept_value callback return an ErrorOr<bool> instead of
just a bool.
The aim of this is to make argument parsing more robust, especially
with the newer String api that returns an ErrorOr for many functions.
This commit adds the ability to use the String class with `add_option`
and `add_positional_argument`.
This should help with the transition away from DeprecatedString.
This is a preparation before we can create a usable mechanism to use
filesystem-specific mount flags.
To keep some compatibility with userland code, LibC and LibCore mount
functions are kept being usable, but now instead of doing an "atomic"
syscall, they do multiple syscalls to perform the complete procedure of
mounting a filesystem.
The FileBackedFileSystem IntrusiveList in the VFS code is now changed to
be protected by a Mutex, because when we mount a new filesystem, we need
to check if a filesystem is already created for a given source_fd so we
do a scan for that OpenFileDescription in that list. If we fail to find
an already-created filesystem we create a new one and register it in the
list if we successfully mounted it. We use a Mutex because we might need
to initiate disk access during the filesystem creation, which will take
other mutexes in other parts of the kernel, therefore making it not
possible to take a spinlock while doing this.
Similar to commit bcfa4a3, this enables navigating to a file:// URL in
Ladybird with audio file extensions.
The file extensions used here were taken from
https://docs.fileformat.com/audio/ (except QOA, which isn't listed).
This commit changes the variables used to represent the size and
progress of downloads from u32 to u64. This allows `pro` and
`Browser` to report the total size and progress of a download
correctly for downloads larger than 4GiB.
Calling `from_utf8` with a DeprecatedString will hide the fact that we
have a DeprecatedString, while using `from_deprecated_string` with a
StringView will silently and needlessly allocate a DeprecatedString,
so let's forbid that.
When called with `SearchInPath::Yes`, calls to `Core::System::exec()`
would fail. The value returned from
`resolve_executable_from_environment()` was assigned to a StringView,
but the original reference was not kept, causing the StringView to
appear empty.
Finally, the end of our journey to fallible I/O!
Now all that's left to do is to rewrite the code around each and every
.release_value_but_fixme_should_propagate_errors() call. :^)
Closes#17129.
DeprecatedFile doesn't properly handle I/O or OOM errors, and only
provides a rudimentary interface to reasonably handle it. We have long
since learned how to do it "properly" with ErrorOr<> and similar
interfaces. See also d43a7eae54.
Note that this leaves behind an invocation to DeprecatedFile in
Ladybird/AndroidPlatform.cpp. However, that part of the system has
compilation errors since at least January, and will get removed or
rewritten as part of issue #19085. Let's not wait for this Android port
to remove this deprecated API.
The if statement for setting the O_NONBLOCK flag was written the other
way around, causing Core::File to open files in non-blocking mode, when
we didn't actually specify it.
Some applications may not want to have the ability to create a
file if it doesn't exist, but still be able to read and write
from it. The easy solution here would be just to not apply
O_CREAT when creating the flags, but to prevent breaking a ton
of applications, having a `DontCreate` mode is the best for now.
`Core::System::fstatat()` is similar to our standard `Core::System`
wrappers.
`Core::Directory::stat(relative_path, flags)` is a convenience method if
you already have a Directory, to stat a file relative to it.
