stop using BytePos for computing spans in librustc_parse/parser/mod.rs#68845
Merged
bors merged 1 commit intorust-lang:masterfrom Feb 6, 2020
Merged
stop using BytePos for computing spans in librustc_parse/parser/mod.rs#68845bors merged 1 commit intorust-lang:masterfrom
bors merged 1 commit intorust-lang:masterfrom
Conversation
Contributor
|
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
Contributor
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Contributor
Author
|
(Repushed after an |
Contributor
Author
|
The diff in the test stderr is: |
estebank
reviewed
Feb 5, 2020
| token::Ge => { | ||
| let span = self.token.span.with_lo(self.token.span.lo() + BytePos(1)); | ||
| Some(self.bump_with(token::Eq, span)) | ||
| let start_point = self.sess.source_map().start_point(self.token.span); |
Contributor
There was a problem hiding this comment.
If this is such a common thing then we might want to have a new method in SourceMap for it.
Contributor
|
@bors r+ rollup |
Collaborator
|
📌 Commit 9ac68e1 has been approved by |
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Feb 6, 2020
stop using BytePos for computing spans in librustc_parse/parser/mod.rs Computing spans using logic such as `self.token.span.lo() + BytePos(1)` can cause internal compiler errors like rust-lang#68730 when non-ascii characters are given as input. rust-lang#68735 partially addressed this problem, but only for one case. Moreover, its usage of `next_point()` does not actually align with what `bump_with()` expects. For example, given the token `>>=`, we should pass the span consisting of the final two characters `>=`, but `next_point()` advances the span beyond the end of the `=`. This pull request instead computes the start of the new span by doing `start_point(self.token.span).hi()`. This matches `self.token.span.lo() + BytePos(1)` in the common case where the characters are ascii, and it gracefully handles multibyte characters. Fixes rust-lang#68783.
bors
added a commit
that referenced
this pull request
Feb 6, 2020
Rollup of 9 pull requests Successful merges: - #68691 (Remove `RefCell` usage from `ObligationForest`.) - #68751 (Implement `unused_parens` for `const` and `static` items) - #68788 (Towards unified `fn` grammar) - #68837 (Make associated item collection a query) - #68842 (or_patterns: add regression test for #68785) - #68844 (use def_path_str for missing_debug_impls message) - #68845 (stop using BytePos for computing spans in librustc_parse/parser/mod.rs) - #68869 (clean up E0271 explanation) - #68880 (Forbid using `0` as issue number) Failed merges: r? @ghost
This file contains hidden or 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
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.
Computing spans using logic such as
self.token.span.lo() + BytePos(1)can cause internal compiler errors like #68730 when non-ascii characters are given as input.#68735 partially addressed this problem, but only for one case. Moreover, its usage of
next_point()does not actually align with whatbump_with()expects. For example, given the token>>=, we should pass the span consisting of the final two characters>=, butnext_point()advances the span beyond the end of the=.This pull request instead computes the start of the new span by doing
start_point(self.token.span).hi(). This matchesself.token.span.lo() + BytePos(1)in the common case where the characters are ascii, and it gracefully handles multibyte characters.Fixes #68783.