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

Rust types code generation #160

Closed
Tracked by #164
karthiknadig opened this issue Feb 15, 2023 · 0 comments · Fixed by #181
Closed
Tracked by #164

Rust types code generation #160

karthiknadig opened this issue Feb 15, 2023 · 0 comments · Fixed by #181
Labels
feature-request Request for new features or functionality needs PR

Comments

@karthiknadig
Copy link
Member

No description provided.

@karthiknadig karthiknadig mentioned this issue Feb 15, 2023
7 tasks
@karthiknadig karthiknadig added feature-request Request for new features or functionality needs PR and removed triage-needed labels Feb 15, 2023
karthiknadig added a commit that referenced this issue Apr 12, 2023
Closes #160

@ebkalderon with this PR most of the types are generated from the spec.
There are some special cases that need to be handled in the generated
code. But, it is good to get a feel for the generated code. I am happy
to review any PR with corrections or suggestions.

* Ignore the `OR` types in this PR. They are temporary.
* Generated type names for "anonymous" types needs work, ignore names
for those in this iteration.
* `extend` (inherited) and `mixins` (basically `Type1 & Type2` in
TypeScript) are implemented by extracting their properties for each
`extend` and `mixin` type and merging them into a single `struct`.
* Quality of life functions (e.g., message directions table)
* Restrictions imposed by LSP on numbers (e.g., unsigned integer must be
in range `[0, 2147483647]` inclusive)
* Most `Option<T>` cases don't need special handling, added skip_if none
for these cases.

Pending (will be covered in followup PRs):
1. Code generation for Request, Notifications, and Responses
1. Special optional in LSP, where absence of a field, filed with `null`
value, and field with non-null value have different meanings. Hence a
simple `Option<T>` is not enough to correctly represent them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality needs PR
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant