And include it in hb_shape_plan_t itself.

This is the root cause of bug worked around in 19e77e01.

Still no shape plan caching for variations though.

No other shaper will need shape_plan_data, by definition.  So, remove
abstraction layer and always create hb_ot_shape_plan_t as part of
hb_shape_plan_t.

To remove custom null object next..

More useful.

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...

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".

Finally, unified!

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

This is a temporary hack just to avoid incorrect shaping results, pending proper support
for caching shape-plans with variation coordinates.

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

CC https://github.com/behdad/harfbuzz/issues/139

clang's new -Wcomma compiler option warns about possible misuse of the
comma operator such as between two statements.

hb-common.cc:190:9 [-Wcomma] possible misuse of comma operator here
hb-ot-layout-gsubgpos-private.hh:345:30 [-Wcomma] possible misuse of
comma operator here
hb-shape-plan.cc:438:26 [-Wcomma] possible misuse of comma operator here

Shape-plan caching is not implemented.

Move the empty-buffer check from hb_shape_full() to hb_shape_plan_execute().

Reported by Simon Cozens.

Based on data from http://upstream-tracker.org/versions/harfbuzz.html
Resolves #103

Previously, when creating an object from inert inputs (eg:
"hb_font_create(hb_face_get_empty())") we returned the inert
empty object.  This is not helpful as there are legitimate
usecases to do that.

We now never return the inert object unless allocation failed.

Tests are revised to reflect.

The only effect is, if shaper_list was not NULL and no shaper was found,
we now don't insert anything into cache and return earlier.

Wasn't breaking out of loop, ouch!

http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1246370.html