Uh oh!
There was an error while loading. Please reload this page.
coverage: Infer instances_used from pgo_func_name_var_map - #144530
Conversation
In obscure circumstances, we would sometimes emit a covfun record for a function with no physical coverage counters, causing `llvm-cov` to fail with the cryptic error message: malformed instrumentation profile data: function name is empty We can eliminate this mismatch by removing `instances_used` entirely, and instead inferring its contents from the keys of `pgo_func_name_var_map`. This makes it impossible for a "used" function to lack a PGO name entry.
rustbot
commented
Jul 27, 2025
r? @SparrowLii rustbot has assigned @SparrowLii. Use |
lqd
commented
Jul 27, 2025
r? lqd This change looks good to me. It'd be better to have a test but we don't necessarily need it in this PR, as getting an MCVE from #141577 is not easy. Reducing the issue seems doable to me, but the current repro involving fuzzing is still quite involved, and it seems it'd be painful to produce a minimization in this current state. We should have such a test before relanding #144298 though, so the issue doesn't reappear a 3rd time. With that, @bors r+ |
bors
commented
Jul 27, 2025
Rollup of 7 pull requests Successful merges: - #144072 (update `Atomic*::from_ptr` and `Atomic*::as_ptr` docs) - #144151 (`tests/ui/issues/`: The Issues Strike Back [1/N]) - #144300 (Clippy fixes for miropt-test-tools) - #144399 (Add a ratchet for moving all standard library tests to separate packages) - #144472 (str: Mark unstable `round_char_boundary` feature functions as const) - #144503 (Various refactors to the codegen coordinator code (part 3)) - #144530 (coverage: Infer `instances_used` from `pgo_func_name_var_map`) r? `@ghost` `@rustbot` modify labels: rollup
Uh oh!
There was an error while loading. Please reload this page.
Rollup merge of #144530 - Zalathar:instances-used, r=lqd coverage: Infer `instances_used` from `pgo_func_name_var_map` In obscure circumstances involving macro-expanded spans, we would sometimes emit a covfun record for a function with no physical coverage counters, and therefore no corresponding entry in the “PGO names” section of the binary. The absence of that name entry causes `llvm-cov` to fail with the cryptic error message: ```text malformed instrumentation profile data: function name is empty ``` We can eliminate this mismatch by removing `instances_used` entirely, and instead inferring its contents from the keys of `pgo_func_name_var_map`. This makes it impossible for a "used" function to lack a PGO name entry. --- This is an attempt to eliminate the cause of #141577 when re-landing changes like #144298 in the future. I haven't been able to reproduce the underlying issue in an in-tree test, because the only known repro involves a non-trivial derive proc-macro that relies on `syn` and `proc-macro2`. But I have manually verified in a separate branch that this change would have prevented the reoccurrence of #141577 (comment).
coverage: Regression test for "function name is empty" bug Regression test for rust-lang#141577, which was triggered by rust-lang#144298. The bug was triggered by a particular usage of the `?` try operator in a proc-macro expansion. Thanks to lqd for the minimization at rust-lang#144571 (comment). --- I have manually verified that reverting the relevant follow-up fixes (rust-lang#144480 and rust-lang#144530) causes this test to reproduce the bug: ```sh git revert -m1 8aa3d41c462895 ``` --- r? compiler
coverage: Regression test for "function name is empty" bug Regression test for rust-lang#141577, which was triggered by rust-lang#144298. The bug was triggered by a particular usage of the `?` try operator in a proc-macro expansion. Thanks to lqd for the minimization at rust-lang#144571 (comment). --- I have manually verified that reverting the relevant follow-up fixes (rust-lang#144480 and rust-lang#144530) causes this test to reproduce the bug: ```sh git revert -m1 8aa3d41c462895 ``` --- r? compiler
coverage: Regression test for "function name is empty" bug Regression test for rust-lang#141577, which was triggered by rust-lang#144298. The bug was triggered by a particular usage of the `?` try operator in a proc-macro expansion. Thanks to lqd for the minimization at rust-lang#144571 (comment). --- I have manually verified that reverting the relevant follow-up fixes (rust-lang#144480 and rust-lang#144530) causes this test to reproduce the bug: ```sh git revert -m1 8aa3d41c462895 ``` --- r? compiler
Rollup merge of #144616 - Zalathar:try-in-macro, r=jieyouxu coverage: Regression test for "function name is empty" bug Regression test for #141577, which was triggered by #144298. The bug was triggered by a particular usage of the `?` try operator in a proc-macro expansion. Thanks to lqd for the minimization at #144571 (comment). --- I have manually verified that reverting the relevant follow-up fixes (#144480 and #144530) causes this test to reproduce the bug: ```sh git revert -m1 8aa3d41c462895 ``` --- r? compiler
coverage: Re-land "Enlarge empty spans during MIR instrumentation" This allows us to assume that coverage spans will only be discarded during codegen in very unusual situations. --- This seemingly-simple change has a rather messy history: - rust-lang#140847 - rust-lang#141650 - rust-lang#144298 - rust-lang#144480 Since then, a number of related changes have landed that should make it reasonable to try again: - rust-lang#144530 - rust-lang#144560 - rust-lang#144616 In particular, we have multiple fixes/mitigations, and a confirmed regression test for the original bug that is not triggered by re-landing the changes in this PR.
coverage: Regression test for "function name is empty" bug Regression test for rust-lang/rust#141577, which was triggered by rust-lang/rust#144298. The bug was triggered by a particular usage of the `?` try operator in a proc-macro expansion. Thanks to lqd for the minimization at rust-lang/rust#144571 (comment). --- I have manually verified that reverting the relevant follow-up fixes (rust-lang/rust#144480 and rust-lang/rust#144530) causes this test to reproduce the bug: ```sh git revert -m1 8aa3d41b8527f9f78e0f2459b50a6e13aea35144 c462895a6f0b463ff0c1c1db2a3a654d7e5976c7 ``` --- r? compiler
coverage: Re-land "Enlarge empty spans during MIR instrumentation" This allows us to assume that coverage spans will only be discarded during codegen in very unusual situations. --- This seemingly-simple change has a rather messy history: - rust-lang#140847 - rust-lang#141650 - rust-lang#144298 - rust-lang#144480 Since then, a number of related changes have landed that should make it reasonable to try again: - rust-lang#144530 - rust-lang#144560 - rust-lang#144616 In particular, we have multiple fixes/mitigations, and a confirmed regression test for the original bug that is not triggered by re-landing the changes in this PR.
Rollup merge of #144663 - Zalathar:empty-span, r=petrochenkov coverage: Re-land "Enlarge empty spans during MIR instrumentation" This allows us to assume that coverage spans will only be discarded during codegen in very unusual situations. --- This seemingly-simple change has a rather messy history: - #140847 - #141650 - #144298 - #144480 Since then, a number of related changes have landed that should make it reasonable to try again: - #144530 - #144560 - #144616 In particular, we have multiple fixes/mitigations, and a confirmed regression test for the original bug that is not triggered by re-landing the changes in this PR.
Rollup of 7 pull requests Successful merges: - rust-lang/rust#144072 (update `Atomic*::from_ptr` and `Atomic*::as_ptr` docs) - rust-lang/rust#144151 (`tests/ui/issues/`: The Issues Strike Back [1/N]) - rust-lang/rust#144300 (Clippy fixes for miropt-test-tools) - rust-lang/rust#144399 (Add a ratchet for moving all standard library tests to separate packages) - rust-lang/rust#144472 (str: Mark unstable `round_char_boundary` feature functions as const) - rust-lang/rust#144503 (Various refactors to the codegen coordinator code (part 3)) - rust-lang/rust#144530 (coverage: Infer `instances_used` from `pgo_func_name_var_map`) r? `@ghost` `@rustbot` modify labels: rollup
coverage: Re-land "Enlarge empty spans during MIR instrumentation" This allows us to assume that coverage spans will only be discarded during codegen in very unusual situations. --- This seemingly-simple change has a rather messy history: - rust-lang/rust#140847 - rust-lang/rust#141650 - rust-lang/rust#144298 - rust-lang/rust#144480 Since then, a number of related changes have landed that should make it reasonable to try again: - rust-lang/rust#144530 - rust-lang/rust#144560 - rust-lang/rust#144616 In particular, we have multiple fixes/mitigations, and a confirmed regression test for the original bug that is not triggered by re-landing the changes in this PR.
In obscure circumstances involving macro-expanded spans, we would sometimes emit a covfun record for a function with no physical coverage counters, and therefore no corresponding entry in the “PGO names” section of the binary. The absence of that name entry causes
llvm-covto fail with the cryptic error message:We can eliminate this mismatch by removing
instances_usedentirely, and instead inferring its contents from the keys ofpgo_func_name_var_map.This makes it impossible for a "used" function to lack a PGO name entry.
This is an attempt to eliminate the cause of #141577 when re-landing changes like #144298 in the future.
I haven't been able to reproduce the underlying issue in an in-tree test, because the only known repro involves a non-trivial derive proc-macro that relies on
synandproc-macro2. But I have manually verified in a separate branch that this change would have prevented the reoccurrence of #141577 (comment).