coverage: Resolve spans to file-coordinates in a separate step - #162044
Merged
Conversation
- Rename `generate_*` functions to `emit_*`, since they emit LLVM globals - Consistently use qualified paths in `counter_for_term` - Remove an unnecessary Clone from `llvm_cov::Regions`
One of the key tasks in coverage codegen is to take the source-code spans that were recorded during MIR instrumentation, and resolve them to physical coordinates in their respective files. In rare cases this resolution can fail, which leads to the awkward possibility that a function might lose _all_ of its mappings for a particular file/expansion. If that happens, we need to avoid emitting a covfun file section containing no regions, because doing so would trigger errors in LLVM. The existing code does handle this edge case, but in a way that won't generalise to multiple files/expansions. Having an explicit intermediate resolution step will make it easier to add support for expansion regions in the future.
Zalathar
added
the
A-code-coverage
rustbot
added
A-LLVM
Collaborator
|
r? @folkertdev rustbot has assigned @folkertdev. Use Why was this reviewer chosen?The reviewer was selected based on:
|
Contributor
|
@bors r+ |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Sep 2, 2026
coverage: Resolve spans to file-coordinates in a separate step One of the key tasks in coverage codegen is to take the source-code spans that were recorded during MIR instrumentation, and resolve them to physical coordinates in their respective files. In rare cases this resolution can fail, which leads to the awkward possibility that a function might lose _all_ of its mappings for a particular file/expansion. If that happens, we need to avoid emitting a covfun file section containing no regions, because doing so would trigger errors in LLVM. The existing code does handle this edge case, but in a way that won't generalise to multiple files/expansions. Having an explicit intermediate resolution step will make it easier to add support for expansion regions in the future. There should be no change to compiler output.
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 2, 2026
coverage: Resolve spans to file-coordinates in a separate step One of the key tasks in coverage codegen is to take the source-code spans that were recorded during MIR instrumentation, and resolve them to physical coordinates in their respective files. In rare cases this resolution can fail, which leads to the awkward possibility that a function might lose _all_ of its mappings for a particular file/expansion. If that happens, we need to avoid emitting a covfun file section containing no regions, because doing so would trigger errors in LLVM. The existing code does handle this edge case, but in a way that won't generalise to multiple files/expansions. Having an explicit intermediate resolution step will make it easier to add support for expansion regions in the future. There should be no change to compiler output.
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Sep 2, 2026
coverage: Resolve spans to file-coordinates in a separate step One of the key tasks in coverage codegen is to take the source-code spans that were recorded during MIR instrumentation, and resolve them to physical coordinates in their respective files. In rare cases this resolution can fail, which leads to the awkward possibility that a function might lose _all_ of its mappings for a particular file/expansion. If that happens, we need to avoid emitting a covfun file section containing no regions, because doing so would trigger errors in LLVM. The existing code does handle this edge case, but in a way that won't generalise to multiple files/expansions. Having an explicit intermediate resolution step will make it easier to add support for expansion regions in the future. There should be no change to compiler output.
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Sep 2, 2026
coverage: Resolve spans to file-coordinates in a separate step One of the key tasks in coverage codegen is to take the source-code spans that were recorded during MIR instrumentation, and resolve them to physical coordinates in their respective files. In rare cases this resolution can fail, which leads to the awkward possibility that a function might lose _all_ of its mappings for a particular file/expansion. If that happens, we need to avoid emitting a covfun file section containing no regions, because doing so would trigger errors in LLVM. The existing code does handle this edge case, but in a way that won't generalise to multiple files/expansions. Having an explicit intermediate resolution step will make it easier to add support for expansion regions in the future. There should be no change to compiler output.
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 2, 2026
coverage: Resolve spans to file-coordinates in a separate step One of the key tasks in coverage codegen is to take the source-code spans that were recorded during MIR instrumentation, and resolve them to physical coordinates in their respective files. In rare cases this resolution can fail, which leads to the awkward possibility that a function might lose _all_ of its mappings for a particular file/expansion. If that happens, we need to avoid emitting a covfun file section containing no regions, because doing so would trigger errors in LLVM. The existing code does handle this edge case, but in a way that won't generalise to multiple files/expansions. Having an explicit intermediate resolution step will make it easier to add support for expansion regions in the future. There should be no change to compiler output.
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 2, 2026
coverage: Resolve spans to file-coordinates in a separate step One of the key tasks in coverage codegen is to take the source-code spans that were recorded during MIR instrumentation, and resolve them to physical coordinates in their respective files. In rare cases this resolution can fail, which leads to the awkward possibility that a function might lose _all_ of its mappings for a particular file/expansion. If that happens, we need to avoid emitting a covfun file section containing no regions, because doing so would trigger errors in LLVM. The existing code does handle this edge case, but in a way that won't generalise to multiple files/expansions. Having an explicit intermediate resolution step will make it easier to add support for expansion regions in the future. There should be no change to compiler output.
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Sep 2, 2026
coverage: Resolve spans to file-coordinates in a separate step One of the key tasks in coverage codegen is to take the source-code spans that were recorded during MIR instrumentation, and resolve them to physical coordinates in their respective files. In rare cases this resolution can fail, which leads to the awkward possibility that a function might lose _all_ of its mappings for a particular file/expansion. If that happens, we need to avoid emitting a covfun file section containing no regions, because doing so would trigger errors in LLVM. The existing code does handle this edge case, but in a way that won't generalise to multiple files/expansions. Having an explicit intermediate resolution step will make it easier to add support for expansion regions in the future. There should be no change to compiler output.
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 2, 2026
…uwer Rollup of 23 pull requests Successful merges: - #162164 (Revert "Implement Debug for C-like enums with a concatenated string") - #160564 (volatile: allow accesses to non-AM memory to trap) - #161579 (suggest calling a fn item used as the iterator of a `for` loop) - #162044 (coverage: Resolve spans to file-coordinates in a separate step) - #162120 (Introduce `PerOwnerLoweringState`) - #162151 (Test itanium mangling of `f16` and `f128`) - #162162 (Don't special-case `!` in stability checks anymore) - #162181 (Remove wrong UnusedBraces lint for iterator loop in edition 2024 ) - #162187 (Rename `thir::ExprKind::Use` to `ValueExpr`) - #158401 (mgca: Don't ICE when evaluating ValTrees that contain error constants) - #159873 (fuchsia: Add safestack as a supported sanitizer for x86_64 fuchsia) - #161847 (Preserve visibility in nested macro import suggestions) - #161972 (Improve tests for `#[track_caller]` in async) - #162008 (Render the `box` pattern removal diagnostic more actionable & remove `box` expression recovery) - #162065 (std: don't reference `libc::O_NOFOLLOW` on VxWorks in `set_perm_nofollow`) - #162076 (docs(num): clarify conditions under which error occurs in `impl TryFrom<int> for int`) - #162152 (Revert "retrieve supported GCC targets from the sysroot") - #162153 (Prefer `LLVMGetVersion` for runtime info) - #162168 (fix ICE in project_goals/inherent) - #162171 (Explain LoongArch f16 NaN-boxing in inline asm) - #162173 (fix supposedly unreachable `bug!` being reachable) - #162191 (core: mark float `ClampBounds` methods as `#[inline]`) - #162199 (docs(time): clarify exact seconds for hour and minute)
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Sep 2, 2026
coverage: Resolve spans to file-coordinates in a separate step One of the key tasks in coverage codegen is to take the source-code spans that were recorded during MIR instrumentation, and resolve them to physical coordinates in their respective files. In rare cases this resolution can fail, which leads to the awkward possibility that a function might lose _all_ of its mappings for a particular file/expansion. If that happens, we need to avoid emitting a covfun file section containing no regions, because doing so would trigger errors in LLVM. The existing code does handle this edge case, but in a way that won't generalise to multiple files/expansions. Having an explicit intermediate resolution step will make it easier to add support for expansion regions in the future. There should be no change to compiler output.
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 3, 2026
Rollup of 23 pull requests Successful merges: - #157808 (sanitizers: Implement support for the sanitize ignorelist) - #160564 (volatile: allow accesses to non-AM memory to trap) - #161579 (suggest calling a fn item used as the iterator of a `for` loop) - #162044 (coverage: Resolve spans to file-coordinates in a separate step) - #162120 (Introduce `PerOwnerLoweringState`) - #162151 (Test itanium mangling of `f16` and `f128`) - #162162 (Don't special-case `!` in stability checks anymore) - #162181 (Remove wrong UnusedBraces lint for iterator loop in edition 2024 ) - #162187 (Rename `thir::ExprKind::Use` to `ValueExpr`) - #158401 (mgca: Don't ICE when evaluating ValTrees that contain error constants) - #159873 (fuchsia: Add safestack as a supported sanitizer for x86_64 fuchsia) - #161847 (Preserve visibility in nested macro import suggestions) - #161972 (Improve tests for `#[track_caller]` in async) - #162008 (Render the `box` pattern removal diagnostic more actionable & remove `box` expression recovery) - #162065 (std: don't reference `libc::O_NOFOLLOW` on VxWorks in `set_perm_nofollow`) - #162076 (docs(num): clarify conditions under which error occurs in `impl TryFrom<int> for int`) - #162152 (Revert "retrieve supported GCC targets from the sysroot") - #162153 (Prefer `LLVMGetVersion` for runtime info) - #162168 (fix ICE in project_goals/inherent) - #162171 (Explain LoongArch f16 NaN-boxing in inline asm) - #162173 (fix supposedly unreachable `bug!` being reachable) - #162191 (core: mark float `ClampBounds` methods as `#[inline]`) - #162199 (docs(time): clarify exact seconds for hour and minute)
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Sep 3, 2026
coverage: Resolve spans to file-coordinates in a separate step One of the key tasks in coverage codegen is to take the source-code spans that were recorded during MIR instrumentation, and resolve them to physical coordinates in their respective files. In rare cases this resolution can fail, which leads to the awkward possibility that a function might lose _all_ of its mappings for a particular file/expansion. If that happens, we need to avoid emitting a covfun file section containing no regions, because doing so would trigger errors in LLVM. The existing code does handle this edge case, but in a way that won't generalise to multiple files/expansions. Having an explicit intermediate resolution step will make it easier to add support for expansion regions in the future. There should be no change to compiler output.
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 3, 2026
Rollup of 29 pull requests Successful merges: - #161694 (add `Complex` ABI run-make test) - #162014 (Move more `rustdoc-html` tests using `--test` into the right folder) - #162164 (Revert "Implement Debug for C-like enums with a concatenated string") - #160564 (volatile: allow accesses to non-AM memory to trap) - #161579 (suggest calling a fn item used as the iterator of a `for` loop) - #162044 (coverage: Resolve spans to file-coordinates in a separate step) - #162120 (Introduce `PerOwnerLoweringState`) - #162132 (std: improve safety documentation in UNIX stack overflow code) - #162151 (Test itanium mangling of `f16` and `f128`) - #162162 (Don't special-case `!` in stability checks anymore) - #162181 (Remove wrong UnusedBraces lint for iterator loop in edition 2024 ) - #162187 (Rename `thir::ExprKind::Use` to `ValueExpr`) - #158401 (mgca: Don't ICE when evaluating ValTrees that contain error constants) - #159873 (fuchsia: Add safestack as a supported sanitizer for x86_64 fuchsia) - #161847 (Preserve visibility in nested macro import suggestions) - #161951 (Windows: add fallback if `canonicalize` fails) - #161972 (Improve tests for `#[track_caller]` in async) - #162008 (Render the `box` pattern removal diagnostic more actionable & remove `box` expression recovery) - #162065 (std: don't reference `libc::O_NOFOLLOW` on VxWorks in `set_perm_nofollow`) - #162076 (docs(num): clarify conditions under which error occurs in `impl TryFrom<int> for int`) - #162152 (Revert "retrieve supported GCC targets from the sysroot") - #162153 (Prefer `LLVMGetVersion` for runtime info) - #162168 (fix ICE in project_goals/inherent) - #162171 (Explain LoongArch f16 NaN-boxing in inline asm) - #162173 (fix supposedly unreachable `bug!` being reachable) - #162180 (remove outdated next-solver FIXMEs) - #162191 (core: mark float `ClampBounds` methods as `#[inline]`) - #162195 (docs(time): clarify exact seconds for week and day) - #162199 (docs(time): clarify exact seconds for hour and minute)
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 3, 2026
…uwer Rollup of 25 pull requests Successful merges: - #161694 (add `Complex` ABI run-make test) - #162014 (Move more `rustdoc-html` tests using `--test` into the right folder) - #162164 (Revert "Implement Debug for C-like enums with a concatenated string") - #160564 (volatile: allow accesses to non-AM memory to trap) - #161579 (suggest calling a fn item used as the iterator of a `for` loop) - #162044 (coverage: Resolve spans to file-coordinates in a separate step) - #162120 (Introduce `PerOwnerLoweringState`) - #162132 (std: improve safety documentation in UNIX stack overflow code) - #162151 (Test itanium mangling of `f16` and `f128`) - #162162 (Don't special-case `!` in stability checks anymore) - #162181 (Remove wrong UnusedBraces lint for iterator loop in edition 2024 ) - #162187 (Rename `thir::ExprKind::Use` to `ValueExpr`) - #158401 (mgca: Don't ICE when evaluating ValTrees that contain error constants) - #159873 (fuchsia: Add safestack as a supported sanitizer for x86_64 fuchsia) - #161135 (Add `f16` and `f128` inline ASM support for PowerPC) - #161847 (Preserve visibility in nested macro import suggestions) - #161972 (Improve tests for `#[track_caller]` in async) - #162008 (Render the `box` pattern removal diagnostic more actionable & remove `box` expression recovery) - #162065 (std: don't reference `libc::O_NOFOLLOW` on VxWorks in `set_perm_nofollow`) - #162076 (docs(num): clarify conditions under which error occurs in `impl TryFrom<int> for int`) - #162111 (Update mailmap for Will Crichton and Petr Hosek) - #162152 (Revert "retrieve supported GCC targets from the sysroot") - #162153 (Prefer `LLVMGetVersion` for runtime info) - #162168 (fix ICE in project_goals/inherent) - #162171 (Explain LoongArch f16 NaN-boxing in inline asm)
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 3, 2026
Rollup merge of #162044 - Zalathar:resolved, r=folkertdev coverage: Resolve spans to file-coordinates in a separate step One of the key tasks in coverage codegen is to take the source-code spans that were recorded during MIR instrumentation, and resolve them to physical coordinates in their respective files. In rare cases this resolution can fail, which leads to the awkward possibility that a function might lose _all_ of its mappings for a particular file/expansion. If that happens, we need to avoid emitting a covfun file section containing no regions, because doing so would trigger errors in LLVM. The existing code does handle this edge case, but in a way that won't generalise to multiple files/expansions. Having an explicit intermediate resolution step will make it easier to add support for expansion regions in the future. There should be no change to compiler output.
Collaborator
|
Note This PR was benchmarked as part of triage of its containing rollup: triage URL. Finished benchmarking commit (a88204a): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis perf run didn't have relevant results for this metric. Max RSS (memory usage)This perf run didn't have relevant results for this metric. CyclesResults (secondary 3.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: missing data |
pull Bot
pushed a commit
to LeeeeeeM/miri
that referenced
this pull request
Sep 4, 2026
…uwer Rollup of 25 pull requests Successful merges: - rust-lang/rust#161694 (add `Complex` ABI run-make test) - rust-lang/rust#162014 (Move more `rustdoc-html` tests using `--test` into the right folder) - rust-lang/rust#162164 (Revert "Implement Debug for C-like enums with a concatenated string") - rust-lang/rust#160564 (volatile: allow accesses to non-AM memory to trap) - rust-lang/rust#161579 (suggest calling a fn item used as the iterator of a `for` loop) - rust-lang/rust#162044 (coverage: Resolve spans to file-coordinates in a separate step) - rust-lang/rust#162120 (Introduce `PerOwnerLoweringState`) - rust-lang/rust#162132 (std: improve safety documentation in UNIX stack overflow code) - rust-lang/rust#162151 (Test itanium mangling of `f16` and `f128`) - rust-lang/rust#162162 (Don't special-case `!` in stability checks anymore) - rust-lang/rust#162181 (Remove wrong UnusedBraces lint for iterator loop in edition 2024 ) - rust-lang/rust#162187 (Rename `thir::ExprKind::Use` to `ValueExpr`) - rust-lang/rust#158401 (mgca: Don't ICE when evaluating ValTrees that contain error constants) - rust-lang/rust#159873 (fuchsia: Add safestack as a supported sanitizer for x86_64 fuchsia) - rust-lang/rust#161135 (Add `f16` and `f128` inline ASM support for PowerPC) - rust-lang/rust#161847 (Preserve visibility in nested macro import suggestions) - rust-lang/rust#161972 (Improve tests for `#[track_caller]` in async) - rust-lang/rust#162008 (Render the `box` pattern removal diagnostic more actionable & remove `box` expression recovery) - rust-lang/rust#162065 (std: don't reference `libc::O_NOFOLLOW` on VxWorks in `set_perm_nofollow`) - rust-lang/rust#162076 (docs(num): clarify conditions under which error occurs in `impl TryFrom<int> for int`) - rust-lang/rust#162111 (Update mailmap for Will Crichton and Petr Hosek) - rust-lang/rust#162152 (Revert "retrieve supported GCC targets from the sysroot") - rust-lang/rust#162153 (Prefer `LLVMGetVersion` for runtime info) - rust-lang/rust#162168 (fix ICE in project_goals/inherent) - rust-lang/rust#162171 (Explain LoongArch f16 NaN-boxing in inline asm)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
One of the key tasks in coverage codegen is to take the source-code spans that were recorded during MIR instrumentation, and resolve them to physical coordinates in their respective files.
In rare cases this resolution can fail, which leads to the awkward possibility that a function might lose all of its mappings for a particular file/expansion. If that happens, we need to avoid emitting a covfun file section containing no regions, because doing so would trigger errors in LLVM.
The existing code does handle this edge case, but in a way that won't generalise to multiple files/expansions. Having an explicit intermediate resolution step will make it easier to add support for expansion regions in the future.
There should be no change to compiler output.