diff options
| author | León Orell Valerian Liehr <me@fmease.dev> | 2024-01-24 15:43:11 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-01-24 15:43:11 +0100 |
| commit | 5a38754d23ef2d5b6ce16dcafdb9ac434726c7d9 (patch) | |
| tree | d2dd0087f6c7495575e1cb400f5f10b5c263a994 /compiler/rustc_mir_transform/src/coverage/graph.rs | |
| parent | 3529d45b7470c13eb1ab2bc03d660e1e1846ded8 (diff) | |
| parent | 21e5beae3cc4ffd2adea9ae7b4a9d8b84a4bc0a8 (diff) | |
| download | rust-5a38754d23ef2d5b6ce16dcafdb9ac434726c7d9.tar.gz rust-5a38754d23ef2d5b6ce16dcafdb9ac434726c7d9.zip | |
Rollup merge of #119460 - Zalathar:improper-region, r=wesleywiser
coverage: Never emit improperly-ordered coverage regions If we emit a coverage region that is improperly ordered (end < start), `llvm-cov` will fail with `coveragemap_error::malformed`, which is inconvenient for users and also very hard to debug. Ideally we would fix the root causes of these situations, but they tend to occur in very obscure edge-case scenarios (often involving nested macros), and we don't always have a good MCVE to work from. So it makes sense to also have a catch-all check that will prevent improperly-ordered regions from ever being emitted. --- This is mainly aimed at resolving #119453. We don't have a specific way to reproduce it, which is why I haven't been able to add a test case in this PR. But based on the information provided in that issue, this change seems likely to avoid the error in `llvm-cov`. `````@rustbot````` label +A-code-coverage
Diffstat (limited to 'compiler/rustc_mir_transform/src/coverage/graph.rs')
0 files changed, 0 insertions, 0 deletions