diff options
| author | DianQK <dianqk@dianqk.net> | 2024-12-20 21:46:59 +0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-12-20 21:46:59 +0800 |
| commit | 1652e3a56073b81f4c990f9c560dbbbab288d4ef (patch) | |
| tree | ee016791ec121e207cb68739156a2e43f1c9ffa1 /tests/rustdoc-ui/coverage/enum-tuple-documented.rs | |
| parent | 8a1f8039a7ded79d3d4fe97b110016d89f2b11e2 (diff) | |
| parent | 1e33dd17115ca948c6e5ebf319695ed64490b2bf (diff) | |
| download | rust-1652e3a56073b81f4c990f9c560dbbbab288d4ef.tar.gz rust-1652e3a56073b81f4c990f9c560dbbbab288d4ef.zip | |
Rollup merge of #134366 - harrisonkaiser:no-break-space, r=davidtwco
Fix logical error with what text is considered whitespace. There appears to be a logical issue around what counts as leading white-space. There is code which does a subtraction assuming that no errors will be reported inside the leading whitespace. However we compute the length of that whitespace with std::char::is_whitespace and not rustc_lexer::is_whitespace. The former will include a no-break space while later will excluded it. We can only safely make the assumption that no errors will be reported in whitespace if it is all "Rust Standard" whitespace. Indeed an error does occur in unicode whitespace if it contains a no-break space. In that case the subtraction will cause a ICE (for a compiler in debug mode) as described in https://github.com/rust-lang/rust/issues/132918.
Diffstat (limited to 'tests/rustdoc-ui/coverage/enum-tuple-documented.rs')
0 files changed, 0 insertions, 0 deletions