-
Notifications
You must be signed in to change notification settings - Fork 743
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
Not safe to share Spans from one ParseSess to another #591
Conversation
Spans in the AST returned by `parse_item_from_source_str` and other parsing functions contain byte offsets into the source code they were parsed from. The pretty printer uses these Spans [here][1] to preserve the representation of literals when parsing and printing back out unmodified. In this bug, the byte offset of a string in the input to `parse_item_from_source_str` coincidentally matched the byte offset of a totally different string in the input to `parse_crate_from_file` called [here][2] by Syntex. The Span from the former triggered the pretty printer to write out the content of the latter. By using the same ParseSess, Spans from the two `parse_*` calls never collide. [1]: https://github.com/rust-lang/rust/blob/1.12.0/src/libsyntax/print/pprust.rs#L628 [2]: https://github.com/serde-rs/syntex/blob/v0.45.0/syntex/src/registry.rs#L134
Isn't the issue only if the newly created |
@dtolnay: r+ on this change. Do you think it'd just be best for us to replace all spans with dummy spans in these cases? Or if we should thread |
@erickt as far as I understand the issue, in theory respanning to DUMMY_SP is sufficient to fix any problems of not using the right ParseSess. In practice |
I released serde_codegen 0.8.14 with this fix and I filed serde-deprecated/aster#116 and serde-deprecated/syntex#100 to follow up on the other occurrences. |
Fixes #574 |
Fixes #590 and probably fixes #574.
Spans in the AST returned by
parse_item_from_source_str
and other parsingfunctions contain byte offsets into the source code they were parsed from. The
pretty printer uses these Spans here to preserve the representation of
literals when parsing and printing back out unmodified.
In this bug, the byte offset of a string in the input to
parse_item_from_source_str
coincidentally matched the byte offset of a totallydifferent string in the input to
parse_crate_from_file
called here bySyntex. The Span from the former triggered the pretty printer to write out the
content of the latter.
By using the same ParseSess, Spans from the two
parse_*
calls never collide.