6d7a
commented
5 months ago Sounds like a useful feature. I would love something like that for test data generation.
I wonder if we should use Default, though. After all, ASN.1 has its own notion of DEFAULT, that's why I would rather use it in cases where it results in the same behavior in Rust. For example if a SEQUENCE has only default values, the compiler could generate a std::default::Default implementation that returns a struct with the corresponding DEFAULTs from ASN.1.
Would random values be an option for you? It would provide a shorthand if one just needs data for testing.
As far as the generate function is concerned, I'd be happy to accept a refactor that adds a configuration object. It will definitely become necessary in the future as we add further options to the compiling process. As far as the design goes, I'd probably go for passing a reference to a simple struct holding the config down to the individual generator functions. But feel free to try out different things. After all, the compiler is still relatively young, so we are free to try different approaches.
The code that will be generated for ASN.1 input lives in template.rs, also for nested types, which will be unnested by the compiler. If you want to add optional generation of trait implementations, that's where the implementation code would eventually have to end up.
v0-e
XAMPPRocky
It would be pretty useful to have an option to instruct the compiler to add the
Defaulttrait to the generated binding types, to help out in especially large ASN.1 definitions. This could be something similar to bindgen'sderive_default.For enums we can default to the first enum choice, for constrained values we can default to the first value in the allowed interval, etc.,
I would be happy to help implement this :). However, the generate() functions currently only use the TLD as an argument, so I'm not sure of the best way to implement this. It should be in a way that allows several options, not only this proposed derive default.