diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2024-01-09 00:19:33 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-01-09 00:19:33 +0100 |
| commit | 70e3f8d240ea6454be252db5d335d1f5bcb86764 (patch) | |
| tree | 6acec7895569fc77d88622a1216ed8cf2be923d6 /compiler/rustc_codegen_llvm/src/errors.rs | |
| parent | ee7d4c15615ed0b6e1fd61c7b8b3462f32a9d68e (diff) | |
| parent | 6971e9332d9a7fb1567a6df0f30d03452f505ed3 (diff) | |
| download | rust-70e3f8d240ea6454be252db5d335d1f5bcb86764.tar.gz rust-70e3f8d240ea6454be252db5d335d1f5bcb86764.zip | |
Rollup merge of #119033 - Zalathar:unicode, r=davidtwco
coverage: `llvm-cov` expects column numbers to be bytes, not code points Normally the compiler emits column numbers as a 1-based number of Unicode code points. But when we embed coverage mappings for `-Cinstrument-coverage`, those mappings will ultimately be read by the `llvm-cov` tool. That tool assumes that column numbers are 1-based numbers of *bytes*, and relies on that assumption when slicing up source code to apply highlighting (in HTML reports, and in text-based reports with colour). For the very common case of all-ASCII source code, bytes and code points are the same, so the difference isn't noticeable. But for code that contains non-ASCII characters, emitting column numbers as code points will result in `llvm-cov` slicing strings in the wrong places, producing mangled output or fatal errors. (See https://github.com/taiki-e/cargo-llvm-cov/issues/275 as an example of what can go wrong.)
Diffstat (limited to 'compiler/rustc_codegen_llvm/src/errors.rs')
0 files changed, 0 insertions, 0 deletions
