diff options
| author | Dylan DPC <dylan.dpc@gmail.com> | 2020-02-06 15:37:47 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-02-06 15:37:47 +0100 |
| commit | ec248333259481af2eedc1cc2a8bdec3b6435a31 (patch) | |
| tree | 7a074f7ee7ab201e97a0ce6bfde28f463f3dcd0c /src/test/codegen/src-hash-algorithm/src-hash-algorithm-sha1.rs | |
| parent | 16e4e8f2de21601fb40e0419579a6126df8a1607 (diff) | |
| parent | 9ac68e128b112e312cfde264d04b9d374a4402d0 (diff) | |
| download | rust-ec248333259481af2eedc1cc2a8bdec3b6435a31.tar.gz rust-ec248333259481af2eedc1cc2a8bdec3b6435a31.zip | |
Rollup merge of #68845 - dwrensha:fix-68783, r=estebank
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 #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 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 #68783.
Diffstat (limited to 'src/test/codegen/src-hash-algorithm/src-hash-algorithm-sha1.rs')
0 files changed, 0 insertions, 0 deletions
