This repository has been archived by the owner on Dec 29, 2022. It is now read-only.
Use serde instead of rustc_serialize #1436
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
matklad
reviewed
Apr 18, 2019
| @@ -106,7 +106,7 @@ where | |||
| let mut contents = String::new(); | |||
| file.read_to_string(&mut contents).map_err(|e| e.to_string())?; | |||
|
|
|||
There was a problem hiding this comment.
Similarly, from_read here should give some sweet perf improvements
There was a problem hiding this comment.
You'd think, but that's unfortunately not the case in practice (the reason why I went with the string -> file flow in the first place but it seems to only affect reading)
bors
added a commit
to rust-lang/rust
that referenced
this pull request
Apr 22, 2019
save-analysis: Use serde instead of libserialize to dump JSON data
This breaks the save-analysis infrastructure (which also includes `rls-{analysis, data, span}` crates) from depending on rustc_serialize and so we can start moving them to being supported on stable without implementing `Decodable` et al. by hand for data structures defined there.
Notable benefits:
- we drop the awkward raw byte `PathBuf` [serialization](https://gist.github.com/Xanewok/f4fe8564d0dc0c3ab1dbc244279ff895) (until now (de)serialized as `&[u8]`)
- [faster](https://github.com/serde-rs/json-benchmark) (hopefully noticeable for inner crate dependencies for the RLS workloads)
- we can easily explore the binary serialization backend (which we planned to do for save-analysis anyway)
~This should be merged together with an update to RLS (rust-lang/rls#1435), which technically could be included right now because we can use the bundled `rls-analysis` here directly, however I'd prefer to publish this to crates.io first (rust-lang/rls#1434, cc @nrc) and use the published version, instead.~
Includes rust-lang/rls#1436.
@matklad @nikomatsakis This is also important for the potential RLS 1.0 - 2.0 bridge we talked about on Zulip today
|
☔ The latest upstream changes (presumably 20e3268) made this pull request unmergeable. Please resolve the merge conflicts. |
|
20e3268 was used in the Rust repo and was merged here instead of this PR, closing. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Basically #1435 but opened from the local (non-fork) branch since Rust tidy only whitelists this repository.
When/if rust-lang/rust#60053 is merged, this should be as well to retain Rust commit history continuity.