[REUSE] is a specification that aims at making file copyright
information consistent, so that it can be both human and machine
readable. It basically requires that all files have a header containing
copyright and licensing information. When this isn't possible, like
when dealing with binary assets, generated files or embedded third-party
dependencies, it is permitted to insert copyright information in the
`.reuse/dep5` file.
Oh, and it also requires that all the licenses used in the project are
present in the `LICENSES` folder, that's why the diff is so huge.
This can be done automatically with `reuse download --all`.
The `reuse` tool also contains a handy subcommand that analyzes the
project and tells whether or not the project is (still) compliant,
`reuse lint`.
Following REUSE has a few advantages over the current approach:
- Copyright information is easy to access for users / downstream
- Files like `dist/license.md` do not need to exist anymore, as
`.reuse/dep5` is used instead
- `reuse lint` makes it easy to ensure that copyright information of
files like binary assets / images is always accurate and up to date
To add copyright information of files that didn't have it I looked up
who committed what and when, for each file. As yuzu contributors do not
have to sign a CLA or similar I couldn't assume that copyright ownership
was of the "yuzu Emulator Project", so I used the name and/or email of
the commit author instead.
[REUSE]: https://reuse.software
Follow-up to 01cf05bc75
Now that the entire project is free of variable shadowing, we can enforce this as a compile time error to prevent any further introduction of this logic bug.
This lets us avoid needing to wrap external headers with #pragma warning directives for warnings we treat as errors and avoids generating warnings for external code.
Thanks to MerryMage for pointing this out.
We never ended up using yuzu_tester.
Removing it saves code duplication with yuzu_cmd, and distribution size on
prebuilt packages.
For unit testing, we can use catch2 from guest code and dump the results
to a file. Then execute yuzu from a script on ci if we want this to be
automated.
This should match some warnings we treat as errors on gcc and clang,
caching bugs early and reducing the number of instances where we have to
edit commits to make CI happy when developing from Windows.
This Clang warning complains when offsetof is used on a
non-standard-layout type (i.e. any class using various C++ features),
even though it works fine (and is not undefined behavior as of C++17).
Allows our CI to catch more potential bugs. This also removes the
[[nodiscard]] attribute of IOFile's Open member function. There are
cases where a file may want to be opened, but have the status of it
checked at a later time.
* ipc: Allow all trivially copyable objects to be passed directly into WriteBuffer
With the support of C++20, we can use concepts to deduce if a type is an STL container or not.
* More agressive concept for stl containers
* Add -fconcepts
* Move to common namespace
* Add Common::IsBaseOf
Allows reporting more cases where logic errors may exist, such as
implicit fallthrough cases, etc.
We currently ignore unused parameters, since we currently have many
cases where this is intentional (virtual interfaces).
While we're at it, we can also tidy up any existing code that causes
warnings. This also uncovered a few bugs as well.
This can result in silent logic bugs within code, and given the amount
of times these kind of warnings are caused, they should be flagged at
compile-time so no new code is submitted with them.
This significantly reduces unnecessary disk writes and space usage
when building Citra.
libcore.a is now only ~1MB rather than several hundred megabytes.
By default, MSVC doesn't use standards-compliant volatile semantics.
This makes it behave in a standards-compliant manner, making
expectations more uniform across compilers.
The C++ standard allows constexpr variables declared with the extern
keyword to have external linkage. Previously MSVC wasn't abiding by
this. This just makes the compiler more standards compliant during
builds.
Given we currently don't make use of anything that would break by this,
this is safe to enable.
