A ResultRange defines an inclusive range of error descriptions within an error module.
This can be used to check whether the description of a given ResultCode falls within the range.
The conversion function returns a ResultCode with its description set to description_start.
Common::Expected effectively provides the same functions as ResultVal, so we can implement it with this.
This can be replaced with std::expected with minimal effort should it be standardized in the C++ Standard Template Library.
This removes the const qualification for types when MakeResult(arg) is used in a const member function, allowing for automatic deduction and removing the need to manually specify the non-const type as the template argument.
The result code classes are used quite extensively throughout both the
kernel and service HLE code. We can mark these member functions as
[[nodiscard]] to prevent a few logic bugs from slipping through.
These macros all interact with the result code type, so they should
ideally be within this file as well, so all the common_funcs machinery
doesn't need to be pulled in just to use them.
Now that we have most of core free of shadowing, we can enable the
warning as an error to catch anything that may be remaining and also
eliminate this class of logic bug entirely.
Previously this was required, as BitField wasn't trivially copyable.
BitField has since been made trivially copyable, so now this isn't
required anymore.
Relocates the error code to where it's most related, similar to how all
the other error codes are. Previously we were including a non-generic
error in the main result code header.
Removes a few inclusion dependencies from the headers or replaces
existing ones with ones that don't indirectly include the required
headers.
This allows removing an inclusion of core/memory.h, meaning that if the
memory header is ever changed in the future, it won't result in
rebuilding the entirety of the HLE services (as the IPC headers are used
quite ubiquitously throughout the HLE service implementations).
Many containers within the standard library provide different behaviors
based on whether or not a move constructor/assignment operator can be
guaranteed not to throw or not.
Notably, implementations will generally use std::move_if_noexcept (or an
internal implementation of it) to provide strong exception guarantees.
If a move constructor potentially throws (in other words, is not
noexcept), then certain behaviors will create copies, rather than moving
the values.
For example, consider std::vector. When a std::vector calls resize(),
there are two ways the elements can be relocated to the new block of
memory (if a reallocation happens), by copy, or by moving the existing
elements into the new block of memory. If a type does not have a
guarantee that it will not throw in the move constructor, a copy will
happen. However, if it can be guaranteed that the move constructor won't
throw, then the elements will be moved.
This just allows ResultVal to be moved instead of copied all the time if
ever used in conjunction with containers for whatever reason.
It is now known that result code description vary depending on the
module, and so they're best defined on a per-module basis. To support
this, allow passing in an arbitrary integer instead of limiting to the
ones in the ErrorDescription enum. These will be gradually migrated to
their individual users, but a few will be kept as "common" codes shared
by all modules.
german77
Morph
bunnei
Lioncash
greggameplayer
Subv
Yuri Kunde Schlesner
wwylele