The result of GetArg() is returned by value, so this is essentially
still a copy. While the previous code *is* valid, this communicates what
is actually happening a little more explicitly.
Ensures that the header dependency is always satisfied directly, and not
through other project headers. While we're at it, we can qualify the
call with the std:: namespace.
Given the same argument is used inside the condition's body if it's
true, we can just utilize the local to cut out a GetArg() operation.
Avoids redundant internal assertion checking.
Makes Windows builds more standard-compliant. Given we currently make no
use of volatile, and the libraries we currently use don't use it any
meaningful way, this is safe to specify without worrying.
Removes a boost header from the public includes in favor of using the
standard-provided std::variant.
The use of boost in public interfaces is often a dealbreaker for some
people. Given we use std::optional in the header already, we can
transition over to std::variant from boost::variant.
With this removal, this makes all of our dependencies internal to the
library itself.
CMake documentation states:
"If this variable is not set, CMake behaves as if it were set to TRUE."
So this isn't needed, as it's the default behavior.
There's currently no way this path can occur and result in any
functioning executable. The recompiler backends are platform-specific.
If those platforms aren't available, then it's quite literally
impossible to use this library for anything meaningful. Instead of
defining a generic architecture and continuing on, notify the developer
that their platform is not currently supported.
Similar to the variant within the ARM-mode translator visitor. This will
be used in subsequent changes to implement the hint instructions
introduced in ARMv7.
Now that we fuzz against Unicorn, we aren't just restricted to VFPv2.
VFPv3 and VFPv4 facilities can now be implemented. This renames
constructs mentioning VFPv2 to just refer to VFP.
Implements the ARM-mode variants of the CRC32 instructions introduced
within ARMv8. This is also one of the instruction cases where there is
UNPREDICTABLE behavior that is constrained (we must do one of the
options indicated by the reference manual).
In both documented cases of constrained unpredictable behavior, we treat
the instructions as unpredictable in order to allow library users to
hook the unpredictable exception to provide the intended behavior they
desire.
