AST parent pointer implementation

[anweiss]

Implements #150.

Based on the work started by @SebastienGllmt in #134. Removes parent fields from the AST in favor of a rudimentary "arena" implementation which negates the need for AST manipulation. Introduces a ParentVisitor which houses the arena tree and implements the Visitor. Also introduces a CDDLType enum which holds all of the different AST nodes.

ParentVisitor and CDDLType can be used as follows to identify an AST node's parent:

let cddl_ast = cddl_from_str(r#"a = "myrule""#, true).unwrap();
let pv = ParentVisitor::new(&c).unwrap();
let rule = cddl_ast.rules.first().unwrap();

assert_eq!(
  CDDLType::from(rule).parent(&pv).unwrap(),
  &CDDLType::from(&cddl_ast)
);

You can also walk up the parent tree by recursively calling parent() on the returned CDDLType as follows:

let cddl_ast = cddl_from_str(r#"a = "myrule""#, true).unwrap();
let pv = ParentVisitor::new(&cddl_ast).unwrap();

if let Rule::Type { rule: tr, .. } = cddl_ast.rules.first().unwrap() {
  assert_eq!(
    CDDLType::from(tr).parent(&pv).unwrap().parent(&pv).unwrap(),
    &CDDLType::from(&cddl_ast)
   );
}

In the example above, the TypeRule's parent's parent is the main CDDL struct itself.

CDDLType::From has also been implemented for all of the AST types.

@SebastienGllmt let me know if this API works for you.

[SebastienGllmt]

Slightly unfortunate this approach means you lose the type of the parent and have to use a broad CDDLType type as it will make pattern matching on the parent easier to get wrong. It might be better to bring back the original parent types from my original PR and put the casts somewhere in this library just to avoid downstream users having to think about it (ex: every node type could have a function that calls its own parent function and then performs the cast). This can be done in a followup PR though if we want it

[anweiss]

Yea this was one of the trade offs vs having to manipulate the existing AST and storing the parents in the AST. But I agree that the specific concrete type of the parent should be returned. Will make some changes.

[anweiss]

@SebastienGllmt updated to abstract the CDDLType type and introduced a Parent trait which is implemented on the AST types. So you get this usage instead:

let cddl = cddl_from_str(r#"a = "myrule""#, true).unwrap();
let pv = ParentVisitor::new(&cddl).unwrap();
let rule = cddl.rules.first().unwrap();

assert_eq!(rule.parent(&pv).unwrap(), &cddl);

Parent trait definition:

pub trait Parent<'a, 'b: 'a, T> {
  fn parent(&'a self, parent_visitor: &'b ParentVisitor<'a, 'b>) -> Option<&T>;
}

In situations where certain AST nodes can have different parent types based on context, you'll need to manually cast ... so for example:

let cddl = cddl_from_str(r#"a = "myrule""#, true).unwrap();
let pv = ParentVisitor::new(&cddl).unwrap();

if let Rule::Type { rule, .. } = cddl.rules.first().unwrap() {
  let parent: &TypeRule = rule.name.parent(&pv).unwrap();
  assert_eq!(parent, rule);
}

... the rule name's ident a has the parent of type TypeRule ...

vs.

let cddl = cddl_from_str(
  r#"
    terminal-color = &basecolors
    basecolors = (
      black: 0,  red: 1,  green: 2,  yellow: 3,
      blue: 4,  magenta: 5,  cyan: 6,  white: 7,
    )
  "#,
  true,
)
.unwrap();
let pv = ParentVisitor::new(&cddl).unwrap();

if let Rule::Type { rule, .. } = cddl.rules.first().unwrap() {
  if let t2 @ Type2::ChoiceFromGroup { ident, .. } =
    &rule.value.type_choices.first().unwrap().type1.type2
  {
    let parent: &Type2 = ident.parent(&pv).unwrap();
    assert_eq!(parent, t2);
  }
}

... wherein the ident &basecolors has the parent of type Type2.

[anweiss]

@SebastienGllmt PR is ready for final review and merge

[SebastienGllmt]

I think you forgot RangeOp / CtlOp

Also, CtlOp has a ctr: &'a str inside it, but I think this should be Identifier and marked as a parent

[anweiss]

@SebastienGllmt RangeCtlOp parent implemented. Moved the control operator tokens into a separate enum.

[anweiss]

@SebastienGllmt this is ready to merge

[SebastienGllmt]

LGTM. Integration worked as expected so far in our codebase 👍