Uh oh!
There was an error while loading. Please reload this page.
stop using BytePos for computing spans in librustc_parse/parser/mod.rs - #68845
Conversation
rust-highfive
commented
Feb 5, 2020
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
commented
Feb 5, 2020
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 |
dwrensha
commented
Feb 5, 2020
(Repushed after an |
dwrensha
commented
Feb 5, 2020
The diff in the test stderr is: |
| 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); |
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.
estebank
commented
Feb 5, 2020
@bors r+ rollup |
bors
commented
Feb 5, 2020
📌 Commit 9ac68e1 has been approved by |
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. Fixesrust-lang#68783.
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
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.