-
Notifications
You must be signed in to change notification settings - Fork 155
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
Rust support #250
Rust support #250
Conversation
…i_struct_compiler into rust_tuning � Conflicts: � shared/src/main/scala/io/kaitai/struct/languages/RustCompiler.scala
This reverts commit 5f301fd.
Using in RustCompiler & RustTranslator.
Just wondering is this is still an active effort? I'd love to have Rust support for for Kaitai, as I'm trying to migrate some of my projects to Rust using existing kaitai structs |
Thanks for your interest. Yes, we are waiting for approval from maintainers. |
…ompiler into rust_basic_support_v2
sample: self.groups().value() # look for "value" method inside of class (type) "groups" self.value() # look for "value" in current class
Updated PR with the latest changes from the master branch + small improvements. |
Rust support is largely reworked in kaitai-io#250 and touching it here would just create conflicts.
It is not used from the rest of the `src/lib.rs` file and it is not referenced from kaitai-io/kaitai_struct_compiler#250 either. Besides, it is apparently a reproduction of `UnexpectedDataError`, which was used in KS only before 0.9. Since 0.9, `ValidationNotEqualError` is used instead (see kaitai-io/kaitai_struct#280 (comment)). In runtime libraries which existed before 0.9, `UnexpectedDataError` was marked as deprecated and will be eventually removed, so it doesn't make sense to add it to new runtime libraries.
It has never been used by any of the commits in kaitai-io/kaitai_struct_compiler#250
At the time of writing, kaitai-io/kaitai_struct_compiler#250 used `KError::ValidationNotEqual` for all kinds of validations (see https://github.com/kaitai-io/kaitai_struct_compiler/blob/23328785803ba93a8b3bfc33e1e0b998a34df01f/shared/src/main/scala/io/kaitai/struct/languages/RustCompiler.scala#L1199), which doesn't make any sense. This commit makes a step towards a solution consistent with the established system of validation errors in KS. The enum variant `KError::ValidationFailed` represents the failure of any validation (it is an equivalent of the `ValidationFailedError` base class in other languages). It contains a `ValidationFailedError` struct, which is intended to hold any details associated with the specific failed validation. It only contains the `kind` field at the moment, but the plan is to extend it in the future with fields like `actual`, `src_path` etc. The `ValidationKind` enum has been marked with the [`non_exhaustive` attribute](https://doc.rust-lang.org/reference/attributes/type_system.html#the-non_exhaustive-attribute), which allows us to add more validation kinds in the future without breaking compatibility with user application code. Even though I anticipate the addition of fields to the `ValidationFailedError` struct, it cannot be marked `non_exhaustive` because we must be able to instantiate it from the KSC-generated code. So I added at least a doc comment warning the users about the possibility of extending the struct contents.
outHeader.puts("#![allow(arithmetic_overflow)]") | ||
outHeader.puts("#![allow(overflowing_literals)]") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These two suppressions hide real bugs, so I'll remove them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Agile86 @revitalyr Thank you for your work, I'll now merge this.
I'm personally not very happy with the quality of the code (for example, too many mutable variables, too much string manipulation instead of modeling the necessary concepts in types in types and using pattern matching like in the majority of KSC code), but it's better than what we have now.
Hopefully we can improve it over time. Going through the code now, it actually seems that it isn't bad overall, there are just a number of weird places that need rewriting. So when I have time in the future, I'll try to refactor these weird places one by one and then it might be actually good.
Hello everybody,
my name is Oleh Dolhov, my collegue name is Vitaly Reshetyuk,
we are from Stroz Friedberg (AON) providing this PR to bring Rust-language support to Kaitai.
Right now we can pass almost all tests, except (4) tests, that's using features like:
Rust doesn't support inheritance, so there is no common type.
KStructUnit, tests like
nav_parent_switch_cast.ksy
,params_pass_array_struct.ksy
,params_pass_struct.ksy
.AnyType, test like
process_coerce_switch.ksy
.Please, note, you need to clone tests and runtime/rust exactly
rust_basic_support_v2
branch.Would be great to get feedback.
Best regards,
Oleh & Vitaly.