This reverts commit fb265b610d.
The optimization in that commit is safe when the executor thread is
writing and the GUI thread is reading, but I had failed to take into
account that it's unsafe when the GUI thread is writing and the executor
thread is reading. (The native UpdateAdditionalMetadata function loops
through m_cached_files, which is unsafe if another thread is adding
elements to m_cached_files simultaneously.)
Losing out on this optimization isn't too bad, because
719930bb39 makes it very unlikely that
both threads will want the lock at the same time.
It seems like we spend a lot of the game list scanning time in
updateAdditionalMetadata, which I suppose makes sense considering
how many different files that function attempts to open.
With the addition of just one little atomic operation, we can make
it safe to call updateAdditionalMetadata without holding a lock.
If the compiler can detect an issue with a format string at compile
time, then we should take advantage of that and turn the issue into a
hard compile-time error as such problems almost always lead to UB.
This helps with catching logging or assertion messages that have been
converted over to fmt but are still using the old, non-fmt variants
of the logging macros.
This commit also fixes all incorrect usages that I could find.
Disable -Wstringop-truncation warnings as they result in many false
positives.
In most (all?) cases where std::strncpy is used, we want to fill the
entire buffer or match emulated code that also ignores the null
terminator, so the warnings are not useful.
Given that Dolphin itself mostly uses std::string, they do not
really help catch any bugs.
Having extra warnings enabled for everything including external
libraries produces an overwhelming amount of warnings in code that
isn't even part of our codebase.
Move the various warning flags to Source/CMakeLists.txt to get rid
of those useless warnings.
Note that the Source CMakeLists.txt is already where the MSVC warnings
are defined, so this commit improves consistency as well.
The CMake Windows build was broken because of me adding a usage
of std::codecvt_utf8_utf16 to StringUtil.cpp. Kinda silly to have
a warning for an API with no standard replacement available...
All supported platforms now have easy access to a compiler with C++17
support.
C++17 potentially allows for some nice cleanups and removes the need
for standard library backports (optional/variant).
See discussion at https://dolp.in/pr6264#discussion_r158134178
This macro (that has unfortunately become the de-facto way of
introducing targets) has a lot of disadvantages that outweigh the fact
that you avoid writing two extra lines of CMake script.
- It encourages the use of variables. In a build system the last thing
we want to care about is mutable state that can be avoided.
- It only handles linking in the libraries and nothing else. It's a
laziness macro.
- We should be explicit about what we're doing by introducing the target
first, not last.
This gets the ball rolling by migrating Core off the macro. Note that
this is essentially 1-to-1 unrolling of the macro, therefore we're
still linking in all libraries as public, even though that may not be
necessary.
This can be revisited once everything is off the macro for a quicker
transition period.
Some toolchains provide enough of C++17 to conflict with Dolphin's
included backport of std::variant and std::optional. Specifically,
the recently-released macOS 10.13 SDK does not provide the <optional>
or <variant> headers, but does provide `in_place_t` in the <utility>
header.
std::optional makes a few things a bit neater and less error prone.
However, we still cannot use C++17 (unfortunately), so this commit
adds an implementation of std::optional that we can use right now.
Based on https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/lib/gtl/optional.h
which seems to be fairly similar to C++17's <optional> and standards
compliant. It's one of the few implementations that handle propagating
type traits like copy constructibility, just like libc++/libstdc++.
Compilers are very picky and don't use PCH when they have been compiled
with different flags. I even got some ICE in MSVC, so removing them for now.
Modules are the solution.
These directories have been unused for several years and without any automated
way of running the tests, they are pretty much useless.
While they might be useful as a reference, in their present state they should
not be kept in the repository.
JosJuice