Open v0-e opened 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 DEFAULT
s 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.
On the Default
feature, I agree with you on the naming.
A derivable randomness trait would be great. I guess most of the implementation would end up being on the rasn
side, using if possible a no_std
random generator like SmallRng
.
SmallRng
looks promising. I guess a trait for randomness would need to live in rasn
, since we don't want to raise the requirement of having the compiler as a runtime dependency. Same goes for a derive macro. @XAMPPRocky, what's your take on this?
Thank you for your issue!
For the default feature, I agree with @6d7a that it should only be default when everything is specified to have a DEFAULT
.
In regards to generating random structured data, I believe the recommended trait to derive would be Arbitrary
rather than SmallRng
, as that is what is used by the fuzzing library community. https://docs.rs/arbitrary/latest/arbitrary/index.html
It would be pretty useful to have an option to instruct the compiler to add the
Default
trait 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.