Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Further encoding support #11

Open
2 of 5 tasks
kellerkindt opened this issue Apr 22, 2020 · 0 comments
Open
2 of 5 tasks

Further encoding support #11

kellerkindt opened this issue Apr 22, 2020 · 0 comments

Comments

@kellerkindt
Copy link
Owner

kellerkindt commented Apr 22, 2020

Issue Tracking Issue for tracking the progress of further encoding implementation.

Preconditions:

  • (in progress, clean-up) Refactor to provide better extensibility (see 325c96f and asn1rs::syn)

Potential encodings:

kellerkindt added a commit that referenced this issue Apr 22, 2020
…exity

The current approach to generate the (de-)serialization code is to messy,
too hard to understand, too hard to extend and too complex. The new idea is
to introduce a further codegen step.

1) ASN Definition   -- old codegen -->  3) Rust struct with (de-)serializable

   |                                                    A
   | generate                                proc-macro |
   V                                                    |

 2) Rust struct with attributes and that pleasant for human eyes

Instead of writing 3) to the user file, 2) shall now be written instead.
Also, instead of generate comple (de-)serializ code in 3), the Visitor
pattern is being used to walk the types and values on the generated data
types. This hopefully allows to implement UPER, PER, BER, ... #1 #10 #11
kellerkindt added a commit that referenced this issue Apr 30, 2020
kellerkindt added a commit that referenced this issue Apr 30, 2020
kellerkindt added a commit that referenced this issue Oct 9, 2020
…pe, fixes #13

Resolve all tags while augmenting the annotated structs with Constraint impls. It
is neccessary that to this state, the complex-type-references have already resolved
their tags. For this it it might be neccessary from now on to have all *.asn1 files
and their modules in scope while resolving the tags in the RustModel-to-Annotation
stage.

Quite a bit of work went into ensuring that no unncessary tags (meaning default tags)
are present in the annotated representation to prevent unnecessary bloat.

This will probably allow the SET and SET_OF branch to be merged soon #11 #10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant