Skip to content

coverage: Infer instances_used from pgo_func_name_var_map #144530

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Zalathar
Copy link
Contributor

@Zalathar Zalathar commented Jul 27, 2025

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:

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).

Zalathar added 2 commits July 27, 2025 21:49
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.
@Zalathar Zalathar added the A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) label Jul 27, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 27, 2025

r? @SparrowLii

rustbot has assigned @SparrowLii.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 27, 2025
@lqd
Copy link
Member

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
Copy link
Collaborator

bors commented Jul 27, 2025

📌 Commit 89b6b0b has been approved by lqd

It is now in the queue for this repository.

@rustbot rustbot assigned lqd and unassigned SparrowLii Jul 27, 2025
@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants