IR - Test adding PrintItem::Items and PrintItems::RcItems

[dsherret]

PrintItems::RcItems

There are certain cases where cloning is necessary in the IR generation:

Condition::new("debuggingName", ConditionProperties {
    condition: Box::new(|context| true_or_false),
    true_path: Some(with_indent(items.clone())),
    false_path: Some(items),
});

It would be useful for performance reasons to instead write this as:

let items = Rc::new(items);
Condition::new("debuggingName", ConditionProperties {
    condition: Box::new(|context| true_or_false),
    true_path: Some(with_indent(items.into().clone())), // only an Rc clone, so should be fast
    false_path: Some(items.into()),
});

PrintItems::Items

Instead of writing this:

items.extend(parse_node(...));

It might possibly be faster to write this:

items.push(parse_node(...).into());
// short for
items.push(PrintItem::Items(parse_node(...)));

This may make the printer run slower, but maybe it might make the parser run faster? I'm not sure how vectors are in rust and how they perform, but this would be good to test out.

[dsherret]

Not doing this. Instead I'm constructing a graph while parsing the nodes. Should be a lot faster (hopefully) and the parsing API will be better (going back to Signal::X too).

Looks like this:

let mut items = PrintItems::new();

items.push_info(start_info);
items.push_str("class");
items.extend(parse_node(....));
items.push_signal(Signal::NewLine);

items

...which internally builds up graph nodes and connects them together.

[dsherret]

The way better solution was implemented in #56.

Basically when parsing a directional graph is constructed. All paths in that graph are behind an Rc<T> so the paths can be shared. The printer then maintains a "next node stack" to figure out what the next node should be when reaching the end of a path.