-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
trait-based serialization and auto-serialization #3520
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I just noticed that generic types aren't properly auto-serializing. Regular types seem fine. I'll try to get that fixed and add some tests tomorrow. |
I've fixed the generic type issues, added temporary prettyprint2 and ebml2 libraries, and a test. We'll need a snapshot before I can convert everything over to the trait-based approach. |
This will need a snapshot before we can convert ebml and rustc to use the new-style serialization.
Unfortunately this trips over issue (rust-lang#3585), where auto-ref isn't playing nicely with @t implementations. Most serializers don't care, but prettyprint2 won't properly display "@" until rust-lang#3585 is fixed.
This will help with the auto_serialize2 migration. We have to change ident from a type alias to uint into a unique type. We need to use a struct instead of a "enum ident = token::str_num" because structs support constants, but newtypes do not.
Rebased and landed, thanks. |
bors
pushed a commit
to rust-lang-ci/rust
that referenced
this pull request
May 15, 2021
use filter by hash when first rendering
RalfJung
pushed a commit
to RalfJung/rust
that referenced
this pull request
Apr 27, 2024
josh rustc-pull: check that no new root commits get created A second root was a bad sign in Miri (judging from the description in rust-lang/miri#2583) and seems to be a [bad sign in RA](rust-lang/rust-analyzer#17025 (comment)). So let's add this to the sanity checks.
RalfJung
pushed a commit
to RalfJung/rust
that referenced
this pull request
May 4, 2024
josh rustc-pull: check that no new root commits get created A second root was a bad sign in Miri (judging from the description in rust-lang/miri#2583) and seems to be a [bad sign in RA](rust-lang/rust-analyzer#17025 (comment)). So let's add this to the sanity checks.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds trait-based serialization and auto-serialization. It's parallel with the old serialization library to help with the migration. This has the same approach as the old function-based one, just with traits. Because of this, we can simplify down auto-serialization to handling just records, structs, and enums. Everything else can be implemented in the library.
There are some downsides to the trait-based approach though:
serialization2.rs
if we want to automatically support more than 5 argument tuples.#[auto_serialize]
requires this preamble at the top of the file, which would be nice to auto-generate.pure
everywhere, because serializers might not be pure. I could change theserialize
signature tofn serialize<S: Serializer>(&mut self) { ... }
but then everything that will be serialized must be stored in alet mut ...
slot. Oddly enough the old function-based approach does not have this problem.