Weird error:
"/root/project/src/hb-iter.hh", line 277: Error: Type name expected instead of "decltype()".
"/root/project/src/hb-iter.hh", line 278: Error: Invalid type while substituting into Iter::item_t.
"/root/project/src/hb-iter.hh", line 317: Error: Type name expected instead of "decltype()".
"/root/project/src/hb-iter.hh", line 318: Error: Invalid type while substituting into Iter::item_t.
Not sure what ancient compiler it is (gcc 4.2?), but didn't like hb_zip SFINAE
apparently:
In file included from /Users/distiller/project/src/hb-aat-layout.cc:28:
In file included from /Users/distiller/project/src/hb-open-type.hh:32:
In file included from /Users/distiller/project/src/hb.hh:642:
/Users/distiller/project/src/hb-iter.hh:364:1: note: candidate template ignored: substitution failure [with A = OT::Coverage, B = OT::OffsetArrayOf<OT::ChainRuleSet>]: non-type template argument does not refer to any declaration
hb_zip (const A& a, const B &b)
^
In file included from /Users/distiller/project/src/hb-aat-layout.cc:37:
In file included from /Users/distiller/project/src/hb-aat-layout-kerx-table.hh:31:
In file included from /Users/distiller/project/src/hb-kern.hh:32:
/Users/distiller/project/src/hb-ot-layout-gpos-table.hh:725:20: error: no matching function for call to 'hb_zip'
for (auto it = hb_zip (this+coverage, pairSet)
^~~~~~
Not going to try to appease.
For some reasons djgpp doesn't understand "unsigned int" can be same
with one of uint*_t anyway so lets do that for it explicitly.
Just to note, our CI's djgpp is based GCC 7.2.0 and isn't old.
https://voidlinux.org/ is yet another and different distro written from scratch, thus completely eligible to have a bot here!
Seriously however not that useful yet however but I will try to overload it other tasks later, like our other bots.
No test yet also, couldn't install cairo-devel, will try to fix that later.
Their harfbuzz package source: https://github.com/void-linux/void-packages/blob/master/srcpkgs/harfbuzz/template
TARGET_OS_OSX was introduced only in late OS versions
so always returns as "0" on older systems.
if !TARGET_OS_IPHONE can work, as it returns as !0 on older
systems where TARGET_OS_IPHONE is not defined, but is not
specific
if TARGET_OS_MAC && !(defined(TARGET_OS_IPHONE) && TARGET_OS_IPHONE)
is both specific and accurate on all systems.
Fuzzer caught it:
==14==ERROR: AddressSanitizer: stack-use-after-return on address 0x7fca2ed7a3e0 at pc 0x0000006057aa bp 0x7ffc3290f1d0 sp 0x7ffc3290f1c8
READ of size 4 at 0x7fca2ed7a3e0 thread T0
SCARINESS: 55 (4-byte-read-stack-use-after-return)
#0 0x6057a9 in OT::SingleSubstFormat2::subset(hb_subset_context_t*) const /src/harfbuzz/src/./hb-ot-layout-gsub-table.hh:194:40
#1 0x5ff921 in hb_subset_context_t::return_t OT::SingleSubst::dispatch<hb_subset_context_t>(hb_subset_context_t*) const /src/harfbuzz/src/./hb-ot-layout-gsub-table.hh:256:13
I can't reproduce locally, but many of the bots are failing because of this
as well.
It's a pity that operator-> must return pointer. Ugh. Why?!
Behdad Esfahbod
Michiharu Ariza
Ebrahim Byagowi
Ken
Behdad Esfahbod
Ken Cunningham