-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
stop using BytePos for computing spans in librustc_parse/parser/mod.rs #68845
Conversation
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
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 |
(Repushed after an |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is such a common thing then we might want to have a new method in SourceMap
for it.
@bors r+ rollup |
📌 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. Fixes rust-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.