I don't know what's going on, nor I want to deal with this right now.
This matches the change they did to the Bullet package. In my opinion
this should not be needed at all, it should work correctly by default.
Fortunately it's just one crap package manager on a single shit platform.
Often the doc contain something like `\cpp int \ce-sized`, and while that
worked in 1.8.16, with 1.12 not anymore. Adding an empty tag right after
to make it keep working as before.
Which is good, those are all either anchors in the theme itself, or are
group names for which Doxygen doesn't make anchors anymore (but m.css
does). Plain HTML link still works as before, so let's do that instead.
This used to work in old Doxygen (now it says something about potential
recursion), but given the m.css theme turns section titles into links,
having a nested link inside doesn't make sense.
This name isn't known to it at the time it parses the header (because no
such header gets included for it), which in turn causes Doxygen 1.12 to
generate a dummy ::Platform namespace. Which then gets a priority over
Magnum::Platform when linked to, and because it's dummy, it's reported
as an error because it's not allowed to link to undocumented stuff.
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.
Same as what Range does, so accessing them doesn't lead to weird
surprises with e.g. `.x()` missing.
Which means I can also HOPEFULLY remove that old MSVC ICE workaround
from the tests.
Same as done for Containers::StaticArray some time ago. Since it's not a
potentially dangerous operation, it's not made as an overload of the
from() function, but instead a regular constructor. It's however kept
explicit for now, even though it eventually might not need to be -- I'm
not sure about potential consequences yet.
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.
Essential for text selection and editing in cases where mapping from the
input text to the actual shaped glyphs is nontrivial. I.e., in case of
HarfBuzzFont; both FreeTypeFont and StbTrueTypeFont perform a 1:1
translation from input (UTF-8) characters to glyphs so there it isn't
as important.
It fixed interpolation for a more precise rounding, which means the
ground truth files for this test are now off-by-one compared to before.
In particular, nothing in the _source_ BCn data or the Y-flip algorithm
changed, it's just that they're now decoded to RGBA differently by bcdec
so the tests fail.
Worked on x86, works on ARM Linux (with GCC) as well. Not sure if it has
anything to do with long doubles being 64bit there, but I don't think it
should.
Having it next to AbstractShaper didn't make sense, as there's various
use cases where font features are specified but the caller code doesn't
even know there's any shaper involved. Such as in the UI library.
Based on the actual text direction (either explicitly set or detected),
these resolve to either *Left or *Right. For the Text::Renderer it's
done automatically inside (and there's no way to actually set the
direction from outside due to the API being ancient and limited), for
the align*() utils the alignment has to be explicitly resolved using a
new alignmentForDirection() utility.
There shouldn't be any other values passed to these. Compilers, don't
even attempt to say that the alignment value is now maybe uninitialized,
I'm watching you!
Microsoft should fire all versioning scheme managers and then start
over. Why a single product needs
- a marketing version that's just a year number
- a major.minor.patch marketing version because the year was too coarse
to be meaningful for anything, and that version being also completely
unrelated to the year for good measure
- a runtime library version that used to match the major.minor marketing
version a decade ago but then it somehow got out of sync
- a _MSC_VER macro that was in sync with the short marketing version
last time in 1989 and never again
- an internal build number that feels like a countermeasure to "sorry,
can't have reproducible builds so be sure to ship the artifact number
194033811, that one we tested"
Vladimír Vondruš