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

syntax: Fix encoding and decoding spans #31028

Merged
merged 1 commit into from
Jan 21, 2016
Merged

Conversation

erickt
Copy link
Contributor

@erickt erickt commented Jan 19, 2016

The protocol for serialize::{En,De}code doesn't allow for two integers to be serialized next to each other.

Closes #31025.

cc @michaelwoerister

@rust-highfive
Copy link
Collaborator

r? @sfackler

(rust_highfive has picked a reviewer for you, use r? to override)

@sfackler
Copy link
Member

Large numbers are always somewhat sketchy to work with in JSON since they'll so often round trip through a double. Should we maybe encode with the packed number in a string?

@erickt
Copy link
Contributor Author

erickt commented Jan 19, 2016

@sfackler: True, although libserialize, rustc-serialize, and serde all are able to properly parse out u64 numbers, we can't assume other json parsers can read them. From what I understand, we only have to worry about dropping values if we ever get to 2^53 + 1. All other integers below that are representible in an f64. So I'm not sure how often this will come up in practice :)

@sfackler
Copy link
Member

I've seen it hit in systems that use randomly generated 64 bit identifiers, for example.

In this case, I think it'd require a high span index greater than 2^21, which is roughly 2 million. It seems not wildly unreasonable to have 2 megabytes of source code for a crate, but I'm not sure.

@michaelwoerister
Copy link
Member

How bad would it be for JSON to encode spans as structs? Because for the binary encoding that is used for crate metadata, there's no more overhead for these. The main reason for encoding it as two separate values was to allow for the variable-length integer format to kick in properly.

@erickt
Copy link
Contributor Author

erickt commented Jan 19, 2016

@michaelwoerister: Yeah, serializing them into structs would work.

We can save this for another time, but we could also optimize the rbml tuple encoding (and tuple structs) to match that of structs by leaving out the tag and the length encoding. We'd lose some safety, but it might shave some more bytes off our metadata.

@michaelwoerister
Copy link
Member

@erickt No need to touch RBML, I think. The bulk of spans stored in metadata is within opaque sections where we don't have any of this overhead anymore since #30565. So I'd say, just do the clean solution and encode spans as structs.

@erickt
Copy link
Contributor Author

erickt commented Jan 20, 2016

@sfackler / @michaelwoerister: I've updated the patch to serialize Spans as a struct. Tests passed locally, and the size of the libraries seems to be identical to before this patch.

self.lo.encode(s)
}));

s.emit_struct_field("hi", 0, |s| {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The field index should be 1 here.

The protocol for `serialize::{En,De}code` doesn't allow for two
integers to be serialized next to each other. This switches the
protocol to serializing `Span`s as a struct. rbml structs don't
have any overhead, so the metadata shouldn't increase in size,
but it allows the json format to be properly generated, albeit
slightly more heavy than when it was just serializing a span as
a u64.

Closes rust-lang#31025.

s
@michaelwoerister
Copy link
Member

r=me if you fix those two errors.

@erickt
Copy link
Contributor Author

erickt commented Jan 20, 2016

Thanks @michaelwoerister!

@michaelwoerister
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Jan 21, 2016

📌 Commit 1dc7eb8 has been approved by michaelwoerister

@bors
Copy link
Contributor

bors commented Jan 21, 2016

⌛ Testing commit 1dc7eb8 with merge 9ae76b3...

bors added a commit that referenced this pull request Jan 21, 2016
The protocol for `serialize::{En,De}code` doesn't allow for two integers to be serialized next to each other.

Closes #31025.

cc @michaelwoerister
@bors bors merged commit 1dc7eb8 into rust-lang:master Jan 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants