This avoids a Clang warning about uninitialized fields when VKDevice
instantiates a DeviceDispatch with an InstanceDispatch (the superclass).
The fields are in fact filled in later, but there's no harm in
initializing them to nullptr; aside from satisfying the compiler, it
would help diagnose the situation if they somehow fail to get filled in.
Specifically:
const auto size = sdl2_config->GetInteger("System", "users_size", 0);
The variable is never used, producing a warning. I wondered if this
ought to be assigning something to in `Settings`, but nothing else in
the codebase ever mentions a settings called "users_size", so I guess
it's safe to remove...
The previous definition was:
#define NUM(field_name) (sizeof(Maxwell3D::Regs::field_name) / sizeof(u32))
In cases where `field_name` happens to refer to an array, Clang thinks
`sizeof(an array value) / sizeof(a type)` is an instance of the idiom
where `sizeof` is used to compute an array length. So it thinks the
type in the denominator ought to be the array element type, and warns if
it isn't, assuming this is a mistake.
In reality, `NUM` is not used to get array lengths at all, so there is no
mistake. Silence the warning by applying Clang's suggested workaround
of parenthesizing the denominator.
This seems to be required in order to actually use the flags for the
copy of zstd found by the top-level CMakeLists. Without it, it seems to
blindly add -lzstd, which breaks the build for me since my copy of zstd
is not in the default library path.
Originally this used `zstd`, not `zstd::zstd`, on all platforms. Commit
2cbce77 ("CMakeLists: use system zstd on Linux") made it
platform-dependent: despite its title, it changed the behavior on
Windows to use `zstd::zstd`, while leaving the behavior on Linux
unchanged.
I'm pretty sure `zstd::zstd` is the right choice on all platforms, but
by accident `zstd` also works on Linux because the library happens to
(usually) be installed in /usr/lib.
In the initializer for a struct-typed variable, one field's initializer
accesses a field that was previously initialized. I've been having a
fun Twitter discussion with C++ experts about whether this is undefined
behavior; regardless, Clang warns about it, so just avoid the pattern.
In cases where the field is initialized by a constructor argument, mark
them `[[maybe_unused]]` in case they're needed in the future. In cases
where the field is completely unmentioned, just remove the field.
This matches the similar call under #else.
Ignoring failure is actually the right behavior here, because the caller
goes on to call DynamicLibrary::IsOpen.
Clang 11 warns about an unreachable `[[fallthrough]]` in
src/core/hle/service/am/applets/controller.cpp after an
`UNIMPLEMENTED_MSG` call, because it realizes that the `if (!false)` in
the expansion of UNIMPLEMENTED_MSG is always taken. But since that
`[[fallthrough]]` is useless, I'm guessing it was added because some other
compiler (or maybe an older version of Clang) warns if it *wasn't*
present, presumably because it doesn't realize the `if` is always taken.
To appease both, change `UNIMPLEMENTED` and `UNIMPLEMENTED_MSG` to expand
directly to a call to `assert_noinline_call` without an `if` statement.
This mirrors the behavior of `UNREACHABLE` and `UNREACHABLE_MSG`.
Also, remove the aforementioned `[[fallthrough]]`.
Found this via a warning, but it's a substantive fix.
Since this is only for a cache, it should be safe to silently drop the
file if opening fails. I think.
In two cases, move constructors or assignment operators defined as
`= default` were being implicitly deleted because one of the class's
fields did not have suitable constructors/assignment operators.
Switch to explicitly deleting them; this does not affect behavior.
Note that in the case of PhysicalCore, only the move assignment operator
is implicitly deleted (because there's a field of reference type);
the move *constructor* is valid, and is required to be valid in order to
have a std::vector<PhysicalCore>.
- Add a type check so that calling Push with an invalid type produces a
compile error rather than a linker error.
- vi.cpp was calling Push with a variable of type `std::size_t`.
There's no explicit overload for `size_t`, but there is one for `u64`,
which on most platforms is the same type as `size_t`. On macOS,
however, it isn't: both types are 64 bits, but `size_t` is `unsigned
long` and `u64` is `unsigned long long`. Regardless, it makes more
sense to explicitly use `u64` here instaed of `size_t`.
On Apple platforms, FALSE and TRUE are defined as macros by
<mach/boolean.h>, which is included by various system headers.
Note that there appear to be no actual users of the names to fix up.
Actually, two enum classes, since for some reason there are two separate
yet identical `PollFD` types used in the codebase. I get one is
ABI-compatible with the Switch while the other is an abstract type used
for the host, but why not use `WSAPOLLFD` directly for the latter?
Anyway, why make this change? Because on Apple platforms, `POLL_IN`,
`POLL_OUT`, etc. (with the underscore) are defined as macros in
<sys/signal.h>. (This is inherited from FreeBSD.) So defining
a variable with the same name causes a compile error.
I could just rename the variables, but while I was at it I thought I may
as well switch to an enum for stronger typing.
Also, change the type used for values copied directly to/from the
`events` and `revents` fields of the host *native*
`pollfd`/`WSASPOLLFD`, from `u32` to `short`, as `short` is the correct
canonical type on both Unix and Windows.
