previously remove_redundant_sys () is missing in harfbuzz, after
redundant langsys removal, some features are removed as well in
prune_features() in fonttools. This change is trying to get the same
result between harfbuzz and fonttools.
optimize recurse_lookups in Context/ChainContext
glyph closure, only the glyphs that the parent lookup
can apply the recursion to can participate in recursing
the lookup.
Previous GSUB glyph closure is done by recursively visiting
all reachable lookup tables that apply to any glyphs in the
current/input glyph set, but actually only the glyphs that
the parent lookup can apply the recursion to can participate
in recursing the lookup. This is step 1 for glyph closure
optimization:
1. Add stack of currently active glyph set pointers into hb_closure_context_t
2. Update closure() method in simple GSUB tables to use
this stack in order not to change current glyph set at different stages
of recursion
3. Add function may_have_non_1to1() to GSUB tables
- subset class def 1 against the coverage table.
- Don't re-use class 0 in class def 2.
- Ignore class 0 glyphs for the purposes of determing format 1 vs format 2 encoding for ClassDef.
Add an additional test case which demonstrates these issues.
Sucks that has to be specified in this order. But that is what it is for now.
Was only exhibiting problem on C++>=17 since that's when the [[nodiscard]]
was introduced.
One of the bots is unhappy when HB_NODISCARD comes after HB_INTERNAL.
No idea why. But, again, we're testing HarfBuzz, not C++, not clang. Ugh.
In file included from src/harfbuzz.cc:1:
In file included from src/hb-aat-layout.cc:30:
In file included from src/hb-aat-layout.hh:32:
In file included from src/hb-ot-shape.hh:32:
In file included from src/hb-ot-map.hh:32:
src/hb-buffer.hh:335:15: error: an attribute list cannot appear here
HB_INTERNAL HB_NODISCARD bool move_to (unsigned int i); /* i is output-buffer index. */
^~~~~~~~~~~~
https://app.circleci.com/pipelines/github/harfbuzz/harfbuzz/1693/workflows/77459205-a189-45d3-bc58-52a8fd952c3f/jobs/155912/parallel-runs/0/steps/0-110?invite=true
To my surprise, saves ~20kb in my build (non-size-optimized) build.
The output_glyph() method is never used in the fast paths, so doesn't
matter if is not fully optimized for the special case it is.
Previous error-handling philosophy was that user doesn't need to
immediately know whether operation failed. But as can be seen after
we added malloc-failing fuzzing, there's just so many places in the
code that a failure of these operations needs to be mitigated before
further operations. So I'm moving towards returning success here,
and possibly making it nodiscard.
Garret Rieger
Behdad Esfahbod
Qunxin Liu
Khaled Hosny