The fact that HB_AUTO_RETURN will return rvalue-references for rvalues
is very disturbing.

Even apart from that, I'm totally lost re any hb_move needs or
hb_forward'ing to functions/templates where the type is fixed by
explicitly specifying template parameters.

==1==ERROR: AddressSanitizer: stack-use-after-return on address 0x7f6ad65e51e0 at pc 0x0000005da240 bp 0x7ffc104ab670 sp 0x7ffc104ab668
READ of size 4 at 0x7f6ad65e51e0 thread T0
SCARINESS: 55 (4-byte-read-stack-use-after-return)
     #0 0x5da23f in bool OT::Coverage::serialize<hb_map_iter_t<hb_map_iter_t<hb_filter_iter_t<OT::Coverage::iter_t, hb_set_t const&, $_7&, (void*)0>, OT::SingleSubstFormat1::subset(hb_subset_context_t*) const::'lambda'(unsigned int), (hb_function_sortedness_t)1, (void*)0>, $_20&, (hb_function_sortedness_t)1, (void*)0>, (void*)0>(hb_serialize_context_t*, hb_map_iter_t<hb_map_iter_t<hb_filter_iter_t<OT::Coverage::iter_t, hb_set_t const&, $_7&, (void*)0>, OT::SingleSubstFormat1::subset(hb_subset_context_t*) const::'lambda'(unsigned int), (hb_function_sortedness_t)1, (void*)0>, $_20&, (hb_function_sortedness_t)1, (void*)0>) harfbuzz/src/hb-ot-layout-common.hh:1055:16
     #1 0x5d88f9 in bool OT::SingleSubstFormat1::serialize<hb_map_iter_t<hb_map_iter_t<hb_filter_iter_t<OT::Coverage::iter_t, hb_set_t const&, $_7&, (void*)0>, OT::SingleSubstFormat1::subset(hb_subset_context_t*) const::'lambda'(unsigned int), (hb_function_sortedness_t)1, (void*)0>, $_20&, (hb_function_sortedness_t)1, (void*)0>, (void*)0>(hb_serialize_context_t*, hb_map_iter_t<hb_map_iter_t<hb_filter_iter_t<OT::Coverage::iter_t, hb_set_t const&, $_7&, (void*)0>, OT::SingleSubstFormat1::subset(hb_subset_context_t*) const::'lambda'(unsigned int), (hb_function_sortedness_t)1, (void*)0>, $_20&, (hb_function_sortedness_t)1, (void*)0>, unsigned int) harfbuzz/src/hb-ot-layout-gsub-table.hh:98:9

Since our API is the invers of what std::bind is, and closer to Python
functools.partial().

To match std:;bind, even though our interfaces are very different.

Finally seems to be working now.

And add a partialization API use example to hb_add()

Ugh.

In file included from hb-ot-face.cc:41:
./hb-ot-layout-gsub-table.hh:293:7: error: template parameter redefines default argument
         hb_requires (hb_is_sorted_source_of (Iterator,
         ^
./hb-meta.hh:59:27: note: expanded from macro 'hb_requires'
 define hb_requires(Cond) hb_enable_if((Cond))
                          ^
./hb-meta.hh:57:67: note: expanded from macro 'hb_enable_if'
 define hb_enable_if(Cond) typename hb_enable_if<(Cond)>::type* = nullptr
                                                                  ^
./hb-ot-layout-gsub-table.hh:40:5: note: previous default template argument defined here
    hb_requires (hb_is_sorted_source_of (Iterator,
    ^
./hb-meta.hh:59:27: note: expanded from macro 'hb_requires'
 define hb_requires(Cond) hb_enable_if((Cond))
                          ^
./hb-meta.hh:57:67: note: expanded from macro 'hb_enable_if'
 define hb_enable_if(Cond) typename hb_enable_if<(Cond)>::type* = nullptr
                                                                  ^

In file included from hb-ot-face.cc:41:
./hb-ot-layout-gsub-table.hh:293:7: error: template parameter redefines default argument
         hb_requires (hb_is_sorted_source_of (Iterator,
         ^
./hb-meta.hh:59:27: note: expanded from macro 'hb_requires'
 define hb_requires(Cond) hb_enable_if((Cond))
                          ^
./hb-meta.hh:57:67: note: expanded from macro 'hb_enable_if'
 define hb_enable_if(Cond) typename hb_enable_if<(Cond)>::type* = nullptr
                                                                  ^
./hb-ot-layout-gsub-table.hh:40:5: note: previous default template argument defined here
    hb_requires (hb_is_sorted_source_of (Iterator,
    ^
./hb-meta.hh:59:27: note: expanded from macro 'hb_requires'
 define hb_requires(Cond) hb_enable_if((Cond))
                          ^
./hb-meta.hh:57:67: note: expanded from macro 'hb_enable_if'
 define hb_enable_if(Cond) typename hb_enable_if<(Cond)>::type* = nullptr
                                                                  ^
1 error generated.

Use default.

Oops.

Unused, and why here and not in other functions...

See comments.

Let's see if I break any bots.  But yeah, it wasn't accepting a
non-const pointer.  It just happens that we don't use that in the
code it seems.

Both to save ops, and also because lambdas don't implement operator!=,
so this was failing in range-based for loop if a lambda was passed to
hb_map() or hb_filter().  Just check end-condition assuming that we
are comparing to .end() or iterators that are otherwise derived from
current iterator.  Ie. don't compare things that are expected to be
in common.

To fix https://travis-ci.org/harfbuzz/harfbuzz/jobs/532693197

It may break things, lets see

Fails locally.  Trying to understand.  Sigh

Apparently there's different overload resolution rules that apply, at
least with some (older?) version of gcc.

hb-ot-name-table.hh: In member function ‘void OT::name::accelerator_t::init(hb_face_t*)’:
hb-ot-name-table.hh:244:62: error: ambiguous overload for ‘operator+’ (operand types are ‘hb_blob_ptr_t<OT::name>’ and ‘OT::NNOffsetTo<OT::UnsizedArrayOf<OT::IntType<unsigned char, 1u> > > {aka const OT::OffsetTo<OT::UnsizedArrayOf<OT::IntType<unsigned char, 1u> >, OT::IntType<short unsigned int, 2u>, false>}’)
       this->pool = (const char *) (const void *) (this->table+this->table->stringOffset);
                                                              ^
hb-ot-name-table.hh:244:62: note: candidates are:
hb-ot-name-table.hh:244:62: note: operator+(const C*, long int) <built-in>
hb-ot-name-table.hh:244:62: note: operator+(const char*, long int) <built-in>

This reverts commit 01912efb.

Actually this didn't break things.  Fixing

Reverts 57f65ae9

Caused ambiguous-overload on some gcc...