fn writes_variant_key(data: &EventData, key: &str) -> boolExpand description
Whether key is written from one of data’s own fields — equivalently,
on an event that was decoded, whether the decode used it. The common keys
are not this function’s business; writes_common_key answers for those.
Deliberately not “does this event type define key”. The two part company
on a defined key whose value the decode could not use: SPEC.md treats such
a key as unrecognised, so its field stays None and the entry goes to
TraceEvent::extra, from where the serializer writes it back unchanged.
Asking about the type’s whole vocabulary instead keeps the key out of
extra while no field holds it either, and merely reading the file deletes
the value — which is how adding "ta", "sg", "fri" and "g" to event
1 made this reader preserve less than while it had never heard of them.
The match is exhaustive on purpose: a new variant does not compile until
its keys are listed, and both ways of getting a list wrong are silent. A
key left out is written twice, once from the field and once from extra,
and a CBOR map with a duplicate key is malformed; a key wrongly listed is
dropped from every rewrite.