They're now uncovered, which only makes it harder to spot missing
coverage in non-deprecated code. And testing is simply a matter of
copypasting the existing tests.
It's done like this in all other code, not sure why not here. Likely
because debug output wasn't tested at all before and only got added
later, thus at the end? So make it consistent.
In some cases the plugin manager constructor was not tested at all,
leading to an uncovered line. For importers also verify that calling
close() on a non-opened instance doesn't call into doClose().
Again, the Audio importer isn't touched at all, as that interface is
scheduled for mergin into Trade.
So far, even though code coverage says it's all fine, things like data
conversion failures were not tested at all, or only by checking the
return value, but without verifying that the implementation got actually
called, and without checking that no superfluous message was printed by
accident.
The AbstractFontConverter interface is tested for failures as well even
though most of it is scheduled for rework (STL removal, etc.), as
otherwise it'd be likely that I forget to test the failure cases when
simply porting the old test code to the new APIs. On the other hand, the
Audio importer interface is not touched as it's scheduled for merging
into Trade.
Glyph cache implementations in the Text library pick features based on
those, and while I'm pretty sure I tested both codepaths at some point,
not having them automatically covered makes them prone to code rot.
This was already done in Magnum Extras, but because here the code
coverage is not 99.99% I never actually saw these. Until now, where both
Text::AbstractShaper and Text::AbstractGlyphCache report destructor
*declaration* as uncovered. Destructor definition is covered, obviously,
so reporting this as uncovered is wrong.
Code from 2012 still wants to fight back. Turns out the user
implementation of doOpenFile() was never tested, only the fallback paths
to doOpenData(). Heh.
Nope, that was a very stupid change. The *vector* min() / max() is used
in intersect(), and this change broke the bindings build (likely along
with random other code).
This reverts commit 8c228c69c9. Partially,
keeping the extra added includes and also documenting why the
Functions.h are included.
Disabling SDL_AUDIO seems to work with 2.32.10, so if there was a bug it
no longer seems to be. On the other hand, SDL_EVENTS is something the
application implementation does need, so I'm not sure why I even
attempted disabling those.
Right now, without find_package(Magnum REQUIRED), FindMagnum just
continued after the FPHSA call even if the configure file wasn't found,
leading to another error right below at file(READ).
There's also a CMake policy push/pop and the newly added early return()
would cause a PUSH happen without a corresponding POP. Move that below
to fix this.
For some reason it had the full set of elements on ES2 as well, i.e.
something that definitely shouldn't be the case. Unfortunately C doesn't
warn if the array isn't initialized for all elements, setting the
remaining to 0, so this was uncaught until now. Now if I accidentally
make the array too small somewhere, it'll blow up inside
BufferState.cpp.
Because I had a stupid bug in the test and wasn't testing all of them.
And then the function itself had a bug that made it no-op exactly when
it shouldn't be a no-op.
Somehow I overlooked this extension back when implementing multidraw, or
maybe it was intentional because ANGLE supported multidraw but not this
extension.
Which makes libc++ since version 16 not use transitive includes for
backwards compatibility, both for faster build times and to detect if
some code is missing a transitive include (which could blow up for the
user even w/o this macro defined, as compiling with -std=c++23 also
removes quite a lot such includes).
This affects Android, macOS/iOS and Emscripten. On the CI right now all
VMs use older libc++, which means it does nothing, but it's done there
anyway to future-proof. Locally on Arch it affects the Android and
Emscripten builds already, as well as an explicit clang + libc++ build.
Vladimír Vondruš