I thought I went over all these several years ago already, but
apparently not or maybe back then not all websites were HTTPS-ready. Now
they mostly are, except for maybe one or two.
Like, no wonder C++ codebases are so bug-ridden, given all APIs in the
standard library are weird like this, requiring the user to completely
understand their inner workings in order to be able to use them safely.
A fix for this got made in 390d3fc06f
(2022) already, but somehow the corresponding tests were living in a
half-done stash ever since. I should probably also just do my own binary
search thing so I don't need to test everything so extensively.
Similarly as done in Aug 2024 in Corrade. When these were a part of the
function signature, they ended up being encoded into the exported
symbol. There are still cases of StridedArrayView slice() having
enable_if in the signature, which amounts to about 18 kB symbols in all
libMagnum*-d.so libraries, but apart from that this is the state before:
$ strings libMagnum*-d.so | grep enable_if | grep -v slice | wc -c
29591
And this is after. All of those are coming from STL, thus from
old or deprecated APIs that still use std::vector, std::tuple and such,
and from the few std::sort() uses.
$ strings libMagnum*-d.so | grep enable_if | grep -v slice | wc -c
4103
In a non-deprecated build it's just this, which is a 10x reduction.
Can't really do much about these maybe exceút for implementing my own
swap() specializations (sigh?), but I think it's fine.
$ strings libMagnum*-d.so | grep enable_if | grep -v slice | wc -c
2904
I also made it consistently use
typename std::enable_if<..., int>::type = 0
instead of
class = typename std::enable_if<...>::type
because the former works correctly also in presence of overloads and
having it used consistently everywhere makes it easier to grep & change
later. All SFINAE is now also excluded from Doxygen output, because it
doesn't make much sense there. It's better to just explain the
restriction in words than with this nasty hack.
They're not parsed since 6b22a11170
(2020), so there's no point in keeping those workarounds. They're only
kept in utility application sources as they're parsed for pages, and in
tweakable implementations where it's easier to just copypaste the whole
ifdef expression from the header every time instead of modifying it to
not include DOXYGEN_GENERATING_OUTPUT.
Compared to Corrade, the improvement in compile time is about a minute
cumulative across all cores, or about 8 seconds on an 8-core system (~2
minutes before, ~1:52 after). Not bad at all. And this is with a
deprecated build, the non-deprecated build is 1:48 -> 1:41.
Heh, somehow every time I run the full battery of tests I discover
another failure.
NVidia, with Vulkan version forced to 1.0 and when VK_KHR_maintenance1
isn't enabled, returns VK_ERROR_OUT_OF_DEVICE_MEMORY. So whitelist that
error as well and treat it as allocation failure and not a fatal error.
Not sure what I did in 3e4e1bde69 but that
updated XFAIL is now an XPASS on NVidia. Because, apparently, the clear
clears the whole memory, not just the image area, so even though the row
pitch is different, the comparison of the initial N bytes passes.
So I'm ditching the silly XFAILs and doing a proper image comparison that
includes the actual driver-dependent row pitch for the images. Finally,
the image-to-image copy was flat out wrong because it didn't take the
*input* row pitch into account, so it copied garbage and then compared to
a different kind of garbage.
The check for memory size was enough for llvmpipe, but not for
SwiftShader. And now it wasn't enough for NVidia either, so let's just do
it properly.
Ideally of course this would compare always. Don't feel like doing that
right now tho, so it's just a TODO.
Similar to previous commit, Doxygen 1.12 being finally strict and
refusing to link to this. There's a new (inline) namespace in between,
and it needs the Corrade:: prefix also.
Doxygen 1.12 has no longer a completely insane matcher and discards
those as it should. With 1.8.17 classes had to be referenced with
Corrade:: but functions, typedefs and variables didn't need to be and it
was a complete utter chaos.
It was an XFAIL in some other case already, do it here as well -- it
seems that llvmpipe now never fails the allocation. Not sure since when
that happens, because several Mesa versions until 23.3 (?) had a
regression with skinning shaders, leading to the automated tests failing
even before they could reach the llvmpipe variant of Vk tests.
An ad-hoc solution was already done in DebugTools::screenshot(), now I
need it in another place. While not as fast as the O(1) mapping from
the generic format to the API-specific ones due to the potentially
linear lookup, it definitely could be useful in general.
Not that C++ STL and exceptions would be anything to take inspiration
from, but there's std::out_of_range. Python IndexError is also specified
as "index out of range", not "bounds".
Partially needed to avoid build breakages because Corrade itself
switched as well, partially because a cleanup is always good. Done
except for (STL-heavy) code that's deprecated or SceneGraph-related APIs
that are still quite full of STL as well.
Among other things this makes it possible to use Utility::copy() instead
of a manual loop and grow arrays with std::realloc() instead of always
new'ing-copy-deleting because Containers::Pair is trivially copyable.
It was creating the pool with 7 buffers, which the driver could as well
just round up to 8 and then allocating 8 would not fail. The test used
to work on Mesa before but not anymore. So I'm creating the pool with 8
and askin for 80 which should definitely fail.
There's a lot more failures on NVidia, I "fixed" those by deleting the
NVidia Vulkan ICD file for now.
Triggers the new OOB assertion in ArrayView element access APIs.
"Technically" this was okay, since converting a BufferMemoryBarrier to
VkBufferMemoryBarrier is just `return this;` (and a cast), which if
`this == nullptr` returns `nullptr`. But practically this probably
triggered all sorts of UB. Haha.
This significantly simplifies everything -- because a single type can
now handle both StringView lists and char* lists, we no longer need a
templated private helper to avoid allocating a temporary array of
unified type. Instead, the whole extension initialization can be done
directly in the initialize() helper, by simply iterating over the
argument.
Yay, this is probably the nicest improvement caused by StringIterable so
far.
Vladimír Vondruš