The built-in operator takes signed int. So, match it, such that
the built-in is never a better or equally-good match to our operator.
Fixes "ambiguous overload" errors from gcc 4.2 and VS 2008.
See https://github.com/harfbuzz/harfbuzz/issues/1374
I wonder if there's something better to do about these :(.
In file included from hb-ot-color.cc:31:
hb-ot-color-cpal-table.hh: In member function 'unsigned int OT::CPAL::get_size() const':
hb-ot-color-cpal-table.hh:118: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
hb-ot-vorg-table.hh:96: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
hb-vector.hh:87: note: candidate 1: const Type& hb_vector_t<Type, PreallocedCount>::operator[](unsigned int) const [with Type = OT::VertOriginMetric, unsigned int PreallocedCount = 8u]
hb-ot-vorg-table.hh:96: note: candidate 2: operator[](const T*, int) <built-in>
hb-ot-layout-gsubgpos.hh:1707: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
...
In file included from hb-ot-name.cc:29:
hb-ot-name-table.hh: In member function 'unsigned int OT::name::get_size() const':
hb-ot-name-table.hh:157: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
hb-open-type.hh:354: note: candidate 1: const Type& OT::UnsizedArrayOf<Type>::operator[](unsigned int) const [with Type = OT::NameRecord]
hb-ot-name-table.hh:157: note: candidate 2: operator[](const T*, int) <built-in>
hb-ot-name-table.hh: In member function 'void OT::name::accelerator_t::init(hb_face_t*)':
hb-ot-name-table.hh:196: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
hb-dsalgs.hh:574: note: candidate 1: Type& hb_array_t<Type>::operator[](unsigned int) const [with Type = const OT::NameRecord]
hb-ot-name-table.hh:196: note: candidate 2: operator[](T*, int) <built-in>
hb-ot-name-table.hh:197: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
hb-dsalgs.hh:574: note: candidate 1: Type& hb_array_t<Type>::operator[](unsigned int) const [with Type = const OT::NameRecord]
hb-ot-name-table.hh:197: note: candidate 2: operator[](T*, int) <built-in>
hb-ot-name-table.hh:198: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
hb-dsalgs.hh:574: note: candidate 1: Type& hb_array_t<Type>::operator[](unsigned int) const [with Type = const OT::NameRecord]
hb-ot-name-table.hh:198: note: candidate 2: operator[](T*, int) <built-in>
make[4]: *** [libharfbuzz_la-hb-ot-name.lo] Error 1
make[3]: *** [all-recursive] Error 1
In file included from hb-face.cc:35:
hb-ot-cmap-table.hh: In member function 'void OT::CmapSubtableFormat4::_compiles_assertion_on_line_388() const':
hb-ot-cmap-table.hh:388: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
hb-open-type.hh:354: note: candidate 1: const Type& OT::UnsizedArrayOf<Type>::operator[](unsigned int) const [with Type = OT::IntType<short unsigned int, 2u>]
hb-ot-cmap-table.hh:388: note: candidate 2: operator[](const T*, int) <built-in>
hb-ot-cmap-table.hh: In member function 'void OT::CmapSubtableFormat4::_instance_assertion_on_line_388() const':
hb-ot-cmap-table.hh:388: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
hb-open-type.hh:354: note: candidate 1: const Type& OT::UnsizedArrayOf<Type>::operator[](unsigned int) const [with Type = OT::IntType<short unsigned int, 2u>]
hb-ot-cmap-table.hh:388: note: candidate 2: operator[](const T*, int) <built-in>
hb-face.cc: In function 'hb_blob_t* _hb_face_builder_data_reference_blob(hb_face_builder_data_t*)':
hb-face.cc:650: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
hb-vector.hh:81: note: candidate 1: Type& hb_vector_t<Type, PreallocedCount>::operator[](unsigned int) [with Type = hb_face_builder_data_t::table_entry_t, unsigned int PreallocedCount = 32u]
hb-face.cc:650: note: candidate 2: operator[](T*, int) <built-in>
hb-face.cc:650: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
hb-vector.hh:81: note: candidate 1: Type& hb_vector_t<Type, PreallocedCount>::operator[](unsigned int) [with Type = hb_face_builder_data_t::table_entry_t, unsigned int PreallocedCount = 32u]
hb-face.cc:650: note: candidate 2: operator[](const T*, int) <built-in>
hb-face.cc:651: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
hb-vector.hh:81: note: candidate 1: Type& hb_vector_t<Type, PreallocedCount>::operator[](unsigned int) [with Type = hb_face_builder_data_t::table_entry_t, unsigned int PreallocedCount = 32u]
hb-face.cc:651: note: candidate 2: operator[](T*, int) <built-in>
hb-face.cc:651: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
hb-vector.hh:81: note: candidate 1: Type& hb_vector_t<Type, PreallocedCount>::operator[](unsigned int) [with Type = hb_face_builder_data_t::table_entry_t, unsigned int PreallocedCount = 32u]
hb-face.cc:651: note: candidate 2: operator[](const T*, int) <built-in>
The override_features is used to override features that are normally
discretionary features, but in a specific shaper are for various
reasons desired to be bolted on or off, because they've been used
for inherent shaping. As such, it makes sense that they also
override user features. Ie. if user turned 'liga' on, we don't
want Khmer shaping to become broken... Or turn 'clig' off...
Fixes https://github.com/harfbuzz/harfbuzz/issues/1310
Profiling showed that type conversions were adding considerable cycles in time
spent doing text shaping.
The idea is to optimize it using native processor instructions to help Blink
layout performance.
Doing further investigation revelead that compilers may not use the
proper instruction on ARM 32bits builds (i.e. REV16).
One way to insure that the generated ASM was ideal for both gcc/clang
was using __builtin_bswap16.
Added bonus is that we no longer need to test for CPU architecture.
Use of the deprecated API USCRIPT_CODE_LIMIT prevents harfbuzz
using the ICU4C as a shared library.
The API has been replaced by u_getIntPropertyMaxValue(UCHAR_SCRIPT)
With OS X 10.13 Apple Chancery fails to ligate if we limit each morx
sub-chain to its declared length. Perhaps their newer compiler does
object-sharing across sub-chains. Anyway, since that's a valid, if
unspecified, way to compile tables, remove enforcement.
Probably do the same with kern/kerx.
Michiharu Ariza
Behdad Esfahbod
Ebrahim Byagowi
Bruce Mitchener
Adenilson Cavalcanti
Victor Chang