Show up with gcc -O0.

There's a few more but those are functions that need to be filled in.

Maybe this is a lost battle...

Actually the check is right,

On -myanmar.hh, on that particular switch, OT_C is indic_category_t
but OT_D is myanmar_category_t so we are mixing the types in one variable.

And on -arabic.cc, step can goes one number higher than step_t enum in the
loop so we are actually using it as an unsinged int.

From Lorna Evans: "That was a new character added to Unicode 11.0"

See comment.

Now I wonder if any bots will be unhappy we calling | in static const initializations...
Or would that cost runtime init?  Our tests don't detect any..

Sorry for the noise, downstream custom builders.  Please adjust.

Found and fixed a couple bugs.

Found a couple multithreading issues.  Marked them with "XXX-MT-bug".

Fixes https://github.com/harfbuzz/harfbuzz/issues/345

Previously we made CGJ unskippable.  Now, if CGJ did NOT prevent
any reordering, allow skipping over it.  To make this work we
had to make changes to the Arabic mark reordering algorithm
implementation to renumber moved MCM marks.  See comments.

Fixes https://github.com/harfbuzz/harfbuzz/issues/554

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4099

Part of fixing https://github.com/behdad/harfbuzz/pull/605

In ten years we never used them...

No flag is safe, over time... See previous commit.

Fixes https://github.com/behdad/harfbuzz/issues/509

Not all shapers code is updated to set this properly.
GSUB and Arabic shaper are updated.
GPOS and other shapers are NOT.

Fixes https://github.com/behdad/harfbuzz/issues/224

Fixes https://github.com/behdad/harfbuzz/issues/505

Fixes https://github.com/behdad/harfbuzz/issues/408

New approach to fix this:
https://github.com/behdad/harfbuzz/commit/69f9fbc4200442a35484d3c790ae8f4979be5d60

Previous approach was reverted as it was too broad.  See context:
https://github.com/behdad/harfbuzz/issues/347#issuecomment-267838368

With U+05E9,U+05B8,U+05C1,U+05DC and Arial Unicode, we now (correctly) disable
GDEF and GPOS, so we get results very close to Uniscribe, but slightly different
since our fallback position logic is not exactly the same:

Before:		[gid1166=3+991|gid1142=0+737|gid5798=0+1434]
After:		[gid1166=3+991|gid1142=0@402,-26+0|gid5798=0+1434]
Uniscribe:	[gid1166=3+991|gid1142=0@348,0+0|gid5798=0+1434]

Fixes https://github.com/behdad/harfbuzz/issues/234

That seems to be what Windows is doing, and makes more sense.

Back in the old days, we used to apply 'calt' and 'cswh' in Arabic shaper,
with a pause in between.  Then we disabled the 'cswh' because Microsoft
disabled it, but forgot to remove the unnecessary pause.  Do that now.

This has the benefit that it fixes shaping with monbaiti from Windows 10.
In that version of that font, the lookups from 'calt' are duplicated in
'rclt', and Mongolian was changed to go through Universal Shaping Engine.
We still use the Arabic shaper for Mongolian.  With a pause after 'calt',
we were applying the duplicate lookups from 'calt' and 'rclt' twice.  It
happened to be the case that these lookups were NOT idempotent.  So we
were getting wrong shaping.  See thread "Windows 10 monbaiti.ttf upgrade
(5.01 -> 5.51) caused loss of diacritical marks when shaped with harfbuz"
on the mailing list.  This fixes that.

This aims to make Syriac Abbr Mark sizing more accurate when repeating segments are used, by adding an extra repeat and tightening up the spacing slightly rather than leaving a shortfall corresponding to a partial repeat-width.

Visual Studio does not like declaring a enum variable within a for
statement, so fix the build by declaring the enum before doing the for
loop.

Err on the side of being too short, than too wide.  Reduces chance
of overlaps with neighboring glyphs.

Addresses
https://github.com/behdad/harfbuzz/commit/6e6f82b6f3dde0fc6c3c7d991d9ec6cfff57823d#commitcomment-14248516

The feature is enabled for any character in the Arabic shaper.
We should experiment with using it for Arabic subtending marks.
Though, that has a directionality problem as well, since those
are used with digits...

Fixes https://github.com/behdad/harfbuzz/issues/141