ion-cli
ion-cli copied to clipboard
amzn
### Issue #105: ### Description of changes: This PR works on adding support for writing SExpression in code generation. ### Generates Code: - Generated code for given ISL test files...
### Issue #, if available: https://github.com/amazon-ion/ion-cli/issues/42 ### Description of changes: This PR adds options to analyze the input binary Ion data stream, allowing users to: * Get the maximum depth...
Currently generator stores all the fields as required but based on ISL these fields could be optional as well as can be repeated. Optional/Required Fields: - [ ] Rust -...
Currently, code generation doesn't support writing SExpression instead it writes it as Ion List. This can be modified to keep track of specified ISL type from schema and write accordingly.
Suppose I have the following schema: ``` $ion_schema_2_0 type::{ name: Foo, fields: { a: { fields: { x: int, y: int } }, b: int, } } type::{ name: Bar,...
Currently variably occurring types are not fully supported in code generation. Process `occurs` field and validate while reading the data using the value of `occurs` constraint.
> If you use `Boolean` instead of `boolean`, then this could be initialized to `null`. Similarly for `int`/`Integer` and `double`/`Double`. > > However, if it's not an optional field, then...
* [ ] Enable the `LazyReader` to read from streams (in addition to byte slices) * [ ] Expose byte slice accessors for stream elements' encodings (e.g. `fn annotations(&self) ->...
Currently, code generation can generate invalid Java or Rust code for ISL types that have names using keywords of Java/Rust programming language. This is also an issue for field names...
> We should not expose the constructor, if we can help it. Unless we generate overloaded constructors, using a constructor means that adding a new optional field is backwards incompatible....