googlefonts / googlefonts/fontations
Cases where Rust impl details are embedded in the codegen inputs
- Dominant language
- Rust
- Stars
- 826
- Forks
- 75
- Avg merge
- 22h 33m
- Merged PRs (30d)
- 75
Description
For future discussion: I've reviewed all the inputs and come up with the following tentative list of places I notice the inputs feel Rust-specific:
- ComputedArray/VarlenArray: these are irrelevant if you aren't trying to do zerocopy, since you can just iterate the items and allocate for all array types.
- the presence of lifetimes in the codegen inputs; for instance in gpos we have:
```rust
table PairPosFormat3 {
// ..
class1_records: ComputedArray>,
}
record Class1Record<'a> {
class2_records: ComputedArray,
}
```
basically we want to include the lifetime in the innertype of `ComputedArray`; not all types in computed array have a lifetime, and we don't know how to guess if we need it or not. We could let it be elided in the decl of `Class1Record`, I think, but so long as we require it in the other place I think it's less confusing if we require it in both places.
- we describe the target of an offset using rust generic syntax.
- some attributes (compile, e.g) allow you to specify expressions inline, and we often include a `self` parameter in the specified expressions (e.g. to call a method on self)
- we specify documentation in markdown syntax (e.g. for specifying links)
- the idea of generic offsets (and the `#[generic_offset]`) attribute
- various places that aren't exactly 'rust specific', but more specific to our particular implementation: attributes like `compile`, `compile_type`, `validate`, `skip_font_write`, `skip_from_obj`, `to_owned`, and `traverse_with`.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.