It happens to behave nicely with MSVC's RelWithDebInfo, but it's undefined behaviour, and GCC (I don't know what parameters were used) errors due to a bounds-check assertion failure.
They don't need to be member functions, and needing a pointer to an
instance of that interface is awkward.
The function names have also changed to reflect that they're not
specific to the masterlists.
This allows common metadata to be shared across masterlists in a
'prelude' YAML file that is then injected into a masterlist when it is
loaded. Masterlist metadata can then reference anchors within the
prelude to make use of those common metadata.
The prelude file will be version controlled in a separate Git
repository, so the masterlist update functions also apply to managing
its versioning.
There's not much point having a Masterlist class with only three static
member functions. This refactoring also helps break the association
between the Git-related functions and masterlists, which will help when
implementing support for prelude files.
To reflect that it will soon be used to provide info for other
version-controlled files. Also rename its revision_id and
revision_date fields to remove the revision_ prefixes.
LOOT's ability to roll back to a working masterlist version hasn't been
exercised in years, as our CI testing has gotten better at catching
issues before they reach users.
Coupling updating a masterlist with loading it also complicates the
introduction of a common prelude, so given the very low usefulness of
the functionality it's best to drop it entirely .
Check after adding group edges, as after that LOOT only adds edges if
they don't cause a cycle. Adding tie-break edges is the step that takes
longest and scales the worst (by far), so failing before that would
provide a much better user experience.
This property can be used to provide detail about a requirement or
incompatibility that can be displayed in the error message displayed
for the file (if one is displayed).
While the value could actually be NaN, that's also what esplugin uses to
signal that the version could not be found, and either way a NaN value
is useless.
In favour of IsLightPlugin() and IsValidAsLightPlugin() respectively.
The new functions are identical to the old besides their names, which
now more clearly indicate that plugins can be light without being
masters.
If there is no exact match, compare language codes so that a more
generic match is preferred over just returning the English content.
This means that if a locale code is given, Choose() will also look for
the locale's language code (but will not match another locale with the
same language code), and if a language code is given, Choose() will also
look for a locale with that language code.
Unlike on Windows, it doesn't return the "true" case of a path on Linux
when case folding is enabled. Using NormalizeFilename() is more
consistent but theoretically less accurate, though all currently
hardcoded plugins are known to use ASCII filenames so there is no
practical downside.
AppVeyor is breaking my builds because I can't create any more artifacts
because I've hit the limit, but there's no way to have it not store
artifacts or to manually delete artifacts...
This also updates Boost from 1.67.0 to 1.69.0 due to differences between
the AppVeyor and GitHub Actions build environments.
Oliver Hamlet
Oliver Hamlet