pub struct MacroDefs { /* private fields */ }Expand description
The macPutValue calls a caller wants made, in the order it wants
them made in.
C builds its table one macPutValue at a time — macInstallMacros
walks the pairs array macParseDefns produced, in file order
(macUtil.c:250-275) — and expand then walks the table in that
same order (macCore.c:655), so the sequence a .db load’s macLib
notices come out in is the sequence the definitions were written in.
A HashMap cannot carry that, and sorting its keys by name only
looked right because the shapes measured so far happened to be in
alphabetical order already.
So the order is carried here instead, and the conversion from a
HashMap is the one place the loss is named: those definitions
arrive in no order at all, and sorting them by name at least makes
the notices reproducible from run to run.
Implementations§
Trait Implementations§
impl Eq for MacroDefs
Source§impl From<&HashMap<String, String>> for MacroDefs
impl From<&HashMap<String, String>> for MacroDefs
Source§fn from(macros: &HashMap<String, String>) -> Self
fn from(macros: &HashMap<String, String>) -> Self
The lossy direction, and the only one: a hash map has no
definition order to carry, so the names are sorted to make the
notice order at least the same on every run. A caller that knows
the order the operator wrote should build a MacroDefs
directly.