Skip to content

.cbor handling incorrect for standalone types #91

@SebastienGllmt

Description

@SebastienGllmt

#50 adds support for the .cbor notation

It does so by having foo = bytes .cbor bar simply make foo be an alias for bar at the type level and handling the cbor-in-cbor encoding in the (de)serialization logic.

This works fine when embedded as part of a larger object, but when the type is used standalone, it just leaves you with type foo = bar with no (de)serialization wrapping a-la #88

I also noticed the same issue happens with TaggedData (foo = #6.24(bytes) generates the wrong code when standalone)

Proposed Solution

I think probably the best way to fix this is to extend the upstream cddl library to give it parent pointers for all the AST types. Basically we would add a new feature flag that, when enabled, adds a parent member variable that gets filled in on a 2nd pass of the AST using the visitor utilities in the library

Then, from our library, we can use these parent pointers in parsing.rs to know if a type is top-level (needs to be wrapped) or if it's embedded (use current technique)

Having this kind of parent pointer would also improve the logic implemented in #84 as we could:

  1. Remove the struct I defined in the PR
  2. Crawl up the parent stack to fallback to the root rule name if no @name definition exists

Metadata

Metadata

Assignees

No one assigned

    Labels

    CDDL featureFeature that is required for proper parsing of CDDL filesbugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions